Политика STOP и HELP не является логикой входящего инбокса

Политика STOP и HELP не является логикой входящего инбокса.

Разделение регуляторных политик и логики инбокса

Обработка сигналов отписки как стандартных входящих сообщений диалогового инбокса создает критические комплаенс-риски. В архитектуре телекома ключевые слова STOP, UNSUBSCRIBE, CANCEL и HELP являются юридическим выражением отзыва согласия, а не тикетами службы поддержки. Когда конечный абонент отправляет команду STOP через SMS, платформа обязана обработать токен на уровне политик мгновенно.

Мгновенный перехват ключевых слов на границе сети

При поступлении входящего MO-сообщения на выделенный номер формата E.164, платформа IOSOR анализирует пейлоад с помощью комплаенс-модуля до передачи события в пользовательский webhook. Если сообщение содержит стоп-токен, система немедленно фиксирует отписку в реестре, генерирует финальное подтверждающее SMS, блокирует исходящую отправку и возвращает структурированный DLR и webhook-ивент.

JIT-выделение номеров и учет списаний MRC

Номера в вашей white-label инфраструктуре не хранятся в статичных пулах. IOSOR использует модель JIT (Just-In-Time) с механизмом prepaid hold и assign. При привязке виртуального номера E.164 к профилю трафика ежемесячный сбор MRC списывается непосредственно с баланса. При этом записи об отписках фиксируются на уровне бренда и кампании, а не только конкретного номера.

Контроль баланса: порог USD 20 и ревью при USD 1,000

Автоматическое соблюдение политик требует стабильности биллинга. IOSOR устанавливает несгораемый порог баланса в USD 20 для гарантированного выполнения обязательных системных ответов на команды HELP и STOP. Если баланс опускается ниже лимита, генерация исходящего промо-трафика останавливается, но шлюз супрессии продолжает функционировать. При достижении оборота около USD 1,000/месяц платформа инициирует мягкий аудит метрик доставляемости и корректности обработки DLR.

Архитектурные границы и техническая документация

Четкое разграничение системных политик и прикладной логики необходимо для отказоустойчивой работы. Ознакомьтесь со связанными руководствами по конфигурации и комплаенсу:

Связанные материалы: Остановка после постановки в очередь: пропуск без ложной доставки · Права TCPA и CASL перед запуском SMS в продакшн · prepaid-резерв до первого списания.

Начните с IOSOR

Откройте консоль IOSOR и перейдите в раздел настройки входящего трафика (Inbound MO), чтобы перенести обработку системных команд STOP и HELP на уровень краевых compliance-правил. Настройте шлюз перехвата так, чтобы сигналы отписки немедленно изменяли статус согласия в реестре до отправки события на внешние вебхуки. Проверьте DLR-уведомления и убедитесь, что сообщения с отпиской блокируются шлюзом автоматически, не попадая в интерфейсы клиентских диалогов.

Итог IOSOR

Данный материал доказывает, что ключевые слова отписки (STOP, CANCEL, HELP) являются юридическими границами согласия получателя, а не контентом для диалоговых вложенных папок поддержки. Обработка этих команд на уровне инфраструктуры IOSOR исключает человеческий фактор, предотвращает повторные отправки на отписавшиеся номера E.164 и защищает маршруты от штрафных санкций операторов.

Не используйте пользовательские приложения или входящие папки службы поддержки для разбора и применения регуляторных ключевых слов. Разделяйте зоны ответственности: правила согласий и перехват MO-команд должны исполняться на краевом уровне шлюза compliance, оставляя пользовательскому слою только валидный контекстный трафик.