IOSOR

IOSOR Wiedza

Pętle autoodpowiedzi inbound: jak echo opróżnia portfel prepaid

Jak B2B utrzymuje dwukierunkowy SMS w uczciwości — STOP/HELP jako polityka, sufity autoodpowiedzi, dyscyplina webhooka inbound i dlaczego nieograniczone echo spala prepaid.

Autoodpowiedź inbound, która zawsze odpowiada, to nie «świetny CX». Na wynajętym DID to wyciek prepaid: dwa boty albo HELP cytujący oryginał mogą odbijać się, aż portfel się opróżni. Produkt widzi engagement. Finanse widzą dziurę. Ops dziedziczy incydent o 02:00 bez ownera.

IOSOR trzyma inbound na tej samej powierzchni prepaid white-label co outbound. Zdarzenia MO, odpowiedzi na słowa kluczowe i linie debetu żyją na koncie. Przy ok. USD 1,000+ miesięcznego użycia próbki pętli i debit na wątek stają się materiałem commercial review. Katalog live bez sufitu pętli to obietnica, której finanse nie obronią. Numer in setup nie jest skrzynką dwukierunkową. Nie ma wcześniej kupionej puli «czystszych» skrzynek do podmiany, gdy pętla startuje.

Pętle autoodpowiedzi opróżniają prepaid

Wzorzec Jak wygląda Efekt na portfel
Echo bot ↔ bot Dwa auto-ack odbijają się Nieograniczony outbound debit
HELP cytuje inbound Payload wychodzi jako nowa wysyłka Zdublowane segmenty
Ping-pong poza godzinami «Otrzymaliśmy SMS» przy każdym retry Nocne spalanie bez człowieka
Burza retry webhook Ten sam MO dwa razy Podwójna odpowiedź,

STOP/HELP przeciw nieograniczonemu echu

STOP i HELP to polityka, nie miłe boty. STOP musi honorować opt-out i zatrzymać wątek — w tym autoodpowiedzi. HELP ma być krótką, bezpieczną dla marki ścieżką z prawdziwymi godzinami, nie echem ostatniego zdania. Nieograniczone «otrzymaliśmy SMS» na każdym MO to nie HELP.

Sufity, które produkt i finanse obronią

  1. Sufit outbound na wątek — max autoodpowiedzi na DID + id klienta i okno.
  2. Idempotentne MO — jedno zdarzenie inbound, jedna odpowiedź, nawet gdy webhook retried.
  3. Cisza po STOP — bez marketingu, bez «czy na pewno», bez drugiego HELP.
  4. Halt przy niskim saldzie — reszta autoodpowiedzi zatrzymuje się przed teatrem overdraftu.

Uczciwość dwukierunkowej skrzynki

Dwukierunkowość to system operacyjny, nie przełącznik. Kto czyta pierwszy, które numery odbierają i wysyłają, co nigdy nie spada na kanał współdzielony, jak działają godziny martwe. Zobacz przewodnik po dwukierunkowej skrzynce i zdarzenia skrzynki na wynajętych numerach.

Czerwone flagi

  • Autonastęp bez sufitu na wątek
  • HELP powtarzający payload inbound
  • STOP wciąż odpalający ack marketingowy
  • Retry webhook podwójnie wysyłające odpowiedzi
  • Katalog live bez ownera pętli
  • Błędy z obcymi markami
  • Echo poza godzinami bez ścieżki ludzkiej

Start z IOSOR

Napiszcie teksty STOP i HELP, które support przeczyta na głos. Ustawcie sufit auto-odpowiedzi na wątek w stagingu, wymuście zdublowany webhook MO i potwierdźcie, że portfel widzi jedną odpowiedź, nie dwie. Zasymulujcie echo bota, aż wydatek się zatrzyma. Wyeksportujcie jeden łańcuch inbound → obciążenie, by finanse zobaczyły, gdzie pętla opróżniłaby saldo prepaid.

Podsumowanie IOSOR

Wejściowe echo to pożar portfela. Jeden MO daje jedną odpowiedź; zdublowany webhook albo ping-pong bota ma zatrzymać wydatek, nie go mnożyć.

Róbcie: ograniczcie odpowiedzi na wątek i rwijcie pętlę na echu. Nie róbcie: nielimitowanego auto-odpowiedzi na inbound ani dwóch obciążeń za ten sam MO.

Czy ten przewodnik był pomocny?

Powiązane przewodniki