Все записи

Клиент + Продакт + Сервис = QBR

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

Даша, менеджер продукта в команде Скорозвон, рассказала, как они выстроили регулярное взаимодействие с клиентами и почему в таких встречах одновременно нужны продукт и клиентский сервис.

Даша qbr.jpg


Что такое Quarterly Business Review (QBR)

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

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


Зачем вообще появился этот формат

Он вырос из конкретных проблем. 

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


Почему не сработали Excel-таблицы

До QBR мы пробовали собирать запросы клиентов через Excel-таблицы: менеджеры фиксировали идеи, передавали продукту, но дальше все разваливалось.
Не хватало контекста + появлялись вопросы = мотивация заполнять таблицы падала.


Что изменилось, когда позвали клиента в диалог

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


Как устроена встреча

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

Что важно в ролях

  1. Менеджер клиента — ведет встречу и держит контекст.
  2. Руководитель сервиса — подключается к сложным вопросам.
  3. Менеджер продукта — отвечает за продуктовую экспертизу.
Без полного состава встреча сильно теряет в качестве.
таблица qbr.png

Что может пойти не так

Встреча превращается в список «хотелок»

Тут нужно вернуть разговор к структуре: сначала бизнес и контекст, потом — пожелания.

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

Стоит заранее объяснить, зачем это нужно — чтобы лучше настроить продукт под задачи бизнеса.

Клиент приходит с негативом

Это нормально. Лучше обсудить проблему открыто, чем получить ее в отложенном виде. 

К следующей встрече нет изменений

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


QBR работает, если

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

Похожие новости

Почему интерфейсы такие, какие они есть и какими они должны быть

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

Динара — владелец продукта Naumen Service Desk и аналитик в команде внедрения. В работе с Enterprise-клиентами она регулярно сталкивается с противоречием: система помогает бизнесу, но усложняет жизнь пользователю.

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

Что такое вайбкодинг

От дедушки ушел, от бабушки ушел... А от дедлайна и багов — тем более. В сказке Колобку помогла наглость, а в вайбкодинге помогает умение правильно составить запрос. Об этом рассказываем в статье.

Зачем продукту исследования

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

Поговорили с Илоной, продуктовым дизайнером Project Ruler, о том, как команда использует исследования в работе и какие выводы из этого делает.

Все новости