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 без связи».

Серьёзный покупатель спросит:

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

Двусторонняя доставка сообщений — это не просто техническая функция, а полноценный рабочий inbox, который требует выделенных сотрудников для обработки входящего потока. Прием и отправка ответов должны происходить строго в рамках единой идентичности номера, чтобы у пользователя не ломался контекст диалога.

Что нужно сделать на практике: обязательно протестируйте в консоли и убедитесь, что тестовый ответ от клиента гарантированно попадает в активный рабочий интерфейс поддержки, а не теряется в логах шлюза. Каждая сессия должна фиксироваться в системе учета. Главная ошибка — пытаться продать или подключить 2-way messaging как простой переключатель поверх существующего одностороннего буквенно-цифрового имени отправителя (one-way From), так как это технически невозможно без выделенного виртуального номера.

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

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