Restrições de rotas A2P SMS: como documentá-las para evitar envios não suportados e decisões de roteamento opacas

Porque as restrições de rota devem ser dados operacionais

Uma restrição de rota A2P SMS é uma condição que determina se uma mensagem específica pode ser enviada por uma determinada rota. Pode depender do destino de terminação, do operador quando aplicável, do tipo de tráfego, do remetente, do conteúdo, de um registo prévio, da capacidade disponível ou de uma condição comercial.

Estas condições costumam ficar dispersas entre contratos, e-mails, portais de fornecedores, tickets e conhecimento informal de uma pessoa da equipa. Este modelo é difícil de auditar e propenso a erros: uma rota pode estar tecnicamente disponível, mas não admitir um determinado destino, um Sender ID, tráfego promocional, links ou um padrão de volume.

A matriz de restrições não substitui o contrato, a regulamentação aplicável nem a confirmação do fornecedor. A sua função é transformar informação dispersa em regras consultáveis, rastreáveis e acionáveis antes de aceitar, rotear ou escalar tráfego.

• Trate cada restrição como uma regra com âmbito explícito, e não como uma nota genérica.
• Modele o destino de terminação de forma concreta; não infira requisitos apenas a partir do país de origem do remetente.
• Utilize a numeração internacional normalizada como campo de validação do destino, de acordo com a recomendação ITU-T E.164 para o plano público internacional de numeração.
• Mantenha separadas as restrições técnicas do SMS, as condições comerciais de uma rota e os requisitos regulamentares ou de rede.

Uma rota disponível não equivale a uma rota adequada

A disponibilidade de conectividade não demonstra que uma rota seja adequada para todo o tráfego. A mesma rota pode aceitar uma ligação HTTP ou SMPP e, ainda assim, restringir remetentes, exigir pré-registo, admitir apenas determinados casos de uso ou aplicar limites de capacidade diferentes consoante a conta, o remetente ou o canal.

A decisão correta não consiste apenas em perguntar se existe uma rota para um país. Deve ser formulada como uma avaliação de compatibilidade: este destino, este remetente, este caso de uso, este conteúdo e este padrão de envio são admitidos por esta rota na data da decisão?

Esta abordagem evita uma conclusão particularmente arriscada: interpretar uma condição comercial ou uma afirmação de disponibilidade como garantia técnica de entrega. Mesmo quando um envio é aceite para processamento, o resultado pode depender de elementos fora do controlo de uma única parte da cadeia de mensagens.

• Destino: país e, quando a evidência o exigir, rede ou operador de terminação.
• Tráfego: OTP ou 2FA, notificação de conta, alerta de fraude, apoio ao cliente, marketing com consentimento ou outra categoria controlada.
• Remetente: alfanumérico, número, código curto ou outro tipo permitido pelo destino e pela rota.
• Conteúdo: idioma, codificação, links, encurtadores, modelos, palavras de cancelamento e elementos de marca.
• Padrão de envio: volume, taxa, recorrência, janela de validade e necessidade de resposta.
• Condições de ativação: pré-registo, aprovação, campanha, consentimento e testes exigidos.

As categorias mínimas de uma tabela de restrições

Uma tabela útil deve permitir que operações, compras, conformidade e engenharia respondam à mesma pergunta com os mesmos campos. Não basta uma coluna de “permitido” ou “não permitido”, porque essa resposta não tem contexto e não explica qual condição a altera.

A granularidade deve ser suficiente para evitar regras excessivamente genéricas por país. Se uma condição foi confirmada apenas para um operador, uma rede ou um tipo de remetente, a ficha deve refletir esse limite em vez de o estender a todo o destino.

A conectividade deve ser registada apenas quando afeta a aceitação operacional do tráfego e existe evidência específica para a rota ou fornecedor correspondente. A disponibilidade de HTTP ou SMPP não confirma, por si só, que um tipo de tráfego é admissível. A BulkSMSMarket descreve conectividade HTTP e SMPP na sua secção para programadores.

HLR Lookup pode ser utilizado como um sinal técnico de rede numa decisão operacional, mas não comprova consentimento, identidade, titularidade do número nem entrega garantida. As verificações internas da BulkSMSMarket constituem evidência operacional limitada: os seus testes diários observam entrega, consistência de DLR, latência, disponibilidade e comportamento de remetente ou conteúdo em rotas, destinos e operadores, sem validar a conformidade nem oferecer garantias comerciais.

