Classes de tráfego têm exigências incompatíveis
Uma única identidade de remetente e uma única rota é simples, mas as classes que a compartilham têm prazos, bases legais, revisão de conteúdo e definições de sucesso diferentes. Se compartilham rota, o comportamento de fila de uma campanha atinge um código de autenticação, e uma revisão de conteúdo promocional atinge a identidade que carrega esse código.
Cinco classes merecem separação: autenticação, serviço, promoção, suporte e avisos operacionais urgentes.
O que precisa ser diferente
- Identidade de remetente e registro. O registro 10DLC nos EUA inclui um caso de uso declarado que influencia o tratamento do tráfego; confirme os detalhes por campanha com seu fornecedor.
- Consentimento e supressão. Um opt-out de marketing não é um bloqueio global, um bloqueio global deve ser respeitado, e a supressão não pode bloquear um código solicitado pelo usuário.
- Prioridade de fila e alocação de throughput por classe, senão um envio grande consome a capacidade das demais.
- Política de rotas. Rotas separadas e, de preferência, fornecedores separados; tráfego promocional nunca faz fallback para uma rota de autenticação.
- Política de retry e prazos: um prazo útil por classe com condição de parada, em vez de repetição indefinida.
- Governança de conteúdo e templates com identidade, ID de template e status de aprovação registrados.
- Baselines de monitoramento vindas do histórico do próprio programa, não de limites universais.
- Resposta a incidentes por classe: quem é acionado, primeira ação, definição de resolvido.
Matriz de isolamento
| Dimensão | Autenticação | Serviço | Promoção | Suporte | Urgente |
|---|---|---|---|---|---|
| Identidade | Dedicada, registrada | Dedicada ou com serviço | Dedicada para marketing | Bidirecional | Dedicada ou serviço |
| Rota | Dedicada, latência primeiro | Compartilhada só com alocação forçada | Rota própria, se possível fornecedor próprio | Com inbound | Dedicada com fallback próprio |
| Prioridade | Máxima | Alta | Mínima, agendada | Interativa | Precedência |
| Consentimento | Solicitado pelo usuário | Evento de negócio | Consentimento registrado | Conversa existente | Necessidade operacional |
| Supressão | Só bloqueios globais | Só bloqueios globais | Opt-out de marketing e global | Estado da conversa | Só bloqueios globais |
| Prazo | O fluxo ativo | O evento | Janela da campanha, horários de silêncio | A sessão | Imediato, com escalada |
| Failover | Outra rota de autenticação | Rota de serviço | Nunca autenticação | Rota com inbound | Caminho independente |
| Alertas | Distribuição de latência e verificação | Mix de status finais | Throttling, rejeições, opt-outs | Inbound sem resposta | Confirmação |
Checklist de migração
- Classificar o tráfego atual e marcar cada envio antes de mudar qualquer coisa.
- Registrar as baselines atuais por programa e rota.
- Registrar novas identidades por mercado e aguardar confirmação.
- Provisionar rotas separadas e alocações de throughput.
- Implementar filas, prioridades, prazos e condições de parada por classe.
- Implementar a semântica de supressão por classe e verificar que um opt-out de marketing não bloqueia um código solicitado.
- Migrar primeiro a classe de menor risco, normalmente promocional.
- Depois serviço e, por último, autenticação, mantendo a rota antiga aquecida.
- Separar os alertas por classe, com responsável e ação.
- Refazer as baselines e remover o caminho de fallback misto.
A Flowstates vende e opera rotas, apoia BYOV e modelos híbridos. O isolamento é o mesmo trabalho em qualquer modelo.