Всем привет! На связи Елизавета, я agile-коуч продуктовых стримов корпоративного бизнеса — транзакционных сервисов, продуктов для малого бизнеса, страхования. Внедряю Discovery и проверку гипотез, а ещё веду курс по CJM для топ-менеджмента и продуктовых лидеров. Отсюда и тема статьи: расскажу о том, как выстроить карту клиентского пути для ИТ-продуктов.

Свои процессы ИТ-команда знает хорошо: сколько занимает разработка, где стоит согласование, какой сервис отвечает за шаг, сколько проходит от постановки задачи до релиза. Мы считаем сроки и смотрим на продукт через метрики. Внутренние процессы не отвечают на один вопрос: что в этот момент происходит с клиентом?

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

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

заявка → проверка → согласование → решение → уведомление клиента.

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

узнал о продукте → попытался разобраться → не понял условия → написал в чат → получил один ответ → пришёл в офис → узнал о дополнительных документах → ушёл → вернулся через несколько дней → снова связался с банком.

Этот разрыв команда разбирает на карте клиентского пути, Customer Journey Map. Ей пользуются не только CX- и UX-специалисты: в работе над ИТ-продуктом карта нужна продукту, аналитике, бизнесу и разработке.

Восемь вопросов, которые помогают понять проблему

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

Карта начинается с двух вопросов: «Кто проходит путь?» и «Что он пытается сделать?». Клиент хочет разблокировать карту, открыть расчётный счёт, подключить кассу, оформить пенсию, узнать статус заявки. За каждым действием стоит своя история, и её команда разбирает по шагам: что человек делает, где сталкивается с продуктом, что думает и что мешает ему дойти до цели.

Для создания идеальной CJM команда по очереди отвечает на восемь вопросов:

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

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

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

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

С болями клиента есть отдельная ловушка: часто команда записывает симптом вместо проблемы. «Клиент долго ждал» ничего не объясняет. Почему ждал? Не прошёл идентификацию, сотрудник не видел данных, не пришло уведомление, пришлось второй раз ехать в офис. Чем точнее причина, тем понятнее, что с ней делать.

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

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

Как собрать данные для CJM

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

• интервью с клиентами;

• интервью с сотрудниками, которые непосредственно работают с клиентами;

• анализ обращений в контактный центр;

• данные CRM;

• цифровая аналитика и данные о переходах между этапами клиентского пути;

• обращения через цифровые каналы;

• наблюдение;

• самостоятельное прохождение сценария;

• результаты опросов;

• анализ социальных сетей и обратной связи.

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

Отдельная сложность — сами интервью. На прямой вопрос «Какие проблемы у вас возникали при использовании продукта?» человек ответит: «Да вроде никаких». Проблем от этого меньше не становится: люди редко критикуют продукт в лицо его создателю. Поэтому просите вспомнить конкретную ситуацию. Вместо «Вам было сложно?» — «Вспомните последний раз, когда вы делали эту операцию. С чего начали?». Вместо «Были проблемы с оформлением?» — «Что произошло после того, как вы отправили заявку?». 

Такие вопросы возвращают человека из оценок в реальный сценарий.

В сценарии появляются детали. Человек сначала говорит «Всё было нормально», а через пять минут рассказывает, как звонил в поддержку, просил коллегу разобраться, искал инструкцию в интернете и отложил задачу на два дня. Проблему он не назвал, но показал.

Для ИТ-продуктов спрашивайте про обходные пути: «Что вы делаете, если не получается?» и «Где ищете информацию, когда её нет в продукте?». Команда закладывала «Заполнить форму → отправить → получить результат», а пользователь открывает форму, спотыкается об один пункт, закрывает её, ищет инструкцию, возвращается, звонит сотруднику и открывает форму заново. Формально сценарий пройден. Если люди регулярно обходят задуманный путь, разберитесь почему.

После первых интервью встаёт вопрос, как не утонуть в материалах. У 50 клиентов 50 историй со своими формулировками и исключениями. Сложите их в один документ, и вместо карты получите коллекцию заметок. Заведите таблицу: на первом этапе хватит обычной, отдельная ИТ-система не нужна. Для сценария «Открытие счёта» она выглядит так:

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

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

В связке CJM c ИТ помогают инструменты визуализации. В Visiology, например, команда собирает данные в интерактивные дашборды и кладёт наблюдения исследователей рядом с цифрами. С одной стороны клиентский путь: привлечение → заявка → оформление → ожидание → результат → дальнейшее использование. С другой, показатели по этим же этапам: количество клиентов, конверсия, время прохождения, обращения и повторные обращения, отказы, оценки из опросов.

Как CJM-карта ложится на ИТ-ландшафт

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

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

• действие клиента;

• канал взаимодействия;

• экран или функциональность продукта;

• внутреннюю систему;

• ответственное подразделение;

• бизнес-процесс;

• данные, которые появляются на этом шаге;

• клиентскую проблему;

• продуктовую метрику.

Такая карта связывает клиентский опыт с ИТ-ландшафтом.

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

Заполняют её в три захода. Исследователь закрывает верхние строки: что клиент делает, где и на каком экране. Материал берёт из интервью и из собственного прохождения сценария. Аналитик и архитектор дописывают системы, владельцев шагов и данные. Здесь обычно выясняется, что по половине этапов данных нет: время в очереди никто не пишет, ручные правки не логируются. По пустым ячейкам вы находите места без логирования и заводите на них задачи.Продуктовая команда закрывает две нижние строки: барьеры и метрики. Барьер приходит из исследования, метрика из аналитики. Если под барьером не стоит метрика, изменение потом не с чем сравнить.

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

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

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

После этого разговор меняется. Три команды смотрят на строку «Ожидание результата», где стоит время в очереди 4 дня, ни одного уведомления клиенту и 19 звонков в контакт-центр на сотню заявок. Дальше они делят между собой три задачи, вместо того чтобы выяснять, чей это участок.

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

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

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

Полная карта на девять слоёв для всего продукта не нужна и не соберётся. Возьмите один сценарий, где у вас падает конверсия или растут обращения, и пройдите его сами от первого экрана до результата. Дальше десять интервью, таблица наблюдений, разметка шагов по слоям. На выходе у команды будет список точек контакта, где клиент спотыкается, и рядом с каждой — имя ответственного и метрика. Из этого списка получаются 3-4 задачи в ближайший спринт и один разговор с соседним подразделением, который до этого никак не начинался. Через квартал карта устареет: выйдут релизы, перестроятся процессы. Обновить её дешевле, чем заново выяснять, где клиент теряет неделю.