Карта уведомлений клиента: как спроектировать SMS по этапам
Карта уведомлений клиента — это таблица, связывающая бизнес-событие, получателя, канал, текст, срок и следующий шаг. Она помогает увидеть повторы между CRM, сайтом, приложением и отделами до запуска автоматизации. Без карты каждый процесс создаёт собственное SMS, и клиент получает несколько сообщений об одном действии.
Начните не с шаблонов, а с пути
Выпишите этапы: регистрация, заказ, оплата, выполнение услуги, поддержка, продление. Для каждого отметьте вопросы клиента. Например, после оплаты его интересуют факт получения денег и следующий статус, а не рекламная подборка.
Не каждое внутреннее изменение достойно уведомления. В карту попадает событие, если информация ожидаема, требует действия или заметно снижает неопределённость.
Поля карты
Минимальная строка содержит:
- Код и понятное название события.
- Систему-источник и владельца данных.
- Получателя и его роль.
- Основной и резервный канал.
- Условие запуска.
- Стоп-условие перед отправкой.
- Срок полезности.
- Разрешённые подстановки.
- Идемпотентный ключ.
- Целевое действие и показатель.
Отдельно фиксируют шаблон и его версию. Тогда изменение текста не меняет историю уже отправленных сообщений.
Пример одной строки
Событие: appointment_changed. Источник: система записи. Получатель: клиент записи. Канал: push, через 15 минут SMS при отсутствии подтверждения. Стоп-условия: запись отменена, подтверждена новая версия или срок уже прошёл. Метрика: подтверждение либо перенос.
SMS:
Время записи №418 изменено на 24 июля, 16:30. Подтвердите или выберите другое: [ссылка].
Эта запись точнее требования «отправлять SMS при переносе», потому что описывает жизненный цикл.
Найдите дубли между отделами
Сгруппируйте строки по клиентскому объекту: заказу, встрече, обращению или подписке. Если два события рассказывают одно и то же, выберите один источник. Например, платёжная система и CRM не должны независимо подтверждать одну оплату.
Также найдите близкие по времени сообщения. Подтверждение, статус и акция могут быть корректны по отдельности, но вместе создают перегрузку. Для маркетинга используйте общий лимит частоты SMS.
Приоритеты и каналы
Назначьте класс: безопасность, критичное сервисное, обычное сервисное или рекламное. Приоритет определяет допустимое время, резерв и возможность объединения. Код входа не ждёт дневного окна, а статус обычного заказа может подождать утра.
Если один текст уходит по push и SMS, это попытки одного события. Архитектура резервирования раскрыта в статье про SMS как fallback для push.
Стоп-условия важнее расписания
Задание, созданное вчера, не гарантирует актуальность сегодня. Перед отправкой проверьте оплату, отмену, новый статус, отказ и закрытие объекта. Например, напоминание о счёте прекращается сразу после поступления денег.
Укажите, кто имеет право приостановить цепочку и как долго действует ручная пауза. Исключение без срока часто остаётся навсегда, а без причины — не поддаётся аудиту.
Техническая реализация
Системы публикуют события, сервис уведомлений применяет карту и вызывает HTTP API QUICKTEL. Идентификатор и статус доставки сохраняются рядом с общим событием.
Карта может сначала существовать в таблице, но рабочая версия должна синхронизироваться с кодом и настройками. Иначе документация и фактическое поведение разойдутся.
Как провести аудит готовой карты
Выберите десять реальных клиентов и восстановите их цепочки по времени. Проверьте, были ли понятны отправитель, причина и действие; не противоречили ли каналы; не пришло ли сообщение после закрытия события. Затем прогоните отмену, перенос, повтор webhook и недоставку.
Владельцы и порядок изменений
Каждая строка карты должна иметь бизнес-владельца. Он подтверждает смысл события, разрешённые данные и действие клиента. ИТ отвечает за техническую доставку, но не решает самостоятельно, является ли внутренний статус полезным человеку.
Изменение условия, шаблона или получателя проходит версионирование и тест. Старые задания либо продолжают работать по прежней версии, либо явно пересчитываются. Нельзя незаметно заменить правило и получить разные сообщения для одной стадии пути.
Раз в квартал удаляйте сценарии без владельца, события, которых больше нет в системе, и тексты без измеримого действия. Карта должна становиться проще по мере развития продукта.
Метрики
Смотрите не только доставку, но и долю завершённых действий, время от события, дубли, просроченные уведомления и ручные остановки. Рост SMS без роста полезных действий означает, что карта требует упрощения.
Начните с одного пути — например, заказ → оплата → выдача. После его проверки добавляйте поддержку и продление. Такая последовательность создаёт управляемую систему, а не набор независимых рассылок.
