Кейс: как мы разработали контактную политику для крупного медиа

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

Контактная политика как инструмент управления клиентским опытом

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

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

Коммуникационная стратегия и коммуникационная политика: как выстроить эффективную систему →

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

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

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

Инвентаризация коммуникационного ландшафта

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

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

Customer Journey Map и стратегия жизненного цикла клиента в CRM-маркетинге →

Для дальнейшего управления они были распределены по нескольким функциональным категориям.

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

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

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

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

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

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

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

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

Такая классификация создала единый реестр коммуникаций, который стал основой дальнейшего проектирования контактной политики.

Построение единой модели клиента

После завершения инвентаризации была разработана единая модель сегментации пользователей. Распространённой ошибкой при построении CRM становится создание отдельных сегментов внутри каждой кампании. В результате один и тот же пользователь может одновременно попадать в несколько различных сегментаций, сформированных по разным правилам. Это усложняет управление коммуникациями и приводит к конфликтам между сценариями.

Сегментация клиентов: разбор подходов. Антон Карелин — руководитель программы лояльности ВкусВилл →

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

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

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

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

Четвёртый уровень описывал вовлечённость в коммуникации. Анализировались открытия писем, переходы по ссылкам, регулярность чтения материалов, возвраты на платформу, использование личного кабинета и взаимодействие с различными каналами связи.

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

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

Разработка матрицы приоритетов

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

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

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

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

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

Приоритизация пользовательских сценариев

В CRM-системе крупного продукта один пользователь редко находится только в одном сценарии. В течение нескольких минут он может зарегистрироваться, подтвердить электронную почту, сохранить рецепт, подписаться на тематическую рассылку, прочитать несколько статей и прекратить заполнение профиля. С технической точки зрения каждое из этих действий является отдельным событием и может стать причиной запуска собственной коммуникации.

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

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

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

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

Такой подход исключает конкуренцию между сценариями и формирует последовательную логику сопровождения пользователя.

Оркестрация коммуникаций между каналами

Следующим уровнем проектирования стала работа с коммуникационными каналами.

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

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

Контентные рекомендации, редакционные подборки и образовательные материалы, наоборот, преимущественно доставлялись через имейл как наиболее удобный канал для потребления большого объема информации. Пуш-уведомления в подобных сценариях использовались как инструмент возврата пользователя в продукт, а не как самостоятельный носитель контента.

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

— бизнес-критичность сообщения;
— срочность доставки;
— объём информации;
— удобство восприятия контента;
— наличие согласия на использование канала;
— предпочтения пользователя;
— история взаимодействия с каждым каналом;
— вероятность достижения целевого действия.

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

Управление контактным давлением

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

Под контактным давлением понимается совокупная нагрузка, создаваемая всеми коммуникациями бренда независимо от их типа и канала доставки.

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

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

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

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

Архитектура принятия решений

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

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

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

Набор артефактов 

1. Карта всех коммуникаций.
2. Модель сегментации пользователей.
3. Матрица приоритетов коммуникаций.
4. Матрица пользовательских сценариев.
5. Матрица выбора каналов.
6. Матрица контактного давления.
7. Матрица разрешения конфликтов.
8. Decision Tree выбора коммуникации.
9. Архитектурная схема контактной политики.

Результаты проекта

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

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

Появление новых механик перестало требовать пересмотра всей CRM-системы. Любая коммуникация проектировалась по единым правилам, проходила проверку на соответствие контактной политике, получала место в общей матрице приоритетов и автоматически наследовала существующие ограничения и принципы оркестрации.

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