IOSOR Guias

Faturação MO inbound versus MT outbound: linhas de carteira bidirecionais no mesmo ledger prepaid

Respostas, STOP e eventos do número alugado debitam. Se finanças só modelou outbound, o ledger mente. Um produto bidirecional deve ver MO e MT na mesma exportação, com teto de auto-resposta.

O pitch fala de outbound. Em produção o número alugado recebe respostas, STOP e por vezes retornos de voz, e aparecem linhas que finanças não pôs no modelo. O MO inbound não é um favor grátis. Um produto bidirecional move MT e MO no mesmo ledger prepaid. Se a exportação só conta «enviados», finanças trata o débito inbound como ruído até o uso perto de USD 1,000+ o tornar tema comercial.

IOSOR é prepaid white-label: outbound e inbound num ledger, erros client-safe, sem portal alheio no dia a dia. live é produção bidirecional; in setup não é uma caixa barata. Veja guia da caixa de entrada bidirecional e eventos de caixa em números alugados. Primeiro evidência, depois escala.

Débitos MO que finanças não planeou

Se o modelo financeiro só multiplica a tarifa MT, omite as linhas MO do número alugado: SMS inbound, acusos de palavra-chave, por vezes eventos de voz. Essas linhas debitam quando a resposta chega, não no calendário de marketing. Produto diz «somos bidirecionais»; finanças pergunta «que linha é inbound». Sem resposta não há controlo.

Direção O que a carteira vê O que o produto costuma omitir
MT outbound Unidades / segmentos de envio Que inbound também debita
MO inbound Unidades inbound + resposta de palavra-chave Correlação com o fio outbound
Auto-resposta Outro MT Teto de ciclo

MT versus MO na mesma exportação

Ponham MT e MO na mesma exportação: tempo, número, direção, débito, correlation ID. Finanças deve filtrar por direção, não misturar inbound numa média outbound. STOP/HELP é linha de cumprimento e também pode debitar. O ciclo de vida do número alugado liga-se à caixa: libertar o número deve cortar eventos inbound; senão aparecem linhas fantasma no mês seguinte. Não deixem uma média mundial esconder um corredor inbound caro.

O ciclo de auto-resposta esvazia a carteira

Uma auto-resposta sem teto transforma um MO numa fila de MT até esvaziar a carteira. Bot contra bot, HELP que cita o original, retries de webhook não idempotentes, drenam prepaid. Teto de respostas por fio e STOP como supressão imediata. Veja loops de auto-resposta inbound. Quando a política diz parar, a carteira para mesmo que o produto queira «confirmar outra vez». Amostras de ciclo perto de USD 1,000+ entram na leitura comercial, não num ticket às 02:00.

Eventos da caixa de entrada e correlação

A caixa é evidência, não brinquedo de chat. Cada evento inbound deve mostrar número, carimbo de tempo e corpo redigido com segurança, e ligar ao contexto outbound quando há fio. Ops precisa de uma fila de letra morta reproduzível, não despejar payloads a montante nos agentes. Sem correlação, finanças não explica o débito MO e o produto não prova que o bidirecional «funciona». Os alugueres seguem o mês de calendário UTC; o dono da caixa deve saber quando o número caduca.

Sinais de alerta

  • Modelo financeiro só com tarifa MT
  • Exportação que não distingue direção
  • Auto-resposta sem teto por fio
  • STOP tratado como conversa, sem supressão
  • Agentes a ver payloads a montante em cru
  • Número libertado com débitos inbound ainda vivos
  • Catálogo in setup prometido como produção bidirecional

Começar com IOSOR

Envie um MO de entrada e um MT de saída no mesmo DID alugado. Exporte as duas linhas de carteira e prove códigos de motivo distintos. Tape a auto-resposta para um inbound não cunhar MT sem limite. É honestidade de linhas prepaid de dois sentidos, não um relatório de mistura da semana de fatura nem um teto de armazenamento de média.

Conclusão IOSOR

MO e MT partilham carteira, não uma linha.

Faça: etiquete o débito de entrada à parte do de saída. Não faça: liquidar MO em MT nem esconder linhas de entrada até ao fim do mês.

Este guia foi útil?

Guias relacionados