УПРАВЛЯЕМ УЛУЧШЕНИЯМИ

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

Документировать обратную связь можно при помощи кейсов в CRM. Если у вас есть возможность настройки системы, для кейсов заведите поле «источник» (source), значения которого соответствовали бы различным способам сбора информации из предыдущей статьи:

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

Например,
Первичный фидбэк «У вас ужасное приложение» после уточнения информации может превратиться в «При попытке входа через соц.сети, приложение просто закрывается. Я использую последнюю версию iOS», на базе которого уже можно действовать.

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

Если фидбэк классифицирован как идея по улучшению / структурная проблема, требующая решения, есть как минимум 3 метода ее распределения:

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

Регулярно прорабатывать все поступившие идеи / проблемы в составе кросс-функциональной группы по улучшению клиентского опыта (например, в том же составе, в котором вы создавали customer journey map).

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

С задачами все довольно просто: в CRM должны быть настроены оповещения сотрудников о получении задачи, а также возможность для сотрудника посмотреть список всех его текущих задач. Если у вас есть доступ к настройке CRM, для удобства использования рекомендую проставить значения статуса по задачам: Open, In progress, In question, cancelled и completed:

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

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

Добавление реализованных улучшений актуализирует текущую карту пути клиента (AS-IS), в то время как добавление проектов реализующихся, запланированных или отложенных на будущее, помогает нам рисовать целевую картину (TO-BE).

Итак, клиент дал нам обратную связь, мы завершили требуемое действие. Что дальше?
Не забыть к нему вернуться!

В рамках управления задачами закрывающая коммуникация в основном играет роль проверки, что все в порядке, клиент доволен и у него нет дополнительных вопросов (так называемое positive closure). В зависимости от количества клиентов, вы можете применять как телефонные звонки, так и автоматизированные email / push-сообщения / сообщения в мессенджерах.

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

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

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

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

Для визуализации performance компании по основным метрикам вы можете использовать множество инструментов. Это может быть как встроенный функционал вашей CRM-системы, так и другие инструменты визуализации данных. Однако если мы говорим о всем пути клиента, данные для расчета метрик будут подтягиваться не только из CRM, но и из Google Analytics / Яндекс.Метрики, маркетинговых платформ, самого продукта, сервисов по проведению опросов и многого другого.

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

Структуру самого дэшборда каждый выбирает для себя сам, но я порекомендовал бы сделать структуру максимально схожей с Customer Journey, на основе которого были выбраны эти метрики.

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

Итак, у нас правильно выстроен сбор данных, мы правильно структурировали их в базе, построили единый дэшборд. Осталось запустить последнее действие в рамках этой статьи – корректирующие меры.

Во-первых, по каждой из метрик необходимо установить целевые показатели (KPI). Важно заметить, что установка целевых показателей не должна делаться исключительно «внутри» компании: предложения подразделений необходимо соотносить с ожиданиями клиентов и эффективностью конкурентов по каждой из точек контакта. В этом нам могут помочь, соответственно, клиентские интервью и конкурентный mystery shopping.

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

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