AI-система триггерных коммуникаций: email, SMS, push

AI-система триггерных коммуникаций: где рвётся логика

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

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

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

Третье — разрозненные каналы. Email, SMS и push живут в разных сервисах со своими настройками, и один человек получает противоречивые сообщения: push о брошенной корзине после успешной оплаты или SMS с напоминанием сразу после письма. Единого профиля частоты и приоритета канала нет — отсюда потеря отклика, отписки и жалобы на навязчивость.

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

Измеримые эффекты: задержка, отказы, ручной труд

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

• Время реакции на событие. Триггер из очереди событий обрабатывается в момент появления, а не в ближайший запуск по расписанию: задержка падает с часов до секунд, и окно, когда клиент ещё в контексте, не теряется.
• Доля доставленных сообщений. Модель выбирает канал и момент отправки под конкретный профиль, а не по единому расписанию: попадание во «Входящие» растёт, часть отправок перераспределяется в SMS и push вместо перегруженной почты.
• Снижение ручных операций. Сегменты, шаблоны и правила перехода между шагами живут в конфигурации; маркетолог правит условия, а не собирает выгрузки вручную — регулярные операции сокращаются в разы.
• Отписки и жалобы. Ограничение частоты на профиль и автоотключение канала при всплеске жалоб держат репутацию домена: доля отписок стабилизируется, а не растёт вместе с объёмом рассылки.
• Устранённые отказы. Повторные попытки с нарастающей паузой и автоматическая смена канала убирают класс сбоев «сообщение не ушло и никто не заметил».

Репутацию отправлений и жалобы сверяем по внешним панелям — отчёты Google Postmaster Tools сравниваем с базовой линией, снятой на старте. Расхождение по любой метрике — повод остановить кампанию и разобрать причину, а не докручивать объём.

Режимы запуска триггерных коммуникаций

Режим запуска определяет, как быстро система реагирует на действие клиента и чего стоит удержание этой скорости. В одном сценарии нужен отклик за секунды — брошенная корзина, подтверждение оплаты; в другом достаточно ночной рассылки по сегменту, где задержка в час ничего не меняет. Смешивать их в одном канале нельзя: разные требования к очереди, к повторным попыткам и к защите от дублей.

Ниже — три режима, которые мы разворачиваем, с честными ограничениями каждого.

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

Внедрение по шагам: от аудита событий до передачи

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

1. Аудит событий. Проходим по продукту и выписываем все точки, где возникает значимое действие: регистрация, первая покупка, брошенный шаг оформления, смена тарифа, длительное отсутствие активности. Для каждого события фиксируем источник, состав полей и момент срабатывания.
2. Карта событий и каналов. Сводим всё в одну схему и для каждого события назначаем канал — email, SMS или push, — приоритет и правила подавления, чтобы человек не получал три уведомления об одном и том же действии.
3. Настройка правил отправки. Описываем условия, задержки и цепочки: что уходит сразу, что через сутки, а что отменяется при встречном действии пользователя. Отдельно задаём частотные ограничения и тихие часы.
4. Проверка на тестовой аудитории. Прогоняем сценарии на сегменте сотрудников и синтетических профилях: подстановка данных, порядок сообщений, срабатывание стоп-условий, обработка отписок и недоставленных адресов.
5. Проверка на реальном потоке. Включаем систему на ограниченном сегменте, сверяем долю доставленных и открытых, ловим дубли и задержки до того, как они затронут всю базу.
6. Передача и обучение. Отдаём документацию по событиям и правилам, доступы и разбор типовых сбоев, обучаем команду вносить новые сценарии и править условия без инженера.

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

Что остаётся в проекте: схемы, правила, регламенты

Что бы ни происходило в интерфейсе, поведение AI-системы триггерных коммуникаций определяется артефактами: описаниями событий, правилами частоты, политиками доступа и журналами. Их мы передаём команде заказчика в виде рабочих документов, привязанных к реальной конфигурации, а не к презентации. Ниже — что именно остаётся в проекте и по чему потом живёт эксплуатация.

• Схема событий. Перечень сигналов, которые запускают сценарий: действие пользователя, изменение статуса заявки, системное событие. Для каждого — обязательные атрибуты, источник данных и поведение при их отсутствии.
• Правила частоты сообщений. Лимиты на пользователя и на канал, окна тишины с учётом часовых поясов, приоритет сценариев при конфликте и логика подавления повторного триггера — чтобы письма, SMS и push не дублировали друг друга.
• Политики доступа и роли. Кто правит шаблоны, кто меняет правила частоты, кто видит только отчётность. Согласия на каналы и обработку данных хранятся отдельно от контента и проверяются перед отправкой.
• Инструкции для команды. Как добавить новый триггер, как приостановить сценарий без правки кода, что делать при всплеске отказов доставки, как проверить гипотезу на части аудитории.
• Журналы и отчётность. По каждой отправке фиксируется решение: какой триггер сработал, какое правило применилось, почему сообщение не ушло. Сводки — по доставляемости и доле целевых действий.
• Регламент изменений. Порядок правки правил и шаблонов, состав согласующих, способ вернуть предыдущую конфигурацию, если метрики отклика просели.
• Карта интеграций. Точки подключения к CRM, хранилищу данных и сервисам рассылок: какие поля куда передаются, с какой периодичностью и кто отвечает за расхождения.

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

Кейс: как выросли доставка и отклик на события

Клиент — розничная сеть с каталогом на несколько тысяч позиций и своей программой лояльности. События собирались ночной выгрузкой: брошенная корзина, повторный заказ и отмена заявки доезжали до рассылки через 5–7 часов после действия. Рассинхрон между складом и Mindbox давал дубли — один покупатель получал письмо и SMS по одному поводу, а часть событий терялась при склейке профилей.

Пилот на одном регионе зафиксировал стартовые цифры: отклик на триггерные сценарии 1,8%, доля отписок 0,9%, доставка SMS 71%, повторный заказ в течение недели — у 6% получивших сообщение.

Что перестроили

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

Что стало

Задержка от действия до касания сократилась с часов до десятков секунд, доля потерянных событий упала с 3% до 0,1%, доставка SMS выросла до 94%. Отклик на триггерные сценарии вырос в 2,4 раза, отписки снизились до 0,2%, повторный заказ в течение недели — у 11%. После этого логику раскатали на остальные регионы, добавив push третьим каналом.

Чем событийная рассылка отличается от массовой

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

Событийная запускается от факта в системе: брошенная корзина, привязка карты, отсутствие входа после регистрации. Инициатор — поток событий, а не человек, поэтому между действием и сообщением проходят минуты. Контент собирается из атрибутов самого события: один шаблон даёт разные сообщения разным получателям.

Разница в отклике объясняется моментом, а не текстом: сообщение приходит, когда задача уже сформулирована действием самого получателя. Массовая проигрывает не из-за формулировок — она говорит со всей базой сразу и не знает, что человек сделал минуту назад.

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

Технические сомнения: ограничения и крайние случаи

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

Как система переживает недоступность внешнего канала?

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

Как ограничивается частота сообщений?

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

Что с задержками и текущими шаблонами?

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

Обсудим задачу: что прислать для оценки

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

• Перечень событий: какие действия клиента или внутренней системы должны запускать сообщение — регистрация, незавершённая покупка, смена тарифа, долгое отсутствие активности. По каждому событию — условия срабатывания, задержка и признак отмены, если действие уже совершено.
• Текущие каналы связи: какие рассыльщики email, SMS и push используются сейчас, кто отвечает за договоры и лимиты по скорости отправки.
• Доступы к системам: тестовые ключи к CRM и хранилищу событий, к сервису рассылок и аналитике, схема полей пользователя, доступных для подстановки в текст.
• Шаблоны и правила: текущие тексты, переменные, частота касаний, «тихие часы», правила согласий и отписки.
• Объёмы и статистика: сколько событий проходит в сутки, доля доставленных и открытых сообщений по каждому каналу, пиковые нагрузки.
• Ограничения: требования к хранению персональных данных, каналы и сценарии, которые трогать нельзя, критерии приёмки работ.

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