Версионирование SMS-шаблонов: переменные, согласование и откат

Версионирование SMS-шаблонов превращает текст сообщения в управляемый объект: у него есть назначение, владелец, переменные, дата действия, история согласований и возможность отката. Без этого сотрудник меняет одну строку «на лету», а через неделю никто не может объяснить, почему часть клиентов получила другой текст или сообщение внезапно стало двухсегментным.

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

Что хранить в реестре

Каждый шаблон получает стабильный ID и отдельные версии. Рядом фиксируют:

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

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

Схема переменных

Переменная — это контракт, а не произвольная подстановка. Для каждой задайте тип, обязательность, максимальную длину, допустимые символы и поведение при отсутствии. Например, order_number — непустая строка до заданной длины, а pickup_date — дата в согласованном формате.

Перед рендерингом данные валидируют и экранируют по правилам канала. Не допускайте подстановку переносов строк, управляющих символов и необработанного пользовательского текста, если сценарий этого не требует.

У шаблона должны быть тестовые наборы: минимальные, максимальные и некорректные значения. Особенно важно проверить длинные фамилии, названия компаний, адреса и ссылки.

Длина после подстановки

Количество сегментов зависит от итогового текста, а не от короткого шаблона с {name}. Проверяйте несколько реальных границ и рассчитывайте кодировку после подстановки. Кириллица, emoji и некоторые символы меняют вместимость сегмента; подробности есть в статье про длину SMS.

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

Согласование

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

Согласуется конкретная версия с контрольной суммой, а не «примерно такой текст». После одобрения изменить её нельзя: любое редактирование создаёт новую версию и новый цикл проверки. Это защищает от незаметной правки между согласованием и запуском.

Единый порядок ролей можно закрепить в регламенте SMS-рассылок.

Активация без мгновенной замены

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

Версию выбирают в момент создания задачи и записывают в неё явно. Если очередь обрабатывается долго, изменение «активного шаблона» не должно переписать уже сформированное уведомление без решения. Для каждого сценария заранее определите: задача хранит готовый текст или template ID, version и набор параметров.

Откат

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

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

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

Связь с Sender ID и провайдером

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

При переезде на новый SMS-шлюз перенесите реестр разрешений и сопоставьте ограничения. Иначе технически исправная интеграция начнёт получать отклонения на production-трафике.

Аудит и метрики

В логах SMS сохраняйте template ID и version, но не обязательно полный текст. Это позволяет связать всплеск ошибок или стоимости с конкретной правкой.

Полезно контролировать:

• долю отправок по версиям;
• ошибки рендеринга и отсутствующие переменные;
• распределение числа сегментов;
• отклонения маршрута;
• дату последнего пересмотра;
• шаблоны без владельца;
• использование retired-версий.

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

Совместимость версий

Изменение набора переменных — это изменение контракта между системой-источником и шаблоном. Если новая версия требует delivery_slot, старый сервис не начнёт передавать его автоматически. Реестр должен указывать минимальную версию клиента или поддерживать безопасное значение по умолчанию.

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

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

Локализация и варианты

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

Перевод — самостоятельная версия с проверкой длины и смысла. Нельзя считать, что число сегментов и допустимые символы останутся теми же. При отсутствии нужного варианта система использует заранее утверждённый fallback либо останавливает задачу, но не собирает случайный гибрид.

Предпросмотр для согласующих

Показывайте не только исходник с {variables}, но и несколько полностью отрендеренных примеров: короткий, длинный и рискованный. Рядом отображайте кодировку, число сегментов, Sender ID, ссылку и итоговую стоимость.

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

Архивирование

Retired-версия остаётся доступной для истории отправок, но не для новых задач. Удалять её физически нельзя, пока журналы и обращения ссылаются на version ID. При этом полный текст и персональные примеры хранятся по утверждённым срокам и правам.

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

Итог

Версия шаблона связывает текст, переменные, стоимость, Sender ID, согласование и фактические отправки. Неизменяемые approved-версии, тесты граничных данных, постепенная активация и быстрый откат делают контент частью надёжной системы. Тогда правка одной фразы остаётся контролируемым изменением, а не скрытым production-релизом.