Как встреча QBR выстроила баланс между продуктом и клиентским сервисом

Привет! Меня зовут Даша, я занимаюсь развитием сервиса Скорозвон — облачного решения для автоматизации коммуникаций в отделах продаж и колл‑центрах. И я менеджер продукта.

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

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

В статье расскажу, как мы пришли к этому формату, почему первая попытка собирать идеи клиентов в Excel не сработала, как устроены наши QBR и что они изменили для всех участников.

Что мы называем QBR

QBR, или Quarterly Business Review, — регулярная встреча с клиентом, которую мы проводим раз в три-четыре месяца.

В ней участвуют: 

• представители клиента;
  

• персональный менеджер;

• руководитель клиентского сервиса;

• менеджер продукта.

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

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

Для команды клиентского сервиса это еще и возможность иначе выстраивать отношения с клиентом — не только реагировать на возникающие вопросы, но и заранее интересоваться его задачами. Вот как одна из коллег описывает ценность таких встреч:

Почему обычной коммуникации оказалось недостаточно

До QBR взаимодействие в основном начиналось со стороны клиента. Если возникал инцидент, он обращался в поддержку. Если требовалась помощь с настройками, оптимизацией работы или повторяющейся проблемой, подключался персональный менеджер. Такая схема решала текущие задачи, но оставалась реактивной: сначала что-то происходило, затем мы начинали действовать.

Одну из проблем руководитель сервиса сформулировал так:

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

Мы видели отдельный запрос, но не всегда понимали его контекст:

• как сейчас устроен процесс;

• почему клиенту понадобилась доработка;

• какого результата он хочет достичь;

• насколько проблема критична;

• сталкиваются ли с ней другие компании.

У клиента тоже оставались вопросы. Ему не хватало информации о развитии продукта и возможности подробно объяснить свою позицию. Он передавал пожелание, но не всегда понимал, что с ним произошло дальше и может ли его обратная связь повлиять на изменения.

Первая попытка: таблица с идеями клиентов

До QBR мы уже пробовали объединить информацию от сервиса и продукта. Для этого завели Excel-таблицу, куда менеджеры записывали идеи и запросы клиентов.

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

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

Почему мы разделили коммуникацию на low-touch и high-touch

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

Поэтому мы опираемся на два подхода к коммуникации.

Low-touch

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

High-touch

Для ключевых или целевых клиентов нужен персональный подход. В большинстве компаний это небольшая часть клиентской базы, около 20%, которая при этом приносит значимую долю выручки. С такими клиентами важно подробно обсуждать процессы, планы и результаты работы с продуктом. 

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

Как устроен наш QBR

У QBR нет единственно правильного сценария. Мы собрали структуру под свой продукт, а затем корректировали ее по итогам встреч.

Перед разговором персональный менеджер просматривает историю обращений, вспоминает основные сложности клиента и поднимает договоренности с предыдущего QBR. 

Сама встреча состоит из девяти частей.

1. Знакомимся и собираем контекст

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

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

2. Обсуждаем планы бизнеса

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

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

3. Ищем смежные задачи

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

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

4. Определяем метрику эффективности бизнеса

Определяем, по каким показателям клиент оценивает пользу сервиса, и связываем их с его бизнес-целями. Например, компания зарабатывает на успешных сделках. Количество сделок зависит в том числе от количества состоявшихся разговоров. Скорозвон помогает сотрудникам проводить больше таких разговоров.

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

5. Разбираем проблемы

Спрашиваем, какие сложности накопились у клиента и что мешает ему работать с сервисом. Часть вопросов можно решить прямо на встрече: объяснить настройку, показать нужную функцию или предложить другой сценарий. Остальные фиксируем и берем на дополнительный разбор.

Важно не обещать реализацию каждой идеи. На этом этапе задача команды — понять проблему и собрать контекст.

6. Рассказываем об обновлениях и планах продукта

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

Поэтому на QBR мы рассказываем:

• что изменилось в продукте;

• какие возможности появились;

• куда мы планируем двигаться;

• почему выбрали именно это направление;

• какую пользу изменения могут принести бизнесу клиента.

Мы стараемся не перечислять релизы, а показывать их на понятных примерах. Так клиент лучше видит объем работы команды и понимает логику развития сервиса.

7. Обсуждаем конкурентов

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

Из таких разговоров мы узнаем:

• с какими продуктами нас сравнивают;

• какие преимущества клиент видит у нас;

• чего ему не хватает;

• какие аргументы используют другие компании;

• какие предложения сейчас появляются на рынке.

8. Получаем оценку и фиксируем договоренности

В конце встречи мы просим клиента оценить сервис по шкале от 0 до 10 и спрашиваем, чего не хватило до максимальной оценки.

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

После встречи фиксируем:

• что нужно проверить;

• с каким ответом вернуться;

• кто отвечает за следующий шаг;

• когда клиент получит обратную связь.

Ошибки в работе продукта исправляем обязательно. Пожелания по развитию анализируем вместе с разработкой и сопоставляем с другими запросами. Если задача не входит в планы, честно объясняем это клиенту, а не оставляем ее в неопределенном статусе.

9. Повторяем цикл

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

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

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

У каждого участника со стороны нашей команды своя роль.

Чего мы опасались при запуске QBR

Формат не начал работать идеально с первой встречи. У команды было несколько опасений, и часть из них действительно подтверждалась.

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

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

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

Нам важно сохранить баланс между тремя направлениями:

• контекстом и планами клиента;

• текущими проблемами;

• развитием продукта.

«Клиент придет и скажет, что все плохо»

Часто это не так, но даже если проблема есть ведем открытый диалог. У нас были QBR после массового сбоя. Клиент, конечно, вспоминал произошедшее. В такой ситуации бессмысленно делать вид, что проблемы не было, или пытаться быстрее перейти к презентации обновлений.

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

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

«На следующей встрече окажется, что мы ничего не сделали»

Регулярность QBR повышает ответственность команды. Нельзя раз в три месяца возвращаться к клиенту и снова говорить, что все вопросы остались без ответа. Но и реализовать каждое пожелание невозможно.

Мы разделяем запросы на два типа:

1. Ошибки в работе продукта необходимо исправлять.

2. Пожелания по развитию проходят анализ. Мы обсуждаем их с разработкой, смотрим на похожие запросы и оцениваем, насколько они соответствуют направлению продукта.

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

Что изменилось после запуска QBR

Формат дал каждой стороне свой результат.

Для клиента

• Лучше понимает направление развития продукта и видит, что происходит с его запросами. 

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

Среди клиентов, с которыми мы проводили QBR, отток был почти нулевым. За период наблюдений ушел один клиент, который уже разрабатывал собственное решение. Мы не связываем этот результат только с QBR: на уход влияет много факторов. Но регулярный разговор помогает раньше заметить риски и обсудить проблемы до того, как они станут критичными.

Для клиентского сервиса

• Команда перестает работать только с отдельными обращениями и начинает лучше понимать процессы клиента. 

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

Это меняет и восприятие сервиса со стороны клиента. За поддержкой и настройками он начинает видеть команду, которая понимает его контекст и помогает искать решение.

Для продукта

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

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

Четыре условия, без которых QBR не работает

За время проведения встреч мы выделили четыре принципа.

1. Сервис и продукт готовятся вместе

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

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

2. Клиент получает достаточно времени для разговора

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

3. Со стороны клиента участвуют люди разных уровней

Руководитель бизнеса и сотрудник, который каждый день работает в системе, видят продукт по-разному.

Поэтому полезно приглашать на QBR и пользователей продукта, и представителей бизнеса. Только вместе их ответы дают достаточно полную картину.

4. Итоги превращаются в действия

Мы делаем запись встречи и заранее объясняем клиенту, что запись нужна для фиксации результатов. Участники относятся к этому с пониманием.

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

К каким выводам мы пришли

QBR работает не потому, что несколько руководителей раз в квартал встречаются с клиентом. Ценность появляется в полном цикле: подготовились → услышали клиента → договорились о действиях → вернулись с ответом → обсудили изменения.

Этот формат помог нам соединить клиентский сервис и продукт, добавить к отдельным запросам бизнес-контекст и перейти от реакции на проблемы к более системной работе.

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

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