Как правильно отвечать на запросы пользователей

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

На эти запросы можно отвечать стандартным “Следите за обновлениями в нашем Twitter” или готовым сообщением “Мы передадим ваши пожелания команде продукта”, но мы обнаружили, что эти запросы ценны своей глубокой информацией, которая поможет вам понять, чего пользователь пытается достичь. С их помощью вы сможете сохранить баланс между удовлетворением пользователей и сбором ценной информации, которая улучшит ценность вашего продукта.

Вот наши лучшие практики по управлению feature request в отделе поддержки пользователей.

Как управлять разными типами запросов

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

1. Нерешенные проблемы с существующей функцией — пользователь столкнулся с технической проблемой и не знает, как с этим справиться.
2. Улучшения функции — ваш клиент не уверен, как достичь определенного результата с вашим продуктом.
3. Запрос на совершенно новую функцию — клиент просит чего-то, что ещё не поддерживается в вашем продукте.

Давайте изучим эти типы подробнее.

1. Нерешенные проблемы с существующей функцией

Если у вас есть программа или веб-приложение, то они, скорее всего, являются частями вашего продукта, который не всегда работает так, как должен. Вероятно, вам пишут клиенты и говорят: “Эта функция, которая мне нужна (и за которую я плачу), не работает. Мне срочно нужна помощь”. Конечно, вы можете просто отправить задачу в GitHub и перейти к следующему разговору, но хорошая команда поддержки должна учить пользователей получать лучший результат, несмотря на технические ограничения.

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

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

2. Улучшение существующей функции

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

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

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

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

3. Запрос на абсолютно новые функции

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

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

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

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

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

Как приоритизировать запросы

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

Можно использовать такие факторы:

1. Время жизни пользователя. Если пользователи зарегистрировались недавно, более высок риск того, что они прекратят использовать ваш продукт.
2. Ценность пользователя. Вам стоит уделить особое внимание пользователям, которые платят вам больше всего. Особенно если эта группа играет ключевую роль в вашей долгосрочной стратегии.
3. Сложность реализации. Некоторые улучшения можно реализовать быстро и повысить ценность продукта для клиентов в 10 раз. Иногда некоторые улучшения кажутся простыми, но требуют месяцы сложной инженерной работы.
4. Объем обратной связи. Записывайте, сколько раз конкретное улучшение было запрошено —  это поможет вам передать некоторые запросы команде разработки.

Замыкание цикла

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

Мы управляем запросами, добавляя теги к каждому полученному вопросу. Это требует некоторых усилий, но как только вы внедрите этот процесс, вы получите все данные о разговорах с пользователями. Также наша исследовательская команда создает ежемесячные отчеты о том, что беспокоит наших клиентов. Эта информация передается продакт-менеджерам, которые могут распределить работу над определенными функциями и решить, что стоит включить в план. Если вы хотите организовать этот фидбэк более интересными способами, то вам стоит взглянуть на сторонние решения, такие как Productboard, NomNom или Trello PowerUp.

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