Все записи

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

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

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

Даша qbr.jpg


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

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

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


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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Подборка материалов: что почитать разработчику

В этой подборке — пять материалов о повседневных задачах разработчика: работе с кодом и коммитами, автоматизации, полезных инструментах и технических решениях на примерах iOS и Java.

Правила хорошего резюме

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

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

Как масштабировать знания, а не нагрузку

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

С этим столкнулась команда клиентского сервиса ITSM 365. Кира, бизнес-аналитик клиентского сервиса и куратор командной базы знаний, рассказала, как команда постепенно выстроила систему, которая помогает не искать одни и те же решения снова и снова.


Все новости