Схема рассылок — это результат компромиссов. Мы подходим к задаче с желанием сделать идеально и с каким-то набором стандартных тактик и личных экспертных наработок, но должны сконфигурировать их под реалии конкретного бизнеса. Как правило, эти реалии обрезают нам крылья и точат душу гневом («Что, нельзя было корзину синхронизировать на сайте и в приложении?!»), и это нормально. Ненормально — делать вид, что все интернет-магазины одинаковы, или все застройщики одинаковы и далее по списку. Ненормально — уклоняться от погружения в бизнес и рисовать сферического коня в вакууме.
Схема рассылок должна учитывать особенности технической экосистемы, бизнес-процессов и внутренней политики проекта. Она должна позволять разным людям, решающим разные прикладные задачи, считать заложенный в ней физический смысл.
Читайте также
Как объяснять сложные процессы с помощью блок-схем
Решение прикладных задач
Возьмём одну из стандартных тактик — брошенную корзину. На картах коммуникаций её показывают примерно так:
Посмотрим, как эту схему читают при решении разных задач.
Аналитик ищет окно возможностей для оптимизации
Но схема рассылок не может помочь даже с вариантами, лежащими на поверхности:
- Может, дать промокод во втором письме? А сейчас его там нет?
- Не поменять ли товарную рекомендацию? А сейчас там какая?
Технический специалист начинает реализацию
И ему не хватает данных даже для минимально необходимых настроек, предусмотренных в платформе:
- Триггер должен срабатывать каждый раз при завершении сессии с корзиной или с какими-то ограничениями? С какими?
- В платформе есть два списка корзин: для сайта и для мобильного приложения. О каком здесь идёт речь?
Эти вопросы даже не чисто технические, это вопросы бизнеса. Так что и в ситуации верхнеуровневого обсуждения с руководителем бизнеса такого представления может быть недостаточно.
Без конкретики также невозможно оценить стоимость внедрения схемы.
Хотелось бы, чтобы заказчики и после внедрения поддерживали схему в актуальном состоянии. Схема рассылок — это и знание о том, как всё устроено, и плацдарм для системного подхода к изменениям.
Если не хватает данных для решения прикладных задач — значит, формат схемы не справляется со своей функцией.
Читайте также
Основы лидогенерации в email-маркетинге
Формат представления схемы
Формат рождается из потребности донести важное.
Отражайте на схеме всё, что считаете значимым для проекта, например:
- максимальную частоту срабатывания триггера для одного пользователя;
- отправителя коммуникации (это может быть директор, команда, персональный менеджер);
- применимость коммуникации к различным сегментам пользователей (по дате последнего заказа, по активности в канале);
- принадлежность коммуникации к маркетинговому или транзакционному типу;
- наличие промокода;
- наличие товарной рекомендации и базовый сегмент товаров для неё («персональные по сегменту футболок для мальчиков»);
- неочевидные динамические параметры (срок хранения заказа, трек-номер);
- utm-метки (хотя бы до уровня кампании);
- ссылки на эти коммуникации в платформе (если уже внедрены);
- приоритизацию цепочек относительно друг друга.
Старайтесь сузить диапазон трактовки схемы.
Прокомментируйте, как видите реализацию конкретного письма
Если на проекте в целом принята сегментация по полу и возрасту, а в конкретном письме вы не указали подобных настроек — подтвердите, что это сделано сознательно.
Если в разных цепочках можно использовать одно и то же (физически или по смыслу) письмо — напишите об этом.
Укажите точку отсчёта для временных задержек
Однажды я видела воронку, коммуникации по которой были реализованы в двух платформах: AMO CRM и Unisender. На схеме временные задержки были указаны в терминах AMO: от момента события-триггера. При реализации в AMO всё прошло хорошо. А в Unisender не была сделана поправка на особенность платформы (в конструкторе цепочек Unisender временные задержки отсчитываются не от стартового, а от предыдущего события), поэтому +30 дней от изменения статуса в воронке превратились в +30 дней от предыдущего письма цепочки, и вся цепочка вместо запланированных 30 дней длилась все 75.
Чтобы избежать подобных ситуаций, можно размещать на схеме краткую спецификацию:
Отразите на схеме те коммуникации, которые ведутся вручную или реализуются сторонними сервисами
Например, протокол работы с клиентом у компании-застройщика подразумевает, что при отмене встречи по инициативе менеджера он обязан лично написать клиенту. В схеме стоит отразить эту коммуникацию с соответствующей пометкой, чтобы было понятно, что она есть.
Ещё пример: уведомление о поступлении заказа в пункт выдачи отправляют службы доставки — интернет-магазину этого достаточно. На схеме стоит отразить эти уведомления, чтобы было понятно, что вы не забыли реализовать их у себя, а сознательно не стали этого делать.
Конечно, для каждого проекта можно решать индивидуально, что отразить на схеме, а что обсудить словами, сделать руками или записать в гугл-доке. Это вопрос договорённостей и организации процессов. Было бы о чём говорить.
Физический смысл схемы: на что обратить внимание при реализации
Если схема рассылок выглядит так, будто с неё стёрли слой с подробностями — это не всегда про формат. Хорошо, если автор просто не отразил нюансы. Хуже, если он их не продумал.
Погружайтесь в проект, и физический смысл схемы сформируется сам собой, останется только нарисовать.
Выбирайте оптимальное время
Когда рисовать схему? Вопрос имеет смысл в ситуации запуска проекта или переезда на новую платформу. Для таких случаев идеальный момент — когда платформа уже выбрана, а интеграции ещё нет.
Если платформа выбрана
Мы сможем спроектировать коммуникационный процесс под реализацию именно в этой платформе:
- Учтём возможность использования встроенных алгоритмов. Например, в платформе Mindbox есть алгоритм «Лучшее следующее предложение»:Если мы его включим, нам не надо будет думать, через какое время после заказа отправлять рекомендации или промокод.
- Отразим на схеме стандартные и обязательные для этой платформы настройки, например, частоту применения триггера к пользователю:
- Будем думать в категориях возможностей платформы: ухватимся за мысль отправлять спецпредложение тем, кто покупает по выходным, или отгоним её, перекрестясь.
Если интеграция будет настраиваться после разработки схемы
Схема рассылок выступит базой, и мы сможем обеспечить передачу всех необходимых параметров уже на первой итерации внедрения платформы. Ведь обновление интеграции будет или не скоро, или никогда.
Принимаясь за схему при готовой интеграции, уточняйте, какие параметры и статусы имеются в наличии. Это убережёт от фантазий на тему передачи трек-номера заказа в письме или уведомлений о продлении срока хранения.
Читайте также
Customer Journey Map в MailChimp
Собирайте анамнез, узнавайте о планах
Выясните, есть ли на проекте программа лояльности, мобильное приложение, офлайн-магазины, разделение на b2b и b2c, функционал избранного и электронного подарочного сертификата (если нет, то планируется ли). И как это всё интегрировано друг с другом и с платформой: действует ли программа лояльности в офлайн-магазинах; синхронизирована ли корзина на сайте и в приложении; передаются ли офлайн-заказы в платформу.
Конечно, всё это лучше узнавать ещё до старта работ: каждый пункт увеличивает усилия по подготовке схемы, и надо быть готовым к тому, за что берёшься.
Запросите результаты опросов пользователей, проведённых до вашего подключения к проекту. Возможно, они зададут направление вашим мыслям, например, подскажут, как отработать возражения пользователя в цепочке стимулирования первого заказа.
Используйте данные, но не забывайте про общую логику бизнеса. RFM-анализ может подсказать, какие промежутки между заказами стоит считать нормой, а когда пора начинать волноваться. Но если вам надо, например, понять, через какое время после заказа клиент считается утраченным, и при этом в программе лояльности баллы сгорают через год — не копайтесь в данных. Год так год.
Выясняйте, используется ли на проекте функционал глобальной контрольной группы
Если используется, часть базы попадает в эту группу и исключается из рассылок. Транзакционные письма игнорируют глобальную контрольную группу. Но надо понимать, что в стратегии могут быть коммуникации, которые не являются транзакционными, но тоже должны игнорировать глобальную контрольную группу. Показав попап с промокодом за подписку, вы обязуетесь прислать этот промокод. Нехорошо, если пользователь не получит его из-за попадания в контрольную группу.
На этой схеме первое письмо игнорирует глобальную КГ, а второе нет. Это показано меткой, пояснения даны в спецификации к схеме.
Разбирайтесь с физическим смыслом статусов в воронке
Вам надо понять следующее:
- что означает каждый статус по версии разработчиков воронки;
- как его понимают и применяют менеджеры на местах;
- с какой скоростью изменения попадают в платформу, с который вы имеете дело.
Я видела ситуацию, когда один из статусов назывался «встреча», и по факту присвоения этого статуса пользователю отправлялось письмо с уведомлением о дате и времени назначенной встречи. На самом деле в CRM этот статус присваивался уже после того, как встреча состоялась.
Автоматизируйте бизнес-процесс, а не создавайте его
Допустим, ваш заказчик организует онлайн-уроки для детей и просит вас отрисовать схему для автоматизации коммуникаций. Если вы, исполненный энтузиазма, начинаете рисовать на схеме уведомления типа «Завтра в 15:00 у вас занятие, вот ссылка» — остановитесь. Сначала узнайте, как организован процесс, попросите показать воронку в CRM. Велика вероятность того, что процесс организован никак, CRM нет в природе, преподаватель создаёт ссылки на Zoom за три минуты до старта занятия, а через 40 минут вылетает из конференции, создаёт новую ссылку и кидает всё это в чат, причём не детям, а родителям:
Тут нечего автоматизировать, понимаете? Нет, вы можете, конечно, проработать и описать бизнес-процесс, внедрить CRM, написать инструкции для сотрудников и систему их мотивации, наладить мониторинг… Но это немного другая задача. Это будет разработка и внедрение бизнес-процесса.
Делая карту коммуникаций, мы должны начинать с анализа существующего бизнес-процесса и выявления коммуникаций, пригодных для автоматизации.
Выясняйте политику бизнеса
На многобрендовых проектах бывает необходимо исключить внутреннюю конкуренцию между брендами. Это актуально, например, для застройщиков. Если клиент находится в воронке одного жилого комплекса, не надо отправлять ему коммуникации про другой. Такой подход требует дополнительных настроек в триггерах и товарных рекомендациях.
Сюда же — вопрос, ведём ли из рассылок в офлайн-магазины или действуем строго на благо интернет-магазина.
Сюда же — сегментирование по отдельным полям (например, сегментирование по полу ребёнка в плане одежды может быть обязательным для бренда, а в плане игрушек — неприемлемым).
Сегментируйте на 100%
Все любят сегментировать, но не все понимают, что у части пользователей конкретный параметр может быть не заполнен или невалиден. Не забывайте про эту часть.
Планируя коммуникацию для жителей регионов, подумайте, как лучше построить фильтр: «город = Москва» или «город неизвестен ИЛИ Москва». А может, для пользователей без города стоит предусмотреть отдельную коммуникацию (учитывая, что неизвестный город может на самом деле оказаться как Москвой, так и не Москвой).
Формируйте долгосрочный эффект
Велика вероятность, что принципы группировки цепочек перетекут из схемы в платформу, а оттуда — в utm-метки и статистические дашборды.
Коммуникации можно группировать по-разному. Группируя, например, брошенную корзину и избранное, можно опереться на отработку:
- действий пользователя (сессия с корзиной, но без заказа);
- события снижения цены;
- пользовательского списка «Корзина»;
- списка «Избранное»;
- пользовательских списков.
Правильного способа группировки нет. Есть тот, который позволит вам интуитивно понимать и грамотно интерпретировать статистику.
Читайте также
Готовая схема для внедрения брошенных корзин
Не множьте сущности
Допустим, вы отправляете письмо с предложением заполнить профиль в рамках welcome-серии и после заказа. Если вам надо различать статистику этих вариантов, делайте два триггера и два email-сообщения. Если не надо — два триггера и одно email-сообщение.
Представим, что на проекте есть две точки входа (регистрация на сайте и подписка из попапа). Стремясь персонализировать путь пользователя, вы решаете сделать две вариации приветственной цепочки, привязываясь к операциям постинга. Но проект развивается, и через месяц там включат ещё три попапа, а через полгода настроят подписку в офлайн-магазинах. Сколько же вариаций цепочек придётся делать?
Правильный ответ — одну. Надо делать одну цепочку, привязываясь к факту изменения статуса подписки. А если в магазине за подписку пообещали промокод на подарок, а на попапе — промокод на скидку, то это решается отправкой единичных писем в дополнение к основной серии.
Ищите универсальные решения. Каждый костыль снижает шансы схемы жить долго и плодотворно. Схему, построенную на экземплярах сущности, а не на сущностях, нельзя оптимизировать — только переделать.
P.S.
Общепринятого стандарта разработки схем коммуникаций не существует. Давайте его вырабатывать?
Подписывайтесь на наш Телеграм-канал «Маркетинг за три минуты», где мы делимся интересными материалами про онлайн-маркетинг в формате постов-трёхминуток. А если вы хотите поболтать и поделиться своими мыслями, приходите к нам в CRM-Chat.