Antes de adquirir ou vender capacidade A2P, é aconselhável confirmar o âmbito de cada restrição, a evidência disponível e a sua validade. Regras precisas e atualizadas reduzem a ambiguidade na gestão responsável de capacidade.

• Identificador da regra: código único e estável para referências em tickets, controlos e alterações.
• Destino: país, prefixo ou padrão de numeração aplicável e formato esperado.
• Operador ou rede: obrigatório apenas quando a condição tiver sido comprovada a esse nível.
• Rota ou relação comercial: identificador interno da rota e âmbito da condição.
• Tipo de tráfego: valor controlado, não uma etiqueta livre.
• Tipo e valor do remetente: classe de remetente, restrições de comprimento ou formato e capacidade de resposta quando aplicável.
• Conteúdo: requisitos de modelos, links, domínios, encurtadores, idiomas ou categorias não admitidas.
• Conectividade: protocolo, parâmetros ou limitações de integração que afetem a aceitação operacional do tráfego, quando documentados para a rota específica.

Declarada, verificada e pendente de confirmação

A qualidade de uma matriz depende tanto do que regista como da forma como expressa o grau de certeza. Uma regra declarada por um fornecedor, um requisito confirmado por documentação oficial e uma condição observada num teste não têm o mesmo valor probatório.

Utilize estados de evidência explícitos. Isto evita que uma equipa transforme uma afirmação comercial num facto comprovado, ou que uma observação técnica limitada se torne numa regra universal. O estado deve acompanhar cada restrição, não ficar numa nota geral da rota.

• Declarada: condição comunicada pela contraparte, pendente de validação independente ou de evidência documental suficiente.
• Verificada: condição suportada por uma fonte primária, uma aprovação documentada, uma cláusula aplicável ou evidência operacional com âmbito definido.
• Pendente de confirmação: informação incompleta, contraditória, expirada ou cuja aplicabilidade ao caso de uso não é clara.
• Não aplicável: a condição foi avaliada e não corresponde ao âmbito dessa ficha; deve incluir justificação.
• Retirada ou substituída: regra histórica que não deve ser utilizada em novas decisões, mantida para auditoria.

Sender ID, pré-registo e capacidade de resposta

O remetente deve ser documentado como um objeto sujeito a regras, e não como um texto inserido no fim do fluxo. A ficha deve indicar que tipo de remetente será utilizado, se é permitido no destino, se necessita de registo prévio e que evidência demonstra o seu estado.

Os Sender ID alfanuméricos merecem atenção específica. São utilizados para mensagens unidirecionais e não devem ser tratados como um canal de resposta. A documentação da Twilio indica que os Sender ID alfanuméricos não estão disponíveis para destinos nos Estados Unidos nem no Canadá; esta condição corresponde ao fornecedor documentado e não deve ser automaticamente extrapolada para outras rotas ou fornecedores.

Quando existir pré-registo, registe o identificador do pedido ou da campanha, o estado, a data de aprovação, a entidade aprovadora, a data de expiração, caso exista, e as mensagens ou domínios abrangidos. Um remetente ativo ou registado não demonstra, por si só, que todo o tráfego associado é admissível.

• Nome ou valor do remetente solicitado e valor efetivamente aprovado.
• Tipo de remetente e indicação de se aceita mensagens recebidas ou respostas.
• Requisito de pré-registo por destino e estado do processo.
• Marca, caso de uso, exemplos de mensagens, links e palavras-chave quando fizerem parte do processo aplicável.
• Data de ativação, validade, renovação e responsável pela revisão do estado.
• Restrições entre o remetente e uma campanha, um domínio, um tipo de tráfego ou uma rota específica.

Classifique o tráfego antes de aplicar regras

A categoria de tráfego não deve ser um campo livre como “transacional” sem definição. Uma classificação controlada permite aplicar restrições consistentes e detetar quando um fluxo misto exige revisão adicional.

No contexto de campanhas A2P dos Estados Unidos, as categorias documentadas incluem 2FA, notificações de conta, apoio ao cliente, alertas de fraude, marketing e campanhas mistas. A classificação exata aplicável dependerá do destino, do enquadramento de registo e da rota; por isso, a matriz deve preservar o catálogo utilizado e a sua fonte.

Para tráfego recorrente, a documentação deve separar o mecanismo de adesão, o mecanismo de cancelamento e a assistência. No guia do The Campaign Registry, o opt-in é obrigatório para quase todos os tipos de campanha, e os elementos de opt-out e HELP têm requisitos próprios. Nos Estados Unidos, os pedidos de revogação de consentimento sujeitos à TCPA devem ser tratados como eventos operacionais: a FCC exige que sejam atendidos num prazo razoável que não exceda dez dias úteis após a receção.

• OTP ou 2FA: defina o evento que gera o código, a validade esperada e o remetente autorizado.
• Alertas transacionais: descreva o evento de conta, encomenda, segurança ou serviço que ativa a mensagem.
• Marketing com consentimento: documente o fluxo de consentimento, a frequência, a mensagem de adesão, o cancelamento e a ajuda quando aplicável.
• Apoio ao cliente: delimite se existe conversa, qual o remetente utilizado e que conteúdo é permitido.
• Tráfego não admitido: utilize uma categoria explícita para proibições confirmadas; não a deixe como uma exceção implícita.
• Tráfego misto: exija revisão humana se combinar finalidades ou se a classificação não for clara.

Conteúdo, links e mecanismos de cancelamento

O conteúdo deve ser avaliado como texto final renderizado. As variáveis de personalização podem introduzir caracteres, links ou comprimento adicional que não estavam no modelo base. Validar apenas o modelo incompleto pode resultar numa classificação incorreta da codificação ou no incumprimento de uma condição de rota.

Documente separadamente as restrições de conteúdo verificadas para cada destino ou campanha: modelos exigidos, mensagens de exemplo aprovadas, domínios, links, encurtadores, marcas e palavras-chave. Se não houver evidência suficiente sobre uma categoria, assinale a condição como pendente de confirmação e não a transforme numa proibição ou permissão universal.

Uma DLR com estado de entrega não valida o conteúdo, o consentimento, o pré-registo nem a adequação de uma campanha. Trata-se de um estado de entrega comunicado pela cadeia de mensagens; a conformidade requer as suas próprias evidências.

• Guarde os exemplos aprovados juntamente com a versão da campanha ou do remetente.
• Registe domínios e links permitidos quando o enquadramento aplicável o exigir.
• Não presuma que um encurtador é permitido apenas porque outro link foi aceite.
• Para campanhas recorrentes, relacione as instruções de cancelamento e ajuda com a evidência do fluxo de adesão.
• Registe os pedidos de cancelamento recebidos, a sua data de receção, o sistema responsável e a data de execução.
• Distinga uma DLR apresentada por um fornecedor da receção verificada de forma independente no terminal; não são equivalentes.

Limites técnicos: documentar sem prometer entrega

Os limites técnicos são necessários para decidir se uma mensagem pode ser processada como esperado, mas não devem ser apresentados como garantias de entrega. A implementação técnica do SMS é regida por especificações como a 3GPP TS 23.040, que continua sujeita a alterações, enquanto os limites efetivos de uma plataforma ou rota podem acrescentar condições próprias.

Como referência técnica documentada pela Twilio, um SMS GSM-7 admite 160 caracteres num segmento e UCS-2 admite 70. Em mensagens concatenadas, as referências são 153 caracteres GSM-7 e 67 UCS-2 por segmento. Um único caráter fora do conjunto GSM-7 pode fazer com que a mensagem completa passe para UCS-2 e altere o número de segmentos.

A taxa de envio, a capacidade e o tempo em fila também exigem contexto. Um limite de TPS ou MPS deve incluir âmbito, data de verificação e condição aplicável, porque pode depender da conta, do remetente e do canal. Ultrapassar o limite pode provocar fila. A janela de validade também deve ser registada: uma fila pode expirar mais cedo se for definido um Validity Period menor. Na plataforma documentada pela Twilio, as mensagens não podem permanecer em fila por mais de dez horas.

• Codificação esperada: GSM-7, UCS-2 ou outra condição documentada pela plataforma.
• Comprimento e segmentação calculados com base no texto final renderizado.
• Política de concatenação e tratamento de mensagens multipartes.
• TPS ou MPS: valor, unidade, âmbito, fonte, data e comportamento ao ultrapassar o limite.
• Janela de validade: valor solicitado, limite admitido e consequência da expiração.
• DLR: estados disponíveis, origem do recibo e limitações de interpretação.