Владелец интернет-магазина кофе в Алматы присылает вам скриншот. Покупатель оплатил заказ на 15 000 ₸, а в 11:00 получил письмо «Вы забыли завершить покупку». Своя цепочка магазина такого бы не отправила: перед письмом она заново читает заказ в CRM, так устроены триггерные цепочки. Письмо ушло из встроенного сценария брошенной корзины в платформе рассылок. Этот сценарий берёт список, собранный в 10:00, и на статус заказа больше не смотрит.
Подрядчик тут же предлагает купить CDP, «чтобы все данные были в одном месте». Не спешите. Сначала выясните, что видит каждая система в ту минуту, когда отправляет сообщение: иногда задачу решают системы, которые у клиента уже есть. Магазин тот же, что в расчёте ценности клиента, с той же экономикой; цифры условные.
Что должна знать система перед отправкой
Разложим по минутам. Покупатель начал оформление в 10:00, заплатил картой в 10:05, а система сообщений узнала об оплате в 10:10. Напоминание по правилам магазина стоит на 11:00, после часовой паузы. Если в 11:00 система ещё раз спросит статус заказа, она увидит «оплачен» и уберёт письмо из очереди. Встроенный сценарий так не делает: он отправляет всё, что попало в очередь в 10:00, и человек получает просьбу оплатить то, за что уже заплатил.
Как своя цепочка отменяет напоминание
10:00: оформление
Покупатель начал оформление заказа.
10:05: оплата
Заказ оплачен картой.
10:10: оплата видна
Система сообщений узнала об оплате.
11:00: решение
Цепочка перечитывает заказ из CRM и убирает письмо из очереди.
Встроенный сценарий платформы отправил старый список без перечитывания статуса.
Такое письмо обходится дороже, чем кажется. Покупатель может решить, что платёж не прошёл, и написать в WhatsApp; менеджер тратит время на ответ, а кто-то отписывается.
Что делают CRM, CDP и платформа сообщений
CDP Institute определяет Customer Data Platform через постоянную объединённую запись о клиенте, к которой есть доступ у других систем. В такой записи сходятся действия на сайте, заказы и разрешения на сообщения. CDP связывает их в профиль, а решение, что сделать с клиентом, принимает сценарий.
Это две разные работы, и их легко спутать. Профиль можно склеить идеально и всё равно отправить письмо по списку часовой давности. И наоборот, без CDP можно обойтись, если CRM получает все нужные статусы и вовремя передаёт их в систему сообщений.
Для одного напоминания магазин расписал, откуда берётся каждое сведение и кто отвечает за правило:
| Сведения | Откуда брать | Кто отвечает за правило |
|---|---|---|
| Начало оформления и ID корзины | Сайт | Разработчик сайта |
| Заказ, способ оплаты и статус доставки | CRM, куда сходятся заказы сайта и менеджера | Владелец магазина |
| Подтверждённая оплата | Учёт оплаты, связанный с заказом | Ответственный за оплаты |
| Согласие на канал и его отзыв | Форма согласия и система, принявшая отписку | Маркетолог |
| Отправка, доставка и причина пропуска | Платформа сообщений | Маркетолог вместе с разработчиком интеграции |
Названия продуктов здесь дело десятое. Даже если заказы и письма живут в одной программе, за оба правила отвечают люди, и в таблице должно быть видно, кто именно. Если данные лежат во внешнем хранилище, опишите, как сценарий их оттуда получает. Профиль нужен, чтобы все системы опирались на одну и ту же историю клиента. Ещё одна карточка покупателя в ещё одной панели письмо не остановит.
Как понять, что записи относятся к одному человеку
Один и тот же покупатель смотрит каталог с телефона, заказывает с ноутбука, а через неделю пишет менеджеру в WhatsApp. Для систем это три записи. Чтобы их связать, нужна надёжная связь записи на сайте с записью в CRM. У магазина такой связью служит вход в аккаунт: после подтверждённого входа сайт передаёт ID клиента вместе с ID корзины.
Похожее имя и общий IP для склейки не годятся. С одного домашнего компьютера заказывают муж и жена, а номер телефона бывает один на всю семью. Склейку по телефону тоже прогоните на таких случаях, прежде чем ей доверять.
В спецификации запишите, по какому признаку объединили записи и кто может их разъединить, если связь оказалась ошибочной. Особый случай - выход из аккаунта: действия следующего человека на том же устройстве не должны дописываться предыдущему. На приёмке два сотрудника по очереди входят в разные тестовые аккаунты с одного устройства и смотрят, к кому попали корзины.
Напоминанию хватает ID клиента, корзины и заказа, статусов, времени обновления и разрешений на канал. Паспортные данные и текст переписки этой цепочке не нужны. О доступе к полям и сроке хранения договоритесь до подключения: каждое лишнее поле добавляет работы, а если что-то пойдёт не так, ущерб будет больше.
У события два времени
Оплата прошла в 10:05, а система узнала о ней в 10:10, на пять минут позже. Если хранить только время получения, в отчёте покупатель заплатил позже, чем на самом деле. Если хранить только время оплаты, задержку интеграции потом не найти.
Поэтому у события записывают оба времени, и оба с часовым поясом. У выгрузок есть ещё и третье: момент, до которого источник передал изменения. Ночной файл с заказами может загрузиться целиком и без ошибок, но для напоминания через час он всё равно устарел.
Подвести может и порядок, в котором приходят записи. После статуса «оплачен» приходит застрявшая где-то запись «оформление начато». Сценарий не должен из-за неё вернуть заказ в неоплаченные только потому, что она пришла последней. Разработчик для этого сравнивает версии записи из источника или просто перечитывает текущее состояние, а правило для исправлений записывает в спецификацию. Возврат денег после оплаты - тоже новое изменение, и его нужно обработать.
Цепочке магазина опоздавшая запись не страшна: перед отправкой она читает текущий заказ из CRM.
Разрешение и ограничения проверяют в момент действия
В 10:00 покупатель попал в сегмент неоплативших, и этого достаточно, чтобы запустить ожидание. Но к 11:00 он мог заказать, отписаться или пожаловаться, поэтому перед отправкой условия смотрят заново, по списку из триггерных цепочек, от заказа до частоты сообщений.
Добавьте к этому списку один случай: CRM недоступна, и текущий заказ не прочитать. Тогда рекламное напоминание ставят на паузу и записывают причину. Когда связь вернётся, условия проверяют заново. Иначе очередь, накопленная за время сбоя, разом уйдёт людям, которые уже успели заказать.
Когда стоит покупать CDP
Прежде чем подписывать договор, попросите подрядчика показать один путь: корзина, заказ, обновлённый профиль, отменённое письмо. Если CRM и платформа сообщений клиента этот путь уже проходят, CDP для этой задачи не нужна. Другое дело, если между сайтом, приложением и CRM копятся несвязанные записи, а под каждый новый сценарий склейку делают заново. Тогда сравнивают два варианта: доработать то, что есть, или вести общий профиль в CDP.
В смету входит не только тариф. Подключение источников, чистка дублей, поддержка, подписки на сервисы и разбор ошибок тоже стоят денег, и тариф одного продукта - лишь часть этой суммы.
Допустим, на месяц заложили 60 000 ₸ на сервисы и ещё 60 000 ₸ на поддержку, всего 120 000 ₸. С заказа магазин оставляет себе 6 000 ₸, значит, чтобы покрыть эту сумму, нужно 120 000 / 6 000 = 20 дополнительных заказов в месяц. Разовую оплату запуска, если она есть, считайте сверху.
Двадцать заказов после писем - ещё не двадцать заказов благодаря письмам. Часть покупателей вернулась бы и сама. Прибавку покажет сравнение с группой, которой напоминание не отправляли, а срок теста и размер групп задают до запуска. Покупку CDP можно обосновать и экономией ручной работы, но тогда в расчёт идут часы команды и их стоимость.
Задание: принять один сценарий до покупки платформы
Возьмите напоминание из своего проекта: брошенная корзина, повторный заказ, любой сценарий с паузой. На выходе у вас будут таблица данных и протокол приёмки, с которыми можно идти к клиенту обсуждать внедрение.
Выполнено 0 из 6
Допустим, при расходах 120 000 ₸ после напоминаний набралось 14 заказов. Даже если считать все их дополнительными, их вклад - 14 × 6 000 = 84 000 ₸, на 36 000 ₸ меньше расходов. Отчёт о том, сколько писем ушло, эту разницу не закроет. Чтобы продолжать внедрение, нужны либо другие подтверждённые результаты, либо расходы поменьше.
Бывает, что тест с заказом у менеджера заканчивается письмом о брошенной корзине. Значит, приёмка уже нашла ошибку: заказ из CRM не дошёл до правила исключения. Запишите в протокол, где случился сбой и кто его исправит. Новую платформу есть смысл покупать, когда вы можете сказать, какую часть этой работы она снимет с команды.
Видео: CRM, ESP и CDP
Пока смотрите, сверяйте роли систем со своей таблицей: где хранится заказ, где разрешение на сообщение и кто решает, отправлять ли письмо.