Клиент отправил форму на сайте. В отчёте появилась заявка, менеджер получил уведомление, а сам человек всё ещё не понимает: его записали или нужно позвонить? Для компании действие состоялось. Для клиента задача пока не решена.
В Гуси-Лебеди мы предлагаем разбирать такие ситуации через CJM, Customer Journey Map. Это карта пути клиента: последовательность его действий, вопросов, ожиданий и контактов с компанией при решении конкретной задачи. Она помогает увидеть, что происходит между отдельными событиями в аналитике. Ниже разберём условную запись на обслуживание через сайт. Это учебный пример, а не кейс нашего клиента.
Сначала выберите путь, который действительно нужно разобрать
Карту легко превратить в огромную схему «от знакомства с брендом до лояльности». Работать с ней трудно, если непонятно, какое решение она должна помочь принять. Начните с вопроса: почему человек отправил заявку, но затем снова позвонил, чтобы записаться?
В нашем примере человек хочет выбрать услугу, согласовать время и убедиться, что его будут ждать. Начало пути: он ищет подходящие условия на сайте. Конец: получает понятное подтверждение записи либо узнаёт, что нужного времени нет. Дальнейшее посещение и повторное обращение можно исследовать отдельно, если задача относится к качеству самой услуги.
Зафиксируйте, чей опыт изучаете. Человек, впервые выбирающий компанию, и постоянный клиент могут решать похожую задачу разными способами. Нельзя объединить их в одного «среднего покупателя», если различия влияют на путь.
Но и выдумывать подробную биографию персонажа не нужно: сведения полезны, когда объясняют действия и ограничения. Для записи может иметь значение, что клиент может говорить по телефону только вечером. Любимый цвет и возраст без связи со сценарием карту не улучшат.
Этапы называйте действиями человека: «сравнивает условия», «выбирает время», «отправляет заявку», «ждёт подтверждения». Названия внутренних подразделений не объясняют его опыт. На одном этапе могут быть разные точки контакта: страница услуги, форма, разговор с сотрудником и сообщение в мессенджере.
Воронка продаж и CJM отвечают на разные вопросы. Воронка показывает переходы между выбранными этапами и потери в количестве обращений. Карта раскрывает содержание пути: какую информацию человек получил, что пытался сделать и где возникло препятствие. Из одного падения конверсии нельзя узнать его причину. Карта помогает сформулировать и проверить объяснение, но не заменяет статистику.
Собирайте события и слова клиента, а не удобную историю
Посмотрите, какие сведения уже доступны: обращения, переписка, записи статусов в CRM, события на сайте, отзывы и наблюдения за прохождением сценария. Каждый источник имеет свои границы. Событие отправки формы подтверждает действие на сайте, но не подтверждает, что клиент понял условия или согласовал время.
Для интервью полезнее восстановить недавний конкретный эпизод, чем спрашивать «какой сайт вам нравится». Что человек искал перед заявкой? Где посмотрел условия? Как понял, что запись подтверждена? Что сделал после отправки? Если он говорит, что позвонил, уточните, что хотел выяснить. Не подсказывайте ответ вопросом «вы ведь испугались, что заявку потеряли?».
В карту переносите отдельно наблюдение и объяснение. «После отправки формы клиент позвонил» описывает действие. «Он не доверяет сайту» уже интерпретация. Причиной звонка могли быть уточнение цены, выбор другого времени или отсутствие подтверждения. Пока это не выяснено, так и запишите: причина звонка неизвестна. Если нужно разобраться в самой задаче и истории выбора, используйте вопросы из нашего разбора Jobs to Be Done.
С эмоциями действует то же правило. Грустный смайлик рядом с ожиданием не становится данными об опыте. Сохраните слова человека и контекст либо пометьте оценку как предположение команды. Гипотезы допустимы: проблема возникает, когда их невозможно отличить от наблюдений.
Для каждого существенного вывода храните основание: ссылку на обезличенное обращение, дату наблюдения или запись исследования. Включите в разбор и людей, которые не дошли до записи. Опыт только успешно записавшихся не объяснит, что помешало остальным. Не ждите одинаковой истории от всех: человек, которому не подошло время, и человек, который не понял статус заявки, столкнулись с разными препятствиями.
Пример карты: где заявка перестаёт быть понятной записью
Ниже показана заготовка для условного сервиса. Все препятствия в ней нужно проверить на собственных материалах. Она не доказывает, что такие проблемы есть на вашем сайте.
| Шаг человека | Что ему нужно понять | Возможное препятствие | Что проверить |
|---|---|---|---|
| Изучает услугу | Подходит ли она и какие условия действуют | В описании нет важного ограничения | Содержание страницы и вопросы перед заявкой |
| Выбирает время | Можно ли прийти в нужный день | Форма просит дату, но не объясняет порядок согласования | Поля формы, пояснения и разговоры с сотрудниками |
| Отправляет заявку | Получена ли она и что будет дальше | Сообщение «спасибо» не говорит о статусе записи | Экран успешной отправки и доступный следующий шаг |
| Ждёт ответа | Когда и каким способом придёт подтверждение | Условия ответа нигде не указаны | Действующий процесс, уведомления и обращения |
| Получает подтверждение | Куда прийти, когда и что подготовить | В сообщении нет согласованных деталей | Текст подтверждения и повторные уточнения |
Возьмём третью строку. Простая замена «спасибо» на «вы записаны» может ухудшить ситуацию, если сотрудник ещё должен согласовать время. Сначала выясните, что означает отправка формы в реальном процессе. Если это запрос на запись, сообщение должно объяснять именно это и доступный следующий шаг. Если время бронируется автоматически, проверьте, что бронь действительно создаётся и подтверждение содержит выбранные условия.
Здесь важно увидеть передачу информации между каналами. Человек выбрал услугу и оставил пожелание по времени. Видит ли сотрудник эти сведения? Нужно ли клиенту повторять их по телефону? Совпадают ли условия на сайте с тем, что сообщает менеджер? Карта должна сохранять возвращения и повторные уточнения, если они наблюдались. Прямая стрелка от формы к покупке может скрыть существенную часть опыта.
Составить первую версию можно в обычной таблице. Для обсуждения большой последовательности удобна доска со стикерами, а для передачи задач достаточно документа со ссылками на основания. Выбирайте формат, который команда сможет обновлять. Красивая схема без источников и решений не полезнее простой таблицы.
Базовые элементы карты описаны в руководстве Nielsen Norman Group: человек, сценарий, этапы, действия и возможности улучшения. В рабочем документе к нашей заготовке добавьте отдельные поля для источника, слов клиента и ответственного. Их нельзя заполнить достоверно за вашу команду.
Текущий и будущий путь храните раздельно. В первом описывайте исследованный опыт и неизвестные места. Во втором показывайте предлагаемые изменения. Если сервис ещё не запущен, схема будущего пути остаётся проектом, который нужно проверить на сценариях использования.
После карты нужна конкретная задача и проверка
Фраза «улучшить коммуникацию» слишком широка для исполнения. Для нашего примера задача может звучать так: «После успешной отправки формы объяснить статус заявки и следующий шаг в соответствии с согласованным процессом записи». У задачи должны быть ответственный, исходное основание и условия приёмки.
Проверяйте весь связанный сценарий. Форма должна отправиться, сведения должны попасть ответственному сотруднику, а сообщение клиенту должно соответствовать фактическому статусу. Отдельно проверьте ошибку отправки: человеку нельзя показывать успешную запись, если заявка не принята. При UX/UI-аудите сайта такие наблюдения связывают с конкретным экраном, условиями воспроизведения и рекомендацией.
Понятность сообщения можно проверить, предложив участнику пройти сценарий и объяснить, что произошло и что он сделает дальше. Если задача касается повторных звонков, заранее определите, какие обращения считаются уточнением статуса. Иначе в один показатель попадут разговоры о цене, переносе времени и действительно непонятном подтверждении.
Перед выпуском изменения сверьте короткую карточку задачи:
- Проблема: что именно человек не смог сделать или понять и чем это подтверждено.
- Изменение: какой экран, текст или процесс должен работать иначе.
- Ответственный: кто исправляет проблему и кто принимает результат.
- Проверка: какой сценарий повторить, что должно произойти и где сохранить результат.
Приоритет выбирайте по подтверждённой проблеме, последствиям для клиента и сложности изменения. Сначала устраняйте препятствие, которое мешает завершить выбранную задачу. Новая анимация формы не решает отсутствие передачи заявки сотруднику.
После доработки обновите карту: что изменилось, что проверили, какие вопросы остались. Найденные проблемы можно включить в план доработок и сопровождения сайта с понятными критериями приёмки. CJM полезна как рабочее основание для решений. В Гуси-Лебеди мы советуем заканчивать её понятным продолжением: конкретным изменением, ответственным и способом увидеть, стало ли человеку проще решить свою задачу.