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

Вхідне ехо — пожежа гаманця. Один MO дає одну відповідь; дубль webhook або пінг-понг бота мають зупинити витрату, а не помножити її.

Чи був матеріал корисним?

Пов’язані гіди