IOSOR

IOSOR Guias

Loops de auto-resposta inbound: como o eco esvazia a carteira pré-paga

Como equipas B2B mantêm o SMS bidirecional honesto — STOP/HELP como política, tetos de auto-resposta, disciplina do webhook inbound e por que o eco sem limite queima o pré-pago.

Uma auto-resposta inbound que responde sempre não é «ótimo CX». Num DID alugado é um dreno pré-pago: dois bots ou um HELP que cita o original podem saltar até a carteira esvaziar. Produto vê engagement. Finanças vê um buraco. Ops herda um incidente às 02:00 sem dono.

A IOSOR mantém inbound na mesma superfície pré-paga white-label que outbound: eventos MO, respostas de palavras-chave e linhas de débito vivem na sua conta. Perto de USD 1,000+ de uso mensal, amostras de loop e débito por fio tornam-se material de revisão comercial. Catálogo live sem teto de loop é uma promessa que finanças não defende. Um número in setup não é uma caixa bidirecional. Não há lote pré-comprado de caixas «mais limpas» para substituir quando o loop começa.

Loops de auto-resposta drenam o pré-pago

Padrão O que parece Efeito na carteira
Eco bot ↔ bot Dois auto-ack saltam sem fim Débito outbound sem teto
HELP que cita inbound Payload sai como envio novo Segmentos duplicados
Ping-pong fora de horário «Recebemos o SMS» em cada retry Queima noturna sem humano
Tempestade de retry webhook O mesmo MO duas vezes Resposta dupla, débito duplo

STOP/HELP contra o eco sem limite

STOP e HELP são política, não bots fofos. STOP deve honrar o opt-out e parar o fio — incluindo auto-respostas. HELP deve ser um caminho curto e brand-safe com horários reais, não um eco da última frase. Um «recebemos o SMS» sem limite em cada MO não é HELP.

Tetos que produto e finanças podem defender

  1. Teto outbound por fio — máximo de auto-respostas por DID + id de cliente e janela.
  2. Tratamento MO idempotente — um evento inbound, uma resposta, mesmo se o webhook reintentar.
  3. Silêncio após STOP — nem marketing, nem «tem a certeza», nem segundo HELP.
  4. Paragem por saldo baixo — o resto das auto-respostas para antes do teatro de sobregiro.

Honestidade da caixa bidirecional

Bidirecional é um sistema operativo, não um interruptor. Quem lê primeiro, que números recebem e enviam, o que nunca cai num canal partilhado, como funcionam as horas mortas. Veja guia da caixa de entrada bidirecional e eventos de caixa em números alugados. JIT é procurar → reter → comprar → atribuir.

Sinais de alerta

  • Auto-resposta sem teto por fio
  • HELP que repete o payload inbound
  • STOP que ainda dispara um ack de marketing
  • Retries de webhook que enviam respostas a dobrar
  • Catálogo live sem dono do loop
  • Erros que despejam marcas alheias
  • Eco fora de horário sem caminho humano

Começar com a IOSOR

Escreva textos STOP e HELP que o suporte consiga ler em voz alta. Ponha um teto de auto-resposta por fio em staging, force um webhook MO duplicado e confirme que a carteira vê uma resposta, não duas. Simule um eco de bot até o gasto parar. Exporte uma cadeia inbound → débito para as finanças verem onde o ciclo teria esvaziado o saldo prepaid.

Conclusão IOSOR

Um eco de entrada é fogo na carteira. Um MO deve produzir uma resposta; um webhook duplicado ou um pingue-pongue de bot deve parar o gasto, não multiplicá-lo.

Faça: limite respostas por fio e mate o ciclo no eco. Não faça: auto-resposta ilimitada no inbound nem debitar o mesmo MO duas vezes.

Este guia foi útil?

Guias relacionados