IOSOR

IOSOR База знаний

Циклы inbound auto-reply: как эхо-боты опустошают prepaid-кошелёк

Как B2B держит двусторонний SMS честным — STOP/HELP как политика, потолки auto-reply, дисциплина inbound webhook и почему безграничное эхо сжигает prepaid раньше, чем кто-то заметит.

Inbound auto-reply, который всегда отвечает, — не «отличный CX». На арендованном DID это слив prepaid: два бота, два человека с auto-ack или HELP, который цитирует исходное сообщение, могут отскакивать, пока кошелёк не опустеет. Продукт видит «вовлечённость». Финансы видят дыру. Ops получает инцидент в 02:00 без владельца.

IOSOR держит inbound на той же white-label prepaid поверхности, что и outbound: MO-события, ответы на keywords и строки debit живут в вашем аккаунте. Около USD 1 000+ месячного platform usage выборки циклов и debit на тред становятся материалом коммерческого review. Каталог live без потолка цикла — обещание, которое финансы не защитят. Номер in setup — не двусторонний inbox.

Циклы auto-reply опустошают prepaid

Паттерн Как выглядит Эффект на кошелёк
Эхо bot ↔ bot Два auto-ack скачут бесконечно Безграничный outbound debit
HELP цитирует inbound Payload уходит как новая отправка Дубли сегментов
Пинг-понг вне часов «Мы получили SMS» на каждый retry Ночной burn без человека
Шторм webhook retry Один MO обработан дважды Двойной ответ, двойной debit

Inbound retry случаются. Если consumer не идемпотентен, каждый webhook retry становится ещё одним auto-reply. См. повторы входящего вебхука. Свяжите детекцию цикла с остановка при низком балансе, чтобы кошелёк остановил оставшиеся эхо.

STOP/HELP против безграничного эха

STOP и HELP — политика, не милые боты. STOP должен зафиксировать opt-out и остановить тред — включая auto-reply. HELP — короткий brand-safe путь с реальными часами, не эхо последней фразы клиента. Безграничное «мы получили SMS» на каждый MO — не HELP. Напишите страницу keywords до первой разговорной отправки; см. политика ключевых слов STOP и HELP. Если STOP «обычно работает», у вас удача, не политика.

Потолки, которые защитят продукт и финансы

  1. Потолок outbound на тред — максимум auto-reply на DID + customer id за окно.
  2. Идемпотентная обработка MO — одно inbound-событие, один ответ, даже при retry webhook.
  3. Тишина после STOP — ни маркетинг, ни «вы уверены», ни второй HELP.
  4. Стоп по низкому балансу — оставшиеся auto-reply гаснут до театра овердрафта.

Выгрузите один инцидент: inbound event → auto-reply → строка ledger. Если цепочку не достаёте — двустороннего контроля нет. Назначьте владельца потолка; без владельца он исчезнет в следующем спринте.

Честность двустороннего inbox

Двусторонность — операционная система, не тумблер. Кто читает первым, какие номера принимают и отправляют, что никогда не попадает в общий канал, как работают after-hours. См. гайд по двустороннему inbox и события inbox на арендованных номерах. JIT — search → hold → buy → assign; заранее купленного пула «чистых» inbox на подмену при цикле нет. Каталог in setup нельзя продавать как укомплектованный inbox.

Красные флаги

  • Auto-reply без потолка на тред
  • HELP, который повторяет inbound payload
  • STOP, после которого всё ещё уходит marketing ack
  • Retry webhook, которые двойно шлют ответы
  • Каталог live без владельца цикла
  • Ошибки с чужими брендами
  • Эхо вне часов без человеческого пути

Старт с IOSOR

Напишите тексты STOP и HELP, которые support прочитает вслух. Поставьте потолок auto-reply на тред в staging, затем принудительно продублируйте MO webhook и убедитесь, что кошелёк видит один ответ, не два. Сымитируйте эхо бота, пока трата не остановится. Выгрузите одну цепочку inbound → debit, чтобы финансы увидели, где цикл опустошил бы prepaid-баланс.

Итог IOSOR

Входящее эхо — пожар кошелька.

Был ли материал полезен?

Связанные гайды