IOSOR

IOSOR База знань

Вхідні SMS і 2-way messaging: inbox, який потягнуть продукт і підтримка

Як B2B запускає відповіді та call-події на орендованих номерах: володіння inbox, keywords, зв’язка send+receive, вебхуки MO, privacy і чесний prepaid.

Вихідний SMS — лише половина зрілого messaging. Щойно клієнт може відповісти — або орендований DID починає приймати call-події — потрібен inbound-контур, який захистять продукт, підтримка та compliance. Двосторонній messaging — це не «увімкнули MO і сподіваємось». Це операційна система: хто володіє inbox, які номери вміють приймати й надсилати, куди падають вебхуки і що законно зберігати.

Гід для B2B-команд, які орендують бізнес-номери під підтримку, OTP-fallback, callback і діалоги — і не хочуть жити в чужому брендовому кабінеті.

Що реально входить у «inbound»

Сигнал Навіщо ops
MO SMS / відповіді Треки підтримки, STOP, намір клієнта
Keywords / короткі команди Маршрутизація HELP, STOP, START без «знань старожилів»
Call-події на орендованому DID Пропущений / відповідений дзвінок, тривалість — якщо voice у scope
Зв’язка з outbound Одна розмова, один customer ID, один audit trail

Спроєктуйте inbox до купівлі номерів

Продукт і підтримка мають узгодити одну операційну модель до першої оренди DID:

  1. Хто читає першим — agent console, тікети чи бот з ескалацією до людини?
  2. Хто володіє keywords — маркетинг vs регульовані STOP / HELP?
  3. Чого не можна класти в спільний канал — платежі, документи, меддані.
  4. Що після годин — auto-ack, черга чи жорсткий стоп із зрозумілою відповіддю клієнту.

Зв’яжіть номер на receive + send

Двосторонність ламається, коли прийом і відправка — «різні SKU без зв’язку».

Серйозний покупець запитає:

  • Чи може цей DID приймати SMS (і voice-події, якщо потрібно) і водночас бути вихідною ідентичністю там, де правила дозволяють?
  • Номер призначено на ваш акаунт після купівлі — а не «висить», поки хтось не клацне в чужому брендовому кабінеті?
  • Messaging-профіль і вебхуки керуються з тієї ж платформи, що й outbound?

Keywords, які підтримка пояснить одним реченням

Keywords — це політика, не милі автовідповіді.

Мінімум для більшості команд:

  • STOP / відписка — швидко виконати opt-out і залогувати для аудиту.
  • HELP / info — чистий brand-facing шлях допомоги (години, канал, ескалація).
  • Кампанійні / локальні команди — лише після підпису продукту й legal.

Зафіксуйте власників. Збій STOP у проді — compliance-інцидент, не «полагодьте бота».

Червоні прапорці

  • Щоденні відповіді вимагають логіну в чужий брендовий кабінет
  • Відправка є, inbound-вебхуки — «фаза два»
  • STOP / HELP не визначені або правляться будь-ким
  • «Activated», поки receive ще не доведено
  • Зберігання тіл вхідних без retention і політики доступу
  • Каталог кричить «global 2-way», а потрібні країни в setup
  • Підтримка не відрізняє funding failure від кривого webhook

Почати з IOSOR

Пов’язані: цикли inbound auto-reply Буферизація вхідних вебхуків для захисту від затримок операторів prepaid-резерв до першого списання.

Підсумок IOSOR

Двосторонність — скринька, яку можна укомплектувати. Прийом і відправлення ділять одну особистість номера.

Робіть: доведіть, що одна відповідь сіла в укомплектовану скриньку. Не робіть: продавати двосторонність як тумблер на односторонньому From.

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

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