Как учитывать клиентские пожелания в продукте и получать сотни пятизвездочных отзывов
Привет. На связи Николай Ермаков, сооснователь сервиса «ПланФакт». Уже пять лет мы записываем пожелания клиентов и включаем их в разработку. Раньше мы старались реализовать каждое из них, но иногда клиенты всё равно оставались недовольны. Были и такие кейсы, когда фичей в итоге пользовалось всего 10 человек из нескольких тысяч.
В статье расскажу, как мы изменили подход к пожеланиям клиентов, ускорили выход новых фич и собрали более 1000 положительных отзывов.
1. Превратить обработку пожеланий клиентов в систему
Мы всегда делали ставку на клиентский сервис. Порой это буквально значило «делаем всё, что скажет клиент». Мы брали пожелания в работу случайно, чаще от клиентов, кто просил настойчивей всего.
В итоге мы могли полгода разрабатывать фичу, которая нужна только одной компании и то раз в месяц. Продукт буксовал, и, как ни странно, все были недовольны. Большинству клиентов не хватало удобных инструментов для работы, сервис догоняли конкуренты.
Также не нравились сроки разработки. Мы рассказывали клиентам, что и когда сделаем, и в итоге не всегда попадали в ожидания. Бывает, что одна галочка в интерфейсе тянет за собой существенные переделки под капотом, которые сразу не видны. Из-за этого разработка занимает больше времени.
Совет: не сообщайте клиентам точные сроки разработки. По разным причинам они иногда сдвигаются, и это вызывает негатив. Либо указывайте не конкретную дату, а бОльший интервал, например, квартал.
Тогда мы решили превратить обработку пожеланий в систему. Мы создали отдельный бизнес-процесс, правила сбора пожеланий для сотрудников поддержки и критерии их отбора для маркетинга и продактов.
Таймлайн процесса выглядит так:
- Каждый день служба поддержки собирает пожелания от клиентов через внутренний чат ПланФакта, звонки и отзывы на сторонних ресурсах. Все пожелания становятся задачами в Jira в течение 1 часа, как клиент их озвучил или менеджер нашел в отзыве.
- Раз в неделю новые пожелания разбирают продуктовая команда и руководство службы поддержки. Они проверяют пожелания на дубли, определяют приоритетность и сложность исполнения и вносят в план реализации, если разработка необходима.
- Раз в три месяца пожелания приоритезирует продуктовая команда и включает нужные в спринты на следующий квартал.
- После реализации пожеланий все клиенты, которые их просили, получают личное сообщение, что и как было реализовано.
2. Собрать пожелания в одном месте
После разработки бизнес-процессов и принципов системы пожеланий мы организовали их сбор и решали две задачи:
- побудить клиентов оставлять пожелания;
- сохранить 100% пожеланий клиентов — неважно, где, кем и в какой форме они сказаны.
Системы поиска упоминаний компании в интернете нам не подходили. Они дорогие и лучше всего работают с аудиторией в сотни тысяч пользователей, например, как у крупных банков.
Чтобы не искать отзывы клиентов вручную по всему интернету, общение мы постарались свести к двум каналам. Для техподдержки, вопросов и уведомлений используем чат в приложении и на сайте. Для публикации отзывов — страницу на startpack.
90% пожеланий мы получаем именно из этих каналов: из чата мы узнаем 70%, а из отзывов еще 20%. Оставшиеся 10% пожеланий — это звонки менеджерам, электронные письма или встречи на конференциях. Также отдел маркетинга регулярно проверяет отзывы на 2ГИС, Гугл- и Яндекс.Картах. Пожеланий с них меньше процента.
Внутренний чат интегрирует учёт пожеланий во все системы. Например, отзывы клиентов записываются в CRM, а операторы службы поддержки создают задачи задачи в Jira.
Чат делает процессы прозрачными и добавляет статистики. Мы считаем метрики удовлетворенности клиентов, скорость ответов, качество работы сотрудников и еще десяток разных параметров. Это позволяет нам ставить KPI и оптимизировать систему. Как мы внедряли чат и что получили в итоге, подробно описано в статье «Семь шагов к идеальной службе поддержки».
«Мы понимаем, что хотят клиенты, не только из пожеланий. Каждое обращение в чате мы дополнительно тегируем. Если собирается много вопросов по одной теме, то разбираемся почему и решаем проблему: пишем обучающие статьи и инструкции или меняем интерфейс на более понятный».
3. Отсортировать пожелания по важности и простоте реализации
Одни клиенты просят добавить пару кнопок в интерфейс, а пожелания других затрагивают половину кода сервиса. Воплощать их все невозможно: потребуются десятки лет разработки или огромная команда с неограниченным бюджетом. Хорошо, что всё реализовывать и не нужно.
Каждое пожелание от клиента оценивает продуктовая команда. Она учитывает время реализации, какую пользу получат от этого пользователи, сколько клиентов просят подобное и т. д. После оценки пожеланий самые востребованные из них попадают в план следующего квартала.
Пример выбора: интеграцию с МоржТрансибБанком, которым пользуется один клиент, мы отложим на потом, а интеграцию с маркетплейсами, которую просят 100 человек, мы возьмем в работу сразу.
Совет: обращайте особое внимание на пожелания постоянных клиентов. Они лучше всего знают продукт, успели попробовать его в самых разных сценариях.
Последним крупным реализованным пожеланием стал раздел «Сделки». Он помогает удобно учитывать оплаты и отгрузки по сделкам/заказам в работе, показывает прибыль и рентабельность.
«Сделки» просили 40 клиентов на протяжении года. Мы не могли взять в работу это пожелание сразу же, потому что разработка оценивалась как сложная. В итоге спустя три месяца «Сделки» появились в приложении для всех пользователей.
Иногда пожелание просто реализовать и оно сделает сервис дружелюбнее и удобнее для многих. Такое пожелание продуктовая команда может взять в работу сразу, без долгого квартального планирования.
4. Увеличить скорость ответа клиенту и сократить lead-time пожеланий
После настройки сбора, сортировки и реализации пожеланий мы оптимизировали систему: мы с первого дня отвечаем быстро, менее минуты, это не связано с пожеланиями.
- Уменьшили время первого ответа поддержки в чате до 30 секунд. Мы всегда отвечали быстро — за 1 минуту — и решили еще улучшить скорость ответа.
- Уменьшили lead-time от регистрации пожелания до реализации в сервисе.
Чем быстрее мы отвечаем, тем проще клиентам оставлять пожелания и отзывы. Клиенты быстрее решают проблемы и меньше уходят из сервиса. Классическая поддержка через тикеты, почту и телефон только мешает.
Мы добились скорости первого ответа меньше 30 секунд. Это значение сохраняется в выходные дни и даже в новогодние праздники
Пожелания можно внедрять быстрее, если увеличить бюджет и нанять новых разработчиков. Но тогда большинство из них станут экономически невыгодными.
Мы решили воспринимать пожелания клиентов как гипотезы. Вместо разработки полного функционала их нужно обязательно проверить с помощью MVP. Например, так мы реализовали «Сделки».
Клиенты просили разное:
«Не хватает еще одной разбивки данных. Объясню: у нас есть индивидуальные номера заказов и есть менеджеры, ведущие много заказов. Номера мы не заводим как проекты, так как их очень много, а под проектами понимаем менеджеров. Не хватает возможности фильтровать и по тому, и по тому признаку».
«У вас есть разделение не по проектам, а по договорам? У меня просто по одному проекту идет сразу несколько договоров с заказчиком».
«Сделать, чтобы проект находился одновременно в двух группах, например по менеджеру, который с ним работает, и по категории проекта (услуги, торговля...)».
Если бы взяли в работу всё, то разработка затянулась бы на пару лет. Мы упростили сервис до MVP: он отслеживает исполнение договоров и контролирует, сколько должны клиент и заказчик друг другу.
Эти функции просили больше всего, и так мы сократили срок разработки с нескольких лет до трех месяцев
Совет: воспринимайте пожелания клиента как гипотезы для исследования рынка. Чтобы их проверить, нужен MVP, а не полный функционал.
5. Продолжать общение с клиентами
После того как клиент рассказал своё пожелание, мы продолжаем с ним общаться.
Менеджер задает дополнительные вопросы и выясняет сценарии, как клиент собирается использовать новую функцию. Мы уточняем, что мешает сейчас, как должно выглядеть улучшение, какие есть хорошие примеры.
Вся информация попадает в карточку Jira. Так нам не нужно дополнительно тревожить клиента в будущем, когда будем реализовывать пожелание.
Если пожелание сложное и затрагивает сразу много пользователей, в чате мы проводим дополнительные опросы. Например, при интеграции с 1С мы узнавали версию, которой пользуются клиенты. Всего опрос увидели 1000 человек, ответили — 350.
После реализации пожелания мы показываем уведомление в чате всем клиентам, которые его хотели. Однако не тревожим их, если c обращения прошло больше двух месяцев. Обо всех крупных обновлениях уведомляем всех массовыми рассылками и поп-апами в сервисе.
Клиенты в любой момент могут узнать о новых возможностях и интеграциях в базе знаний.
Результаты: 1000 положительных отзывов и 98% удовлетворенность клиентов
На startpack наш сервис занимает первое место с 1013 отзывами. Из них только восемь с оценкой «три звезды» и ниже.
После каждого обращения в чат клиент может оценить разговор с поддержкой кнопками «хорошо», «плохо» и «отлично». По ним мы считаем суммарную удовлетворенность клиентов. Последние полгода она держится на отметке 98%.
Сейчас система сбора пожеланий отлажена и полностью нас устраивает. Но нет предела совершенству. Поделитесь своим опытом в комментариях, интересно, как это устроено у коллег по SaaS-цеху.