Итак, компания выбирает один канал: мессенджер, пуш, СМС или e-mail. Пока он жив, все хорошо. Как только он падает, клиент пропадает.

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

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

Как предотвратить: спроектировать каскад. Выстроить цепочку из запасных вариантов и переключаться между ними, если основной канал не сработает. Простой пример каскада: «Мессенджер — 30 секунд без ответа — СМС — 60 секунд без ответа — пуш».

Здесь нужно определить, какой канал будет основным, через сколько секунд без ответа будет переход на следующий и какой канал будет последним — например, e-mail или звонок оператора.

Что настроить:

• статусы доставки по каждому каналу;
• fallback (переключение с канала на канал) после N минут без доставки — через какое время после отправки в первый канал надо перейти к следующему звену каскада;
• ограничение частоты сообщений по событию — например, не больше трех в целом и не больше одного на конкретный канал;
• дедупликацию сообщений по user_id / order_id / event_id (идентификатор пользователя / заказа / события) — защиту от ситуации, когда одно и то же событие запускает каскад дважды (например, после оплаты заказа клиенту приходят уведомления и в СМС, и на e-mail).

Событие попало в платформу автоматизации, но CRM (Customer Relationship Management, ПО для автоматизации работы с клиентами), сайт, биллинг или мобильное приложение не синхронизировались. Коммуникация сбоит. Например, пользователь оплатил заказ, но эти данные еще не обработаны, и через минуту он получает письмо «Завершите покупку». Или клиенту с активной подпиской приходит сообщение с посылом «Вернитесь, мы скучаем».

Нажмите, чтобы увеличить изображение

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

Как предотвратить: не запускать важные сценарии сразу после события, если данные приходят из нескольких систем.

Что настроить: техническую задержку 5-15 минут после входящего триггера. И добавить повторную проверку статуса перед отправкой.

Например, «Триггер: оплата прошла», дальше задержка 10 минут, после запускается повторная проверка статуса в CRM и только потом — отправка сообщения.

Также нужно настроить единый источник правды для заказа, подписки или оплаты. Таким источником может быть CRM-система или отдельная система (условно, CDP — Customer Data Platform, ПО для сбора клиентских данных), которая агрегирует данные из всех систем и уже оттуда дает «чистый статус».

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

Однако без грамотной настройки они превращают один сбой в несколько одинаковых сообщений.

Например, клиент оформляет заказ, но система не получила сообщение «Все хорошо, принято». И она повторяет отправку, потом еще раз. В итоге клиенту приходит три одинаковых СМС с кодом или три письма с одним заказом.

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

Как предотвратить: каждое событие должно иметь уникальный event_id, а каждое сообщение — message_id (у каждого СМС или письма он разный). В таком случае система видит, что пришел вебхук («обратный звонок» от системы о том, что событие произошло) с event_id = X. Если она уже обрабатывала это событие условные полчаса назад, она его игнорирует.

Что настроить: обработку вебхуков и TTL (Time To Live, «срок годности» информации) для событий — сделать обязательным ответ системы на событие и задать время, в течение которого система помнит, что это событие уже было. Например, оплата заказа 123 будет считаться «свежей» в течение шести часов, второй-третий сигнал по нему игнорируется. Но если сигнал придет через шесть часов, система обработает его как новый и отправит пользователю сообщение.

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

Нажмите, чтобы увеличить изображение

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

В моей практике такая история случилась на одном проекте. Уважаемая компания проводила конференцию два года назад. Меня приглашают на аудит проекта. Я запрашиваю доступ в аккаунт ESP (платформы массовых рассылок) и обнаруживаю, что формы захвата, отправка подтверждения заявки, письма после конференции — все еще работает. Лендинг нашли, форму удалили, цепочки отключили — не надо так.

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

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

Например, если у вас сценарий сезонной акции с условием «запускать с 20 февраля по 8 марта включительно», то для него можно прописать отключение «остановить сценарий автоматически 9 марта в 00:00». Это делается прямо в календаре встреч, достаточно просто заблокировать себе временной слот под задачу.

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

Разные команды или инструменты управляют разными каналами без единой логики. Например, e-mail предлагает скидку 10%, пуш — 15%, in-app (сообщение в приложении) показывает что-то третье, а менеджер в CRM видит вообще старый статус.

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

Как предотвратить: предложение должно быть не в письме, а в централизованной логике принятия решений в CRM или в модуле управления промо. Сотрудники не вбивают вручную в каждое сообщение конкретную скидку — вместо этого в каждом сообщении стоит ссылка-идентификатор (например, offer_id = SPRING25).

Например, письмо говорит: «Ваша скидка — посмотри здесь» (вставляет offer_id). А система сама решает, что именно показать клиенту по этому offer_id: 10% или 15%, исходя из его сегмента, истории, времени. Тогда клиент в любом канале видит одинаковое предложение.

Что настроить: единый offer_id (идентификатор предложения) и приоритеты кампаний (какую акцию показать клиенту, если он подходит под разные условия), которые настраиваются однократно для всех каналов. Также нужен общий календарь коммуникаций по всем каналам — одна таблица или доска, где видны все запланированные рассылки: e-mail, пуш, СМС, in-app, мессенджеры, даже колл-центр.

Проблема простая: пользователь отписался или изменил свои согласия на подписку, но часть сценариев продолжает отправлять сообщения. Например, он отключил e-mail-рассылки, но получает триггерные письма из старой цепочки. Или отказался от SMS, а fallback (переключение с канала на канал) все равно уходит в SMS.

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

Как предотвратить: менеджмент подписок должен быть общим для всех каналов и сценариев.

Что настроить:

• Единый центр согласий — все согласия клиента по всем каналам должны храниться в одном месте, лучше всего в CRM или CDP.
• Проверку разрешения перед отправкой — хочет ли клиент получить сообщение именно сейчас, именно по этому каналу, именно по этому типу (маркетинг или сервис).
• Синхронизацию отписок в реальном времени.<
• Отдельные правила для сервисных и маркетинговых сообщений — о статусе заказа можно сообщить, даже если клиент отказался от рассылок, но о новой акции нельзя.

Нажмите, чтобы увеличить изображение

Компания построила автоматизацию с расчетом на то, что пользователь моментально получает сообщения. Не учтены перебои интернета, отсутствие человека в сети. В результате, например, клиент получает push с ограничением «только 20 минут», но видит его через 3 часа. А бизнес теряет конверсии и лояльность клиента.

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

Что настроить:

• Срок годности сообщения (TLL) — компания отправляет push с оффером «действует 2 часа», система пытается его доставить. Если устройство клиента офлайн, push виснет в очереди у провайдера. Когда TTL истечет, провайдер удаляет это уведомление и не отправляет клиенту.
• Проверку времени открытия — сообщение дошло, клиент открывает, но прежде чем показать контент или активировать ссылку, система проверяет, актуальна ли информация в этот момент.
• Динамический контент вместо зашитых дедлайнов — вместо «скидка 20% заканчивается завтра» можно отправить «ваша персональная скидка действует 24 часа с момента перехода по ссылке» и реализовать это через динамическую проверку.

А для критичных уведомлений настраивается альтернативный канал. Например, если клиент не получил важное сообщение через push, оно придет в SMS.

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