Регламент SMS-рассылок: роли, согласование и контроль запуска

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

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

Область действия

Начните с перечня систем и сообщений: личный кабинет Quicktel, CRM, API, 1С, сервисные интеграции, ручные и автоматические сценарии. Регламент действует и на единичное автоматическое SMS, если оно влияет на клиента или безопасность.

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

Классификация сообщений

До согласования каждое сообщение получает тип:

• OTP и безопасность;
• сервисное или транзакционное;
• информационное;
• рекламное.

От типа зависят основание отправки, приоритет, частота, шаблон, срок жизни и согласующие. Разделение сервисного и рекламного содержания подробно разобрано в статье как разделить SMS-сценарии.

Смешанные тексты отправляются на дополнительную проверку. Нельзя добавлять акцию в обязательное уведомление и считать весь текст сервисным.

Роли и ответственность

Минимальный набор ролей:

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

Один человек может совмещать роли в небольшой компании, но решения всё равно фиксируются. У каждой кампании и автоматического сценария есть конкретный владелец, а не «отдел маркетинга».

Карточка сценария

До первого запуска создайте карточку:

• цель и ожидаемое действие;
• тип сообщения и основание;
• аудитория и исключения;
• источник данных и стоп-лист;
• шаблон и переменные;
• Sender ID;
• время, частота, TTL и приоритет;
• лимит объёма и бюджета;
• метрики и окно атрибуции;
• ответственный за мониторинг;
• стоп-условия и откат.

Автоматический сценарий дополнительно описывает событие-триггер, дедупликацию и поведение при повторе. Карточка получает версию и дату пересмотра.

Подготовка базы

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

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

Работа с шаблоном

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

После согласования версия неизменяема. Любая правка создаёт новую версию и повторяет нужную часть проверки. Базовые требования к структуре и ясности текста можно закрепить на основе статьи про SMS-шаблоны для бизнеса.

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

Тест и запуск

Сначала сообщение уходит на контролируемые номера основных операторов. Команда проверяет Sender ID, текст, переменные, ссылку, сегменты, время и DLR. Затем выполняется малый canary на части аудитории.

Перед полным запуском оператор сверяет:

1. Утверждённую карточку и версию шаблона.
2. Итоговый размер аудитории и исключения.
3. Время и частотные ограничения.
4. Бюджет и лимиты.
5. Состояние очередей, маршрутов и мониторинга.
6. Контакты ответственных и кнопку паузы.

Двойное подтверждение особенно полезно для большой кампании или изменения критичного автоматического сценария.

Мониторинг и стоп-условия

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

Стоп-условия должны быть конкретными. «Если что-то пойдёт не так» не работает. Примеры: неверная подстановка, рост постоянных ошибок выше порога, расход быстрее бюджета, жалоба на чужие персональные данные, нарушение SLO критичного трафика.

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

Инциденты и изменения

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

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

Изменения API, провайдера, закона, структуры компании и каналов запуска требуют внепланового пересмотра.

Доступы и аудит

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

API-ключи хранятся вне документов и чатов, регулярно пересматриваются и отзываются после миграции. Выгрузки с номерами имеют ограниченный срок и доступ. Регламент описывает не секреты, а безопасный способ работы с ними.

Периодические проверки

Раз в согласованный период владелец просматривает активные сценарии, роли, шаблоны, ссылки, лимиты и неиспользуемые доступы. Автоматический сценарий без запусков не обязательно безопасен: его старый ключ и шаблон всё ещё могут быть активны.

Учебный запуск проверяет паузу кампании, контакт дежурного и восстановление после тестовой ошибки. Результат фиксируется, а не остаётся устным подтверждением «вроде работает».

Исключения

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

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

Как сделать документ живым

Регламент хранится рядом с фактическими инструкциями и конфигурацией, имеет владельца и историю версий. Ссылки ведут на работающие панели, шаблоны и runbook, а не на удалённые скриншоты.

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

Итог

Рабочий регламент — это короткий маршрут от цели до контролируемого запуска: классификация, владелец, база, версия шаблона, тест, бюджет, мониторинг и право остановки. Он не заменяет закон, техническую документацию и профессиональное решение, но делает их частью ежедневного процесса. Благодаря этому SMS запускаются одинаково предсказуемо независимо от того, кто сегодня выполняет операцию.