SMS entrantes e mensagens bidirecionais: caixas de entrada que produto e suporte conseguem operar

SMS de saída é apenas metade de um produto de mensagens sério. No momento em que um cliente pode responder — ou um DID alugado começa a receber eventos de chamada — precisa de um caminho inbound que produto, suporte e compliance possam defender. Mensagens bidirecionais não são «ativar MO e rezar». É um sistema operativo: quem possui a inbox, que números recebem e enviam, onde caem os webhooks e o que pode armazenar legalmente.

Este guia destina-se a equipas B2B que alugam números empresariais para suporte, fallbacks OTP, callbacks e tráfego conversacional — e recusam operar o dia a dia dentro do portal de marca de terceiros.

O que «inbound» inclui de facto

Para a maioria dos compradores CPaaS prepaid, inbound significa mais do que um interruptor verde:

| Sinal | Porque o

Desenhe o caminho da inbox antes de comprar números

Produto e suporte devem acordar um único modelo operacional de inbox antes do primeiro aluguer de DID:

Ligue números para receber + enviar (mesma identidade comercial)

Two-way quebra quando receção e envio são tratados como SKUs sem relação.

Compradores sérios perguntam:

Keywords que suporte consegue explicar numa frase

Keywords são política, não autorespostas fofas.

Conjunto mínimo para a maioria das equipas:

• STOP / cancelar subscrição — honrar opt-out prontamente; registar para auditoria.
• HELP / info — responder com caminho de ajuda limpo orientado à marca (horário, canal, escalada).
• Comandos de campanha ou locale — só se produto e legal assinaram o texto.

Webhooks para mensagens MO (e porque capturas falham)

Inbound sem webhooks torna-se conhecimento tribal.

Exija:

• Eventos inbound autenticados / assinados que a sua stack consiga verificar
• Tratamento idempotente (retries acontecem)
• Payloads claros: from, to, body, timestamp, ID de atribuição do seu número
• Forma de reinspecionar MO recentes quando suporte diz «o cliente respondeu mas não vemos nada»

Começar com IOSOR

Desenhe a inbox antes de alugar: receber e enviar numa identidade atribuída, um webhook MO vivo, política de palavras e retenção. Prove que uma resposta do cliente vira uma linha que um agente responde. É o modelo operativo bidirecional — não um aluguer porque o megafone não aceita respostas, não só o texto STOP/HELP, nem um corte de classe TF versus local.

• Inbound no segundo mês: Carga de MO no mesmo DID alugado
• Revisão de volume inbound: carga de palavras-chave que esgota a carteira
• O limite da subconta é uma parada total, não um estouro silencioso

Conclusão IOSOR

O bidirecional é uma inbox que se pode dotar. Receber e enviar partilham uma identidade de número.

Faça: prove que uma resposta aterra numa inbox dotada. Não faça: vender bidirecional como um interruptor num From de um sentido.