Все записи

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

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

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

Даша qbr.jpg


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

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

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


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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Как посмотреть на задачу глазами исполнителя

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

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

Как замечать тренды раньше конкурентов

Каждый год на рынок выходит более 30 000 новых продуктов, но успеха добиваются лишь 15–20% из них. Часто проблема не в качестве продукта, а в том, что рынок меняется быстрее, чем команды успевают адаптироваться к новым запросам пользователей и технологиям.

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

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

Путь тестировщика: от User Story до Test Case

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

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

Все новости