Стоп-лист SMS: как синхронизировать отказы во всех рассылках

Стоп-лист SMS — это единый источник запрета на определённые коммуникации, а не файл с номерами после последней кампании. Он должен применяться к автоматическим сценариям, ручным выгрузкам, разным отделам и внешним подрядчикам непосредственно перед отправкой.

Какие причины хранить

• отказ получателя от рекламы;
• жалоба;
• неверный или чужой номер;
• просьба клиента не использовать конкретный канал;
• внутреннее исключение на время спора;
• техническая блокировка;
• запрет по категории или бренду.

Причина определяет область действия. Ошибочный номер блокируется полностью, а отказ от рекламы не следует автоматически трактовать как запрет ожидаемого кода входа.

Нормализация номера

Один телефон может храниться как 8..., +7... и набор цифр с пробелами. Перед сравнением приводите его к единому международному формату. Иначе запись в стоп-листе не совпадёт с номером из другой CRM.

Не удаляйте историю при форматировании. Храните нормализованное значение, исходный ввод и результат проверки.

Категории сообщений

Минимально разделите рекламные, сервисные и сообщения безопасности. Пограничные шаблоны заранее классифицируются ответственным сотрудником. Подробный подход к сервисным и рекламным SMS нужно зафиксировать в правилах коммуникации компании.

Стоп-запись содержит категорию, источник, дату, область действия и при необходимости срок. Свободный комментарий без машинного признака система не сможет применить.

Источники отказа

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

Если ответы на SMS поддерживаются, команда отказа обрабатывается автоматически и подтверждается нейтральным сообщением. Варианты написания и ошибки должны учитываться осторожно, чтобы обычный ответ не стал случайным глобальным отказом.

Проверка в момент отправки

Сегмент устаревает сразу после формирования. Поэтому worker проверяет стоп-лист для каждого получателя непосредственно перед обращением к HTTP API QUICKTEL. Удаление номера только на этапе выборки недостаточно.

Результат проверки журналируется: какая версия правила применена и почему адресат исключён. Сам факт нахождения в стоп-листе не должен попадать в текст сообщения.

Ручные рассылки и подрядчики

Загрузка CSV проходит через тот же шлюз. Если сотрудник может отправить файл в обход проверки, единый стоп-лист фактически не работает. Ограничьте права и запретите использование личных сервисов.

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

Повторное согласие и снятие блокировки

Не удаляйте старую запись бесследно. Создайте новое событие с источником и датой, которое изменяет активный статус. Для неверного номера повторное включение требует подтверждения владения. Временная внутренняя пауза завершается только после проверки причины.

Несколько брендов и организаций

Определите область отказа: конкретная категория, бренд или рекламораспространитель. Пользователь должен понимать, от чего отказывается. Техническая модель не должна автоматически расширять или сужать его решение.

Контроль и аудит

Регулярно тестируйте номер из стоп-листа во всех путях: автоматическом, ручном, повторной кампании и импорте из другой CRM. Настройте сигнал, если заблокированный адресат дошёл до этапа отправки.

Архитектура высокой доступности

Если центральный стоп-лист временно недоступен, рекламная очередь должна безопасно остановиться, а не считать отсутствие ответа разрешением. Для ожидаемых критичных уведомлений заранее определяют отдельный режим и минимальный локальный набор запретов, например ошибочные номера.

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

Защита от случайного удаления

Права на снятие блокировки ограничиваются. Массовое удаление требует подтверждения и отчёта, а восстановление выполняется из истории событий. Обычная синхронизация CRM не должна перезаписывать более новый отказ пустым полем из старой системы.

Для слияния двух профилей выбирается более строгое активное правило до ручной проверки. Разделение профиля также не должно терять исходный запрет.

Отчёт для владельца процесса

Полезный отчёт показывает новые отказы по источникам, время распространения, попытки отправки после запрета и операции снятия. Он не используется для повторного маркетинга по людям, которые уже отказались.

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