Ошибка в коде — минус в кассе: 7 ловушек в автоматизации сложного клиентского пути
Чем насыщеннее омниканальная маркетинговая коммуникация, чем сложнее ее автоматизация — тем выше риск, что система «сойдет с ума» и завалит клиента мусором или наоборот, не отправит важное напоминание. Елена Лесных, growth-маркетолог платформы автоматизации маркетинга Unisender рассказала, какие подводные камни учесть при планировании рассылок, как застраховать их от человеческого фактора и технических сбоев
Собрать сценарий в один канал
Итак, компания выбирает один канал: мессенджер, пуш, СМС или 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 говорит одно, пуш — другое
Разные команды или инструменты управляют разными каналами без единой логики. Например, 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.
Автоматизированные сценарии — это удобно и эффективно, особенно в омниканальной коммуникации. Но чтобы они не стали причиной массовых жалоб клиентов и убытков, важно их тщательно настроить: предотвратить дублирование сообщений, отправку неактуальных уведомлений и спама во все каналы сразу.
