Все записи

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

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

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

Даша qbr.jpg


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

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

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


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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Аналитика нагрузочного тестирования

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

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

Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.

Инструменты, которые упрощают iOS-разработку

Старый код усложняет рефакторинг, тесты в команде запускаются по-разному, баги не воспроизводятся на хорошем Wi-Fi, а после обновления инструментов локальная сборка начинает расходиться с CI — по отдельности все это мелочи, но именно они постепенно начинают тормозить разработку.

В статье Ринат, iOS-разработчик Naumen, рассказывает об инструментах, которые помогают ему решать такие задачи и упрощать повседневную работу.

ИИ против ИИ: кто победит в кибербезопасности

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

Денис — руководитель группы мониторинга и анализа инцидентов информационной безопасности в Naumen. Его команда отслеживает события в инфраструктуре, расследует инциденты и помогает коллегам разбираться с вопросами киберграмотности.

В статье на Хабре Денис рассказывает, какие именно изменения привнес ИИ в атаки, почему классическая модель защиты начинает давать сбои и где ИИ в защите действительно приносит пользу.

Все новости