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

product-management

Обратную связь собирает каждая SaaS-команда, но мало у кого она доживает до планирования дорожной карты. Отзывы, разбросанные по тикетам поддержки, звонкам отдела продаж, веткам в Slack и забытой форме в Typeform, — это не сигнал, а набор историй. По таким историям дорожную карту строят для того, кто крикнул последним. Решение не в том, чтобы собирать больше. Нужны одно место, один процесс и цикл, который видно со стороны.

Один вход: публичная доска обратной связи

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

  • Дубли отсекаются на входе. Пользователь хочет попросить экспорт в CSV, находит пост с 40 голосами и добавляет свой, а не создаёт 41-й тикет, который потом кому-то придётся объединять с остальными.

  • Голосование превращает истории в цифры. «Это хотят несколько клиентов» становится «63 пользователя проголосовали, 12 описали в комментариях свой сценарий».

  • Открытость задаёт ожидания. Пользователи видят, что запланировано, а что нет, и тикетов «есть новости по…?» незаметно становится меньше.

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

Минимум полей в запросе

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

Разбирайте запросы на доске, а не в таблице

Обратная связь без процесса превращается в болото. Рабочая модель — набор колонок в духе канбана, по которым движется каждый пост, например: Новое → На рассмотрении → Запланировано → В работе → Выпущено, и боковой выход — Не планируется.

Чтобы это работало, нужны два правила:

  • Каждый новый пост получает статус в оговорённый срок (за неделю это вполне реально). Сменить статус почти ничего не стоит, а сообщает он больше, чем ответ.

  • «Не планируется» — тоже ответ. Открытый отказ с одной фразой объяснения вызывает больше доверия, чем запрос, который вечно гниёт в «Новом». К тому же отказ не даёт заново спорить о том же запросе в пяти новых постах.

Если ваш инструмент обратной связи отдаёт колонки через API, запланированное и то, что в работе, можно показать прямо в приложении, а не только на доске.

Голоса нужно толковать, а не просто складывать

Число голосов — начало расстановки приоритетов, а не конец. Внесите три поправки:

  • Учитывайте сегмент. Десять голосов от ваших идеальных клиентов могут весить больше сотни голосов от пользователей тарифа, от которого вы уходите. Когда обратная связь привязана к известным пользователям, видно, кто именно просит.

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

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

Замыкайте цикл: публично и лично

Именно цикл отличает систему обратной связи от ящика для предложений. У него два уровня:

  • Публично: когда что-то вышло, перенесите пост в «Выпущено» и дайте ссылку на запись журнала изменений, где об этом объявили. Если журнал изменений и доска обратной связи живут в одной системе, ссылка ничего не стоит, а отдача копится: пользователи, которые видят, что запросы выполняются, пишут запросы лучше.

  • Лично: те, кто голосовал, вправе узнать, что то, о чём они просили, появилось. Уведомление о выпуске для проголосовавших превращает самых вовлечённых пользователей в рупор ваших релизов.

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

Модерация и тон

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

Инструменты: что важно на деле

Что бы вы ни выбрали — отдельный инструмент для обратной связи или модуль обратной связи в более широкой контент-платформе, — на практике важно вот что: публичные запросы с голосованием и комментариями, колонки для разбора, известные пользователи, API, чтобы данные обратной связи попадали в ваши собственные дашборды и в интерфейс приложения, и журнал изменений по соседству, чтобы замкнуть цикл. Доски обратной связи Kookee закрывают эти пункты, и к ним сразу прилагаются журнал изменений, дорожная карта и центр помощи. Именно поэтому замкнуть цикл здесь дёшево. Отдельные инструменты тоже подойдут, если вы готовы сшивать цикл сами.

Запускаться без своего фронтенда — нормально: готовый портал с доской и дорожной картой начинает собирать запросы с первого дня. Позже доску и дорожную карту только для чтения можно вывести в своём приложении — через SDK или React-компоненты. Чтение работает через API, а запросы, голоса и комментарии остаются на портале: там каждый человек учитывается один раз и там же работает модерация.

Система, которую можно запустить на этой неделе

  1. Заведите публичную доску с голосованием и 4–6 колонками для разбора.

  2. Наполните её десятью запросами, которые вы уже знаете по тикетам поддержки.

  3. Поставьте на неё ссылку в приложении и объявите о ней в журнале изменений.

  4. Разбирайте запросы каждую неделю, давайте статус каждому посту, говорите «не планируется» вслух.

  5. Выпустите что-то с доски, отметьте как выпущенное, дайте ссылку на запись журнала изменений.

Прогоните этот цикл квартал, и разговор о дорожной карте изменится: меньше «мне кажется, пользователи хотят», больше «вот о чём просили 60 известных нам пользователей, вот какая проблема за этим стоит, и вот что мы им ответили».