Как правильный ответ на фичреквесты поможет вырасти вашему продукту

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

Конечно, на запросы всегда можно ответить общими фразочками вроде «Следите за нашими обновлениями» или «Мы передадим вашу просьбу в продуктовую команду». Но полезнее погрузиться в проблему пользователя, чтобы полностью понять, чего он хочет достичь. 

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

Признать, что в продукте нет какой-либо фичи, которую запросил клиент, — абсолютно нормально.

Как работать с запросами на фичи?

Для начала важно понять, что все фичреквесты разные. Их можно разделить на три основных типа:

1. Проблемы с существующими фичами. Пользователь столкнулся с технической проблемой и не понимает, как сдвинуться с мертвой точки;
2. Доработка фичей. Пользователь не знает, как достичь определенного результата с помощью продукта;
3. Запросы на новые фичи. Пользователь просит добавить что-то, чего раньше не было в продукте.

Давайте разберем более подробно. 

1. Проблемы с существующими фичами.

Идеальных продуктов не существует. Наверняка в вашем сервисе что-то не работает так, как нужно. Возможно, некоторые пользователи даже пишут: «Фича, на которую я рассчитываю (и за которую плачу!) сломалась. Мне срочно нужна ваша помощь.» Конечно, можно просто отправить ошибку в Github и перейти к следующему диалогу, но мы считаем, что команда поддержки должна уметь показывать клиентам, как достичь результата, даже при наличии технических ограничений. 

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

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

2. Исправления фичей.

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

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

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

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

3. Запросы новых фичей. 

Самые коварные вопросы — о том, в чем ваш продукт действительно бессилен. Перед ответом на них спросите себя: вписывается ли этот реквест в ваш роадмап и стратегию развития продукта?

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

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

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

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

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

Приоритизация фичреквестов

Как только вы собрали данные о том, что клиенты хотят изменить в продукте, вам нужно приоритизировать их пожелания. 

Критерии, на которые можно опираться:

1. Жизненный цикл клиента. Возможно, есть смысл работать с пользователями, которые недавно зарегистрировались и с большой вероятностью могут уйти.
2. Ценные пользователи. Так как эти клиенты приносят больше всего денег, нужно обратить особое внимание на их отзывы. Особенно если эта группа важна для роста в долгосрочной перспективе. 
3. Сложность осуществления. Некоторые функциональные изменения просто реализовать, при этом они могут увеличить ценность для клиентов в 10 раз. С другой стороны, многие изменения выглядят просто, но требуют месяцев сложной разработки. 
4. Количество обратной связи. Записывайте, сколько раз запросили изменение какой-то функциональности, и вам будет проще обосновать ее важность для команды продукта. 

Заключение

Один раз собрав и приоритизировав обратную связь от пользователей, подумайте, как передать ее команде продукта. В конце концов, если 50 клиентов в неделю не могут найти какую-то кнопку, это точно знак, что нужно что-то поменять в интерфейсе. 

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

Это перевод статьи Intercom The right way to respond to feature requests.