Как построить плохую CJM и заставить всех тебя ненавидеть

За последние несколько лет я видела столько CJM, хороших и разных, что они мне снятся могу очень быстро определить, приведет ли та или иная из карт к позитивным изменениям для компании/продукта/сервиса.

Я горячо люблю CJM как технику, и меня расстраивает, когда её неправильно готовят и разочаровываются в ней. Есть несколько «красных флажков”, которые я считаю индикаторами того, что карта пользы не принесет (или принесет не так много пользы, как могла бы).

Итак, что можно сделать, чтобы запороть успешное начинание?

Пропустить все точки касания (touchpoints), кроме непосредственно сайта/приложения

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

Если карта рассказывает про system flow, а не про user journey, она оставляет за скобками многие переменные, зачастую не менее важные.

Вот несколько примеров категорий тачпоинтов (для разных сервисов могут быть актуальны разные из них) — все ли из них попали на карту?

• Электронные письма (например, фоллоу-ап письмо для тех, кто положил продукты в корзину и ушел, не совершив покупку; письмо с инвойсом, даже подписи в письмах — все это — маленькие кирпичики, из которых строится отношение человека к вам как сервису). Эта тема заслуживает отдельной статьи, и может быть, даже не одной. Но если вкратце, могу сказать, что умело составленные письма порой сглаживали для меня шероховатости интерфейса некоторых сервисов (а самые удачные из них подталкивали рекомендовать сервисы друзьям). Обратное тоже справедливо: письма, которые неуместны, не учитывают моей истории взаимодействия с сервисом и противоречат “духу” продукта, в лучшем случае удаляются непрочитанными, в худшем — портят впечатление.
• Люди (аккаунт менеджер, колл-центр, сейл, те, кто проводит демо/вебинары, модель “пользователь поддерживает пользователя” и т.д. и т.п.). Везде, где происходит “живое” общение, вступает в игру сразу группа факторов. Удалось ли человеку найти общий язык с пользователем? Если у пользователя была проблема, решили ли ее вообще, насколько быстро, потребовало ли это лишних усилий? Осталось ли после общения с суппортом ощущение, что сотрудник старался отделаться от пользователя поскорее (привет суппорту Google и Paypal), или что на “той” стороне — веселые ребята, которые не только помогут, но и настроение улучшат (привет суппорту Intercom и Baremetrics)?
• Реклама (баннеры, реклама на радио (включая заразительный джингл 🙂 ), реклама в социалках, контекст, реклама в видео на Youtube (лучи ненависти). Особенно актуально для первых этапов в CJM: важно понимать, что и как узнает пользователь о сервисе в начале пути (а дальше, экспериментируя с тем, какую информацию и в каком формате сообщать, можно измерять эффективность рекламных кампаний и оценивать их влияние на всё путешествие… но это совсем другая история).
• Сторонние сайты (форумы, сайты-агрегаторы, каталоги с отзывами пользователей о вас, в конце концов, даже результаты поиска в Google и то, что видят те кто, ищут вас). Не всё из этого можно напрямую контролировать, но игнорирование крайне отрицательных отзывов (или формальные отписки в духе “спасибо за мнение, сам дурак”) способно знатно подпортить мнение о сервисе.
• Контент (кейс-стади, блог, пресс-релизы, отзывы, Help и т.п.). Content is the king 🙂 . Влияет многое: и наличие контента, и его формат, тематика, частота обновления, тональность общения. Контент — повсюду, его слишком много, при этом хорошего — недостаточно.
• События (выставки, конференции, вебинары).
• Социалочки в т.ч. наполнение и оформление страниц/каналов, частота обновления контента в них, стратегия общения с подписчиками и т.п.
• Non-digital и всё, что можно “потрогать”: мерч, киоски, упаковка, пробники, запахи, звуки (да, это тоже можно и нужно проектировать), визитки, флайеры, бумажные письма. Больше, больше тактильных ощущений 🙂 В мире, где люди получают сотню электронных писем каждый день, бумажное письмо может быть чем-то таким, что запомнится и впечатлит.

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

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

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

Забыть о KPI

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

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

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

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

Приукрасить реальную картину

При построении CJM для “своего” сервиса велик соблазн преуменьшить фрустрации пользователей и показать, что хотя проблемы и есть, они не такие большие и страшные. Заметнее всего это на графиках вроде такого:

Когда реальная картина ближе к такой:

Что не так с верхней картинкой? Усредненный пользователь усредненного сервиса большую часть времени нейтрален. Мы не пользуемся сервисами в состоянии эйфории, мы не думаем “Ура! Сейчас я запущу почтовик и напишу письмо!”. Так что первая проблема в том, что субъективно оценивая эмоциональное путешествие пользователя, люди используют как baseline не нейтральное состояние, а приподнятое настроение.

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

Как починить: по возможности — в оценке опираться не на субъективное впечатление, а на результаты исследования (рейтинги, NPS и т.д.). Не всегда это возможно, и в качестве альтернативы хорошо отрезвляют цитаты фрустрированных и недовольных клиентов, чтобы команда видела, чем чревато игнорирование проблем:

Предлагать “капитанские” усовершенствования

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

Ни одна CJM сама по себе не исправит все шероховатости user journey. Самый главный и ценный результат работы по построению такой карты — это формирование высокоуровнего плана действий. С понятием “высокоуровневый” есть разночтения. Примеры рекомендаций, в которых смысла мало:

Проблема: не все могут найти компанию в Google
Плохая рекомендация: SEO

Или:

Проблема: сложная процедура регистрации
Плохая рекомендация: упростить процедуру регистрации

Как починить: формулируя рекомендации, задать себе два вопроса: достаточно ли они понятны, чтобы передать исполнителю без разночтений? Достаточно ли они реалистичны в контексте проекта? Грубо говоря, если у проекта проблемы с финансированием, рекомендация “переписать проект на другом движке” несколько неуместна.

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

Впасть в крайности: или красиво, или содержательно

В мире CJM есть две крайности: слишком много внимания к тому, как CJM выглядит, в ущерб содержанию:

… и слишком мало внимания к этому:

В первом случае красивые карты бесполезны без их автора рядом, который бы пояснял/дополнял, что он имел в виду и почему одни кружочки зелёненькие, а другие голубенькие. У отдельных личностей такие карты вызывают праведный гнев (и, пожалуй, можно с ними согласиться).

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

“You don’t need a pretty customer journey map.” If you’re communicating with robots, then this is probably true. Go ahead and just focus on the facts, and turn your robots loose.

Как починить: соблюдать баланс и использовать визуализацию и украшательства там, где это способствует пониманию, а именно:

• • 1. Если они позволяют увидеть то же, что видит пользователь (фотографии, скриншоты интерфейса/писем).
    2. Если они позволяют проиллюстрировать идеи улучшений.
    3. Если они позволяют понять характер процесса (линейный, нелинейный, циклический).
    4. Если они подчеркивают самые “острые” моменты во взаимодействии (то самое эмоциональное путешествие описывать словами — плохая идея).
    5. Цветовое кодирование там, где это уместно (банальное — зелёный/жёлтый/красный для метрик, с которыми всё хорошо/так себе/очень плохо).

Не идентифицировать цели пользователей

… или идентифицировать их неверно. В чем это может выражаться:

• Их может не быть на карте вообще.
• Цели пользователей могут быть сформулированы через цели бизнеса. Например, “зарегистрироваться в приложении» — это вам нужно, чтобы пользователь регистрировался. Для пользователя это вынужденная необходимость, если бы он мог сделать то, что ему нужно, без регистрации, так бы и поступил.
• Цели пользователей могут подменяться их задачами. К примеру, “добавить встречу в календарь” — это задача, а не цель. Целью может быть ”Знать свою нагрузку на 1-2 недели вперед”.

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

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

— Знать свою нагрузку на 1-2 недели вперед
— Зачем?
— Чтобы лучше планировать свой рабочий день
— Зачем?
— Чтобы задачи не терялись/пропускались дедлайны/не приходилось перерабатывать

Это мои личные индикаторы того, что при построении CJM кто-то свернул не туда. Я верю, что их исправление поднимает качество артефакта на новый уровень, а его полезность взлетает до небес.

А какие проблемы в CJM замечали вы? Как их исправляли?