Transacional, OTP ou marketing: estrutura operacional para classificar tráfego A2P SMS antes do envio
Um guia prático para classificar o tráfego A2P SMS de acordo com a sua finalidade, desencadeador, relação com o destinatário e conteúdo. Transforme cada caso de uso em controlos auditáveis antes de encaminhar ou enviar.

A classificação deve preceder o encaminhamento
A classificação do tráfego A2P SMS não é uma etiqueta comercial acrescentada no final do processo. É uma decisão de governação operacional que deve ocorrer antes da seleção de uma rota, de um remetente, de um modelo, de uma política de frequência ou de um tratamento de incidentes.
Um mesmo programa de mensagens pode conter casos de uso distintos. Por exemplo, o acesso a uma conta pode exigir um OTP, uma compra pode gerar uma confirmação funcional e uma campanha posterior pode promover produtos ou serviços. Agrupar os três sob uma etiqueta genérica como “notificações” dificulta a aplicação de controlos coerentes e a demonstração de que cada envio era adequado.
A decisão deve estar associada ao caso de uso, e não apenas à mensagem individual. Desta forma, operações, produto, conformidade e encaminhamento trabalham com uma definição comum que pode ser revista quando o modelo, o desencadeador, o país de destino ou a base de contactos mudarem.
- Classifique antes de enviar, e não após observar resultados técnicos.
- Aplique a classificação ao caso de uso e às respetivas regras de geração.
- Reveja a classificação quando o conteúdo, a finalidade, o destino ou o fluxo de produto mudarem.
- Não utilize uma categoria como argumento para contornar requisitos aplicáveis num mercado ou numa rota.

Três categorias operacionais: OTP, transacional e marketing
OTP, transacional e marketing descrevem finalidades operacionais diferentes. A distinção não depende apenas de uma palavra no texto, de uma etiqueta interna de campanha ou do facto de a mensagem ser enviada automaticamente.
Um OTP está associado a uma operação específica de autenticação ou recuperação e entrega um segredo de curta duração. Uma mensagem transacional comunica informação necessária perante um evento de serviço. Uma mensagem de marketing procura promover, persuadir ou incentivar uma ação comercial junto de uma audiência.
Estas categorias podem estar sujeitas a regras diferentes consoante o país, a operadora, a rota e a relação com o destinatário. Por isso, a classificação interna deve ser conservadora e não substitui a análise dos requisitos aplicáveis a cada destino.
- OTP: permite uma operação de autenticação ou recuperação através de um segredo de uso limitado.
- Transacional: informa sobre um evento de serviço e limita-se ao necessário para esse evento.
- Marketing: inclui uma finalidade promocional, persuasiva ou comercial, mesmo quando é enviada para contactos existentes.

O texto isolado não determina a categoria
Palavras como “código”, “confirmação”, “aviso” ou “oferta” fornecem indícios, mas não resolvem isoladamente a classificação. Uma mensagem com um código só é OTP se existir uma operação de autenticação específica que a desencadeie, se o código permitir concluir essa operação e se o fluxo aplicar controlos adequados de validade, utilização e tentativas.
Da mesma forma, uma confirmação de encomenda pode ser funcional se comunicar dados necessários sobre uma compra já efetuada. Se acrescentar venda cruzada, um desconto ou um convite para voltar a comprar, incorpora uma finalidade promocional que deve ser avaliada separadamente.
A classificação deve considerar todo o fluxo: quem recebe, que evento o ativa, que ação permite, que relação o justifica e que componente comercial contém.
- Não classifique uma mensagem como OTP apenas porque inclui números ou a palavra “código”.
- Não classifique uma campanha como transacional apenas porque é enviada a clientes existentes.
- Não mantenha uma classificação funcional se uma nova versão do modelo acrescentar persuasão comercial.
- Documente a relação entre a mensagem e o evento ou a transação que a desencadeia.
Quatro perguntas para classificar cada caso de uso
Uma estrutura repetível começa com quatro perguntas. Devem ser respondidas para cada caso de uso, modelo e destino relevante, e não através de pressupostos gerais sobre a marca ou o setor.
A primeira pergunta é o que desencadeia a mensagem. A segunda é que ação permite ou que informação necessária entrega. A terceira é que relação com o destinatário justifica o contacto. A quarta é se o conteúdo inclui valor promocional ou persuasivo.
Se as respostas mudarem devido a uma alteração de produto, a uma nova automatização ou a uma variante de modelo, o caso deve voltar a ser revisto.
- O que a desencadeia? Exemplos: pedido de acesso, compra concluída, alteração de estado de um serviço ou campanha planeada.
- Que ação permite? Autenticar, recuperar acesso, consultar uma informação de serviço, concluir uma ação contratual ou comprar.
- Que relação a justifica? Um pedido iniciado pelo utilizador, uma transação existente, uma relação de serviço ou uma base de contactos documentada.
- Que valor promocional inclui? Descontos, chamadas à compra, recomendações comerciais, incentivos ou venda cruzada.
Estrutura para OTP: autenticação específica, contexto e controlos de tentativas
Um OTP deve estar associado a uma operação específica de autenticação ou recuperação. O NIST descreve a autenticação fora de banda como uma operação associada entre o canal principal e o secundário, e não como o simples envio de um código por SMS. Assim, a classificação como OTP exige o registo do pedido que originou a mensagem e da ação que o segredo permitirá concluir.
O conteúdo deve ser breve e contextual. O destinatário deve conseguir reconhecer o serviço e o pedido ao qual o código corresponde. O NIST indica que as mensagens fora de banda devem incluir informação contextual, como o nome do serviço a que se está a aceder.
Os segredos devem ser concebidos para utilização limitada. O NIST estabelece que, na autenticação fora de banda, um segredo deve ser aceite uma única vez e que a autenticação não deve ser considerada válida se não for concluída em dez minutos. Também exige segredos aleatórios de, pelo menos, seis dígitos decimais ou equivalentes.
O controlo de tentativas não deve ser resolvido apenas pelo reenvio de mensagens. O NIST exige limitação de tentativas quando o segredo tem menos de 64 bits e indica que gerar um novo segredo não deve reiniciar o contador de tentativas falhadas. As regras de reenvio, validação e bloqueio devem pertencer ao fluxo de autenticação e estar correlacionadas com o evento original.
O SMS OTP não deve ser apresentado como autenticação resistente a phishing. O NIST indica expressamente que a autenticação fora de banda não é resistente a phishing. Quando a rede telefónica pública é utilizada para entregar um segredo, o NIST também exige alternativas de autenticação para os subscritores e recomenda considerar sinais de risco, como mudança de dispositivo, troca de SIM, portabilidade ou outros comportamentos anómalos antes do envio.
- Associe cada OTP a um pedido identificável de autenticação ou recuperação.
- Inclua contexto reconhecível sobre o serviço e a operação solicitada.
- Utilize um segredo aleatório, de uso único e com validade limitada.
- Aplique limites de tentativas e não reinicie o contador ao gerar um novo código.
- Controle reenvios e avalie sinais de risco antes de entregar o segredo, quando aplicável.
- Não acrescente descontos, ofertas, recomendações ou outros incentivos comerciais ao modelo OTP.
- Mantenha métodos alternativos de autenticação para os utilizadores.
Estrutura para mensagens transacionais: evento de serviço e informação indispensável
Uma mensagem transacional comunica informação necessária sobre um evento de serviço. Pode tratar-se, por exemplo, de uma confirmação de encomenda, uma alteração de estado, um alerta operacional ou um lembrete associado a uma relação de serviço. A classificação depende de o evento existir, ser identificável e justificar o envio.
O modelo deve limitar-se à informação indispensável para que o destinatário compreenda o evento ou atue sobre ele. Se o objetivo principal for informar sobre uma compra, um serviço ou uma ação já iniciada, a mensagem pode permanecer nesta categoria dentro de uma estrutura operacional. Se o modelo procurar gerar uma compra adicional, captar atenção comercial ou incentivar uma nova decisão, deve ser revisto como marketing ou como mensagem mista.
É aconselhável registar a referência ao evento: identificador de encomenda, incidente, marcação, conta ou processo interno, conforme aplicável. Não é necessário incluir todos esses dados no texto do SMS, mas deve existir evidência interna que permita relacionar o envio com o evento que o originou.
- Exija um desencadeador de serviço verificável.
- Limite o modelo a informação útil e necessária para esse evento.
- Conserve uma referência de correlação entre a mensagem e o evento de origem.
- Reveja qualquer alteração que introduza recomendações, incentivos, venda cruzada ou chamadas comerciais à ação.
- Não presuma que uma relação prévia elimina requisitos aplicáveis de privacidade ou comunicações comerciais.
Estrutura para marketing: promoção, persuasão e audiência documentada
Uma mensagem deve ser tratada como marketing quando a sua finalidade é promover uma oferta, persuadir a comprar, recomendar um produto ou serviço, reativar uma audiência ou incentivar uma ação comercial. A classificação continua a ser marketing mesmo que o destinatário já seja cliente, que a mensagem contenha informação útil ou que esteja programada como parte de uma automatização.
A operação deve documentar a finalidade promocional e a base de contactos aplicável ao destino. O regime de proteção de dados da União Europeia regula o tratamento de dados pessoais; por isso, reutilizar uma base para promoção exige que a finalidade e a base aplicável estejam devidamente registadas para o país em causa.
O marketing exige controlos específicos de audiência e supressão. Antes do envio, a equipa deve conseguir determinar que segmento recebe a comunicação, por que motivo é elegível, que restrições se aplicam e como serão tratadas as solicitações ou os estados de exclusão aplicáveis.
- Classifique como marketing descontos, ofertas, recomendações, convites à compra e campanhas de reativação.
- Mantenha documentadas a finalidade e a base de contactos aplicável ao destino.
- Aplique listas de supressão e regras de elegibilidade antes de construir a audiência final.
- Defina políticas de frequência e horários compatíveis com os requisitos aplicáveis e com a experiência esperada pelo destinatário.
- Reveja remetentes, modelos e rotas de acordo com as restrições do país e da conectividade utilizada.
Casos-limite e mensagens mistas
Os casos-limite exigem a análise da finalidade dominante e de cada componente do conteúdo. Uma confirmação de encomenda sem elementos promocionais pode ser transacional. A mesma confirmação com uma oferta de venda cruzada já contém um componente de marketing. Manter a etiqueta transacional apenas por incluir dados da encomenda não é uma decisão suficientemente prudente.
Um lembrete de renovação pode ser funcional se informar sobre uma data, um estado ou uma ação necessária num serviço existente. Se se transformar num convite para contratar uma melhoria, ampliar um plano ou aproveitar um desconto, deve ser revisto pelo seu componente promocional.
Os alertas de saldo, os convites e a recuperação de conta também exigem contexto. Um alerta de serviço pode ser funcional; um convite destinado a captar novos utilizadores tem normalmente uma finalidade promocional; e uma mensagem de recuperação de conta que acrescenta uma oferta não deve manter automaticamente uma classificação OTP ou transacional.
Perante uma mensagem mista, existem três alternativas operacionais prudentes: separar os envios, eliminar o componente promocional da mensagem funcional ou aplicar ao conjunto o regime mais restritivo que seja aplicável. A escolha deve ser documentada.
- Confirmação de encomenda com venda cruzada: separe a confirmação e a promoção ou trate o conjunto com os controlos de marketing aplicáveis.
- Lembrete de renovação: mantenha-o funcional apenas se informar sobre o serviço sem persuasão comercial adicional.
- Alerta de saldo: reveja se comunica um facto de serviço ou se incentiva uma compra ou recarga através de um incentivo.
- Convite: analise se é uma comunicação necessária numa relação existente ou uma ação de captação.
- Recuperação de conta com oferta: separe o segredo ou a instrução de recuperação de qualquer promoção.
Perguntas frequentes
Um SMS com um código numérico é sempre OTP?
Não. Deve estar associado a uma operação específica de autenticação ou recuperação, e o código deve permitir concluir essa operação. Também requer controlos de validade, utilização única, tentativas e contexto reconhecível.
Uma confirmação de encomenda pode incluir uma oferta e continuar a ser transacional?
Não deve manter automaticamente uma classificação transacional. A oferta acrescenta uma finalidade promocional. A opção prudente é enviar a confirmação funcional separadamente, eliminar a oferta ou aplicar à mensagem mista os controlos de marketing aplicáveis.
Um DLR entregue prova que a mensagem estava correta do ponto de vista da conformidade?
Não. Um DLR é um sinal técnico cujo significado depende da integração e da rede. Não prova que o tráfego foi corretamente classificado, que existia uma base de contactos válida quando necessária, nem que o destinatário leu a mensagem no terminal.
Uma consulta HLR prova consentimento, identidade ou titularidade do número?
Não. Uma consulta HLR não prova consentimento, identidade, titularidade do número nem entrega garantida. A elegibilidade para enviar deve basear-se nos registos e controlos aplicáveis ao caso de uso e ao destino.
O que deve ser revisto quando um modelo de SMS muda?
Devem ser revistos a finalidade, o desencadeador, a relação com o destinatário, o componente promocional, a categoria atribuída, o remetente permitido, as regras de frequência, a supressão e as restrições de rota aplicáveis.
Fontes consultadas
- NIST SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator ManagementNational Institute of Standards and Technology (NIST)
- General Data Protection Regulation (GDPR) — resumen oficial y referencias al Reglamento (UE) 2016/679EUR-Lex / Publications Office of the European Union
- Data protectionEuropean Commission