Как понять, где клиенту неудобно, если он не жалуется?
Сейчас одна из задач моей команды - адаптировать метрику Bad CX, то есть негативного клиентского опыта, под специфику среднего и крупного бизнеса.
Для меня это история про «градусники», которые нужно расставить на разных участках клиентского пути. Они помогают увидеть, где возникают проблемы, а дальше - разобраться в причинах и исправить процесс. В среднем и крупном бизнесе это особенно непросто.
В одной компании с банком взаимодействуют десятки сотрудников - у каждого свои роль, полномочия и набор задач. Причем человек, который инициирует операцию, может вообще не заходить в личный кабинет, а тот, кто ее выполняет, может не участвовать в принятии решения.
Поэтому сценарий «клиент пользуется продуктом» здесь часто выглядит совсем не так, как в массовом сегменте.
Например, сейчас мы отдельно разбираемся с ролевыми моделями: кто что может делать от имени компании, кому какие действия доступны и насколько эта логика соответствует тому, как бизнес действительно устроен.
А чтобы находить такие места, мы собираем сигналы из разных источников: исследования клиентов и сотрудников, записи звонков, встречи, чаты, обращения. Метрика помогает увидеть проблему, но ответ на вопрос «почему?» нужно искать дальше.
В одном из качественных исследований накопительных продуктов мы, например, выявили триггеры, которые негативно влияют на клиентский опыт. Но семь триггеров не равно семь задач в бэклоге.
Следующий шаг - понять, насколько каждая проблема массовая, кого именно она затрагивает, насколько критична и связана ли с конкретными бизнес-показателями.
Сейчас у нас накоплено около 20 таких гипотез. Часть уже передали продуктовым командам, что-то находится в разработке, а некоторые изменения уже запустили. И, кажется, это бесконечная история - в хорошем смысле.
Когда мы настроим метрику, работа не закончится. Новые исследования будут находить сценарии, которых раньше не было в наших «градусниках». А значит, их придется дополнять и снова проверять, что происходит на клиентском пути.
Для меня здесь главное - не превратить Bad CX в красивую цифру в отчете. Метрика полезна, когда помогает найти конкретную проблему и довести ее до исправления.
Если вы работаете с Т-Бизнесом, расскажите о своем опыте в комментариях или личке: что в процессах хотелось бы изменить, а что, наоборот, работает удобно и хорошо. Такие истории помогают увидеть клиентский путь не только изнутри и понять, что стоит улучшать, а что важно сохранить.
· 7 ч
Андрей, ваш пример про «инициирует один, выполняет другой» для меня объясняет саму тишину: если кабинет сделан под одного «пользователя компании», то у директора, бухгалтера и исполнителя внутри продукта нет своего инструмента — есть общий, который никому из них не подходит до конца. Они не жалуются — они обходят: просят коллегу «посмотри у себя» или делают по-старому. Снаружи это выглядит как «всё в порядке».
Поэтому я бы начинал не с градусников на пути, а с ролей: сколько их реально взаимодействует с банком, и у скольких есть свой инструмент, которым удобно именно им. А измерять — не обращениями, а использованием: заходит ли роль сама, делает ли операцию до конца, или рядом живёт обходной путь.
Из практики: когда внедряли систему управления инцидентами, сразу делали её одной конструкцией с тремя входами — веб для администратора, программный интерфейс для архитектора, мессенджер для дежурного. Один из критериев успеха: каждая роль пользуется своим входом и никого не просит сделать это за неё.
И про «работа не закончится» — да, и это нормально. Роли меняются, появляются новые сценарии, и система должна меняться вместе с ними; если она перестала меняться, значит, перестала отражать то, как бизнес живёт.
Неудобство измеряется не жалобами, а тем, пользуются ли инструментом.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён