Customer Success Journey Map — это визуализация пути достижения клиентом успеха с помощью продукта компании. Скорее всего, вы не часто сталкивались с этим определением, но это полезный инструмент, который поможет приводить клиентов к успеху. Мы знаем о том, что его используют некоторые зарубежные компании, но на российском рынке примеров еще не встречали и надеемся, что у нас получится это изменить. Рассказываем, зачем это нужно и как пользоваться. Не благодарите.
Рассказывает
Михаил Селицкий
Чтобы решить запрос клиента, требуются совместные усилия множества людей, команд и отделов внутри компании. Даже в небольших стартапах разным командам нужно взаимодействовать между собой и передавать друг другу информацию. Нужен инструмент, который показывает, кто и когда взаимодействует с клиентами, и как отделы в компании обмениваются информацией. Выигрывает от этого клиент, потому что все команды работают друг с другом слаженно и сообща.
Но иногда получается, что маркетинг сделал рассылку, а поддержка не в курсе и не может ответить на уточняющие вопросы клиента. Или разработчики выпустили обновление с новым интерфейсом, а менеджер Customer Success об этом не знает, поэтому не поправил FAQ. Что делать?
Если вы тот самый человек, который отвечает за клиентский опыт в компании, то есть заботится о том, чтобы клиенты получали максимум пользы от продукта, попробуйте нарисовать Customer Success Journey Map. Все шаги мы расписали, а для краткости будем писать просто Success Map. Поехали?
1. Сформулируйте «успех клиента»
Чтобы построить Success Map, первое что нужно обозначить — что такое для вас успех клиента. Подумайте о том, для чего он пользуется вашим продуктом или сервисом, какой результат он ждет.
Например, если вы Apple Music, то успех вашего клиента — слушать любимых исполнителей без ограничений. Если вы Рокетбанк — удобно и экономично пользоваться собственными деньгами. Если вы банк для предпринимателей — без проблем принимать платежи, легко платить налоги и зарплату сотрудникам.
Понимание, зачем клиент пользуется вашим продуктом, поможет на следующем этапе. Когда успех клиента определен, то, двигаясь в обратном направлении, проще определить шаги клиента, которые приведут его к этому успеху.
2. Определите стадии жизненного цикла клиента
Подумайте о пути, который проходит клиент при использовании вашего продукта, чтобы достичь успеха, который вы определили ранее — это будет основой Customer Success Journey Map. Мы сформулировали шесть стадий, подходящих для многих компаний.
- Привлечение (Interest). Благодаря работе маркетинга, клиент узнает о продукте.
- Оценка продукта (Evaluation). Клиент оценивает продукт и осознает его ценность для себя. Определяет, как он поможет решить его проблему.
- Покупка (Purchase). Когда клиент понял, какую пользу ему принесет продукт, он его покупает.
- Знакомство с продуктом (Onboarding). После покупки клиент учится использовать продукт, чтобы как можно быстрее получить от него пользу.
- Осознание ценности продукта (Value Realization). Во время использования продукта клиент понимает, какую выгоду от этого получает.
- Продление подписки (Renewal). Если польза от продукта превышает затраты на него, то клиент продолжит им пользоваться.
3. Определите команды, которые участвуют в жизненном цикле клиента
Мы установили, зачем клиент пользуется продуктом, и как выглядит его жизненный цикл. Теперь определим, на каких стадиях разные команды взаимодействуют с клиентом как напрямую (поддержка, CS менеджер), так и условно (маркетинг, продакт-менеджер).
Скорее всего, эта информация уже есть и передается из «уст в уста». Самое время нанести ее на карту и зафиксировать взаимодействия.
4. Настройте передачу информации между командами
Так как в одной стадии жизненного цикла клиента вовлечены разные отделы, им понадобится делиться информацией между собой. Например, маркетингу передавать информацию поддержке о новых акциях, чтобы они могли рассказать о них клиентам. Или CS менеджеру передать продакт-менеджеру предложения клиентов.
На Success Map показываем не столько порядок передачи информации сколько способ. Это поможет избежать путаницы и вопросов, как и где передавать информацию в другой отдел.
Для обмена информацией можно использовать базу знаний или создать доски, например, в Notion или Trello. Там отдел маркетинга может создать доску с акциями, и при добавлении новой все, кто на нее подписан, получат уведомления. Таким же образом поддержка может добавлять информацию о багах, о которых им сообщили пользователи, чтобы о них узнали продакт-менеджер и разработчики.
Передавайте информацию другим отделам в той системе, которую они используют в своей работе. Для этого найдите в каждой команде стейкхолдера — человека, который позаботится о том, чтобы другие отделы были в курсе новостей.
Как настроить передачу информации?
- Определите, какая информация должна быть у разных отделов на каждом этапе жизненного цикла клиента. Классно, если для каждого типа информации вы опишете структуру, что именно там должно быть — поможет избежать ситуаций, где забыли что-то указать. Например, что для участия в акции есть ограничения по возрасту или городу. Структура описания акции с пунктом «ограничения» помогла бы этого избежать.
- Уточните, когда нужно передать информацию: сроки и дедлайны. Например, чтобы большой команде саппорта выучить новые тарифы, нужно 5–7 рабочих дней. Поэтому поддержка должна быть в курсе минимум за неделю до того, как о тарифах узнают клиенты.
- Найдите ответственных за передачу информации в конкретном отделе.
- Укажите, где вся информация хранится. Внутренняя база знаний или специально организованные доски в Notion или Trello.
Как это работает на практике
Например, в Рокетбанке главный отдел, взаимодействующий с клиентами, это поддержка. Поэтому она всегда должна была быть в курсе всех изменений, чтобы решать проблемы клиентов и отвечать на их вопросы. В каждом отделе Рокетбанка — маркетинге, доставке и остальных — был человек, который отвечал за то, чтобы транслировать изменения на поддержку. Когда что-то менялось, ответственный писал на почту, что это за изменения и как поддержка должна на них реагировать, а также отвечал на вопросы, если они возникали.
В проекте с Finom одна из задач была создать базу знаний для саппортов, которой до этого вообще не было. Проблема была в том, что знаниями обладают разные команды, но нет процесса коммуникации, то есть передачи этого знания из команды в команду. Поэтому в рамках проекта по созданию базы знаний мы взяли на себя проект по построению культуры новостей.
Мы сделали страницу в Notion, куда записывали вопросы к разным командам: разработчикам, продактам, дизайнерам. Составили правила, как этой страницей пользоваться:
- В каждой из этих команд был один человек, ответственный за то, чтобы проверять эту страницу, читать вопросы и отвечать на них.
- Проверять вопросы нужно было один раз за рабочий день.
Также мы договорились с продактами, чтобы команде поддержки дали доступ read only в Figma — инструменту для дизайна, где саппорт может всегда видеть, какие изменения в интерфейсе планируются и как они будут выглядеть. Это позволяет задавать вопросы по обновлениям и добавлять ответы в базу знаний еще до релиза. Поэтому к моменту, когда клиент начнет пользоваться новым интерфейсом, саппорт уже готов к вопросам по нему.
Создавая Success Map, вы столкнетесь с задачей — создать ценность этого процесса в головах коллег. До тех, кто связан с клиентом опосредованно, пользу от процесса донести будет сложно.
Проблема — мотивировать команды, которые напрямую не общаются с клиентами. Для этого нужно самим подавать пример. Это может делать первая линия поддержки, которая больше всех ощущает последствия от недостатка знаний. Поэтому чем больше сотрудники поддержки будут делиться информацией о болях клиентов, тем больше другие отделы будут видеть в этом ценность.
