IOSOR

IOSOR База знаний

STOP/HELP на арендованном DID: policy, которой верит support

Как B2B пишет policy STOP/HELP на арендованных номерах — владельцы, формулировки, audit-логи и prepaid-честность без привычки жить в third-party portal.

Ключевые слова STOP и HELP на арендованном DID — это не просто автоответчики, а обязательные элементы комплаенса и репутации вашего бренда. Служба поддержки должна четко понимать эти регламенты, чтобы уверенно отвечать пользователям в любое время, не придумывая правила на ходу. Без такой политики двусторонняя переписка рискует превратиться в бесконечный поток неразрешенных инцидентов. Узнайте больше о настройке inbound-сообщений, чтобы сохранить контроль над коммуникациями.

Keywords — это policy, а не бот «сбоку»

Product, legal и support подписывают одну страницу до первого conversational send:

Keyword Обязательный исход Owner
STOP / unsubscribe Opt-out быстро; залогирован Compliance + messaging ops
HELP / info Brand-safe путь: часы, канал, escalation Support lead
START / resume (если есть) Re-opt только с ясным consent Product + legal
Campaign commands Опционально; никогда не перекрывают STOP Campaign owner

Если STOP «обычно работает» — у вас нет policy, есть удача.

STOP, который support может прочитать вслух

Ответ на STOP — короткий, brand-facing, однозначный:

  • Подтвердите opt-out для этой программы / identity
  • Скажите, что останавливается (алерты, marketing-класс, тред на этом DID)
  • Дайте human path, если помощь всё ещё нужна
  • Не светите технические ID и чужие бренды

Лог: кто прислал STOP, какой DID, когда исполнено, какие outbound-классы блокируются. Эскалации support тянут лог из вашей платформы — не из скриншотной охоты.

HELP, который совпадает с реальными часами

HELP — место, где бренды over-promise.

  1. Реальными часами поддержки и timezone
  2. Каналами, которые вы реально штатуете (email, chat, callback)
  3. Тем, что клиент должен указать (последние 4 цифры номера, order id)
  4. Следующим шагом, если никто не online

Арендованный DID, отвечающий HELP мёртвым email, учит пользователей жаловаться громче в соцсетях — и жжёт доверие быстрее позднего OTP.

Ownership и audit trail

Назовите primary owner и backup. Когда STOP ломается в production — это compliance-инцидент, не тикет «подкрутить бота».

Нужно:

  • MO webhook или inbox-событие, проверяемое вашим стеком
  • Идемпотентная обработка (retries бывают)
  • Корреляция: inbound keyword → customer id → suppression state
  • Правила retention для тел keyword, где может быть PII

White-label значит: агенты живут на одной коммерческой поверхности. «Проверь другой portal» — не operating model.

STOP/HELP разваливаются, если receive и send — «разные SKU».

  • Арендованный DID может принимать MO и отправлять там, где правила позволяют
  • Assignment на ваш аккаунт после покупки — не «висит», пока кто-то кликнет где-то ещё
  • Webhook destinations совпадают с платформой outbound

Путь номеров IOSOR — prepaid и just-in-time: search, hold, buy, assign. Keyword-readiness — часть этой assignment-истории.

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

  • STOP-ответ называет чужой portal
  • Часы HELP не совпадают со штатом
  • Нет лога момента opt-out
  • Keywords правят marketing live без legal review
  • Live conversational claims, пока inbound ещё in setup
  • Клиентские ошибки с дампом чужих брендов

Старт с IOSOR

Напишите одну страницу STOP и HELP, которую support прочитает вслух на арендованном DID. Подключите оба слова, докажите по одной audit-строке и назовите HELP вне часов. Это произносимая policy на одном номере, не изоляция списков opt-out арендаторов, не оценка спама на входе и не архитектура двустороннего inbox.

Связанные: циклы inbound auto-reply Буферизация входящих вебхуков для защиты от задержек операторов prepaid-резерв до первого списания.

Итог IOSOR

STOP и HELP — произносимая policy на арендованном DID, не синхронизация opt-out между арендаторами.

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

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