Один продукт - несколько покупателей: почему в B2B нельзя говорить со всеми одинаково

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

Он говорит:

• план снова не выполнен;
• РОП утверждает, что все нормально;
• менеджеры уверяют, что делают повторные касания;
• маркетинг и продажи спорят о качестве лидов;
• новый скрипт внедрили, но работает ли он, непонятно.

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

Но дальше обнаружился еще один слой.

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

Потому что у сложного B2B-продукта почти никогда нет одного покупателя в практическом смысле.

Договор может подписывать собственник. Инициировать поиск может РОП. Проверять безопасность и внедрение могут другие подразделения. Каждый день работать с системой будут менеджеры и контроль качества. Маркетинг захочет получить из того же массива совсем другие ответы.

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

Мы уже понимали, что ролей несколько. Но описывали их по “книжкам”

После встречи с Сергеем Жариковым мы довольно быстро зафиксировали логичную модель:

• собственник покупает деньги, прозрачность и управляемость;
• коммерческий директор или РОП покупает контроль исполнения и рост KPI;
• менеджер покупает удобство и помощь в работе;
• маркетинг покупает понимание спроса и качества лидов;
• контроль качества покупает автоматизацию проверок.

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

Собственник не открывает встречу словами:

Мне нужна дополнительная управляемость коммерческой системой.

РОП не говорит:

Я хотел бы приобрести доказуемость управленческих решений.

Менеджер не формулирует запрос как:

Мне нужна автоматизация личного развития.

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

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

Для меня это стало следующим важным осознанием:

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

И здесь один продукт начинает распадаться на несколько совершенно разных рабочих историй.

Собственнику нужен не «контроль». Ему нужно понять, пора ли вмешиваться

По книжкам

Собственник покупает:

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

На глубоком уровне это, скорее всего, верно. Но в реальной работе его вопрос часто звучит иначе:

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

Я не понимаю, кому верить: маркетингу, продажам или отчету в CRM.

Мне нужно понять, команда сама выправит ситуацию или уже пора подключаться.

Я не собираюсь каждый день слушать звонки и разбирать работу каждого менеджера.

За этими фразами стоит не желание получить еще один дашборд.

Собственнику нужен короткий ответ:

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

Он не хочет жить внутри операционного интерфейса РОПа. Ему не нужны десятки критериев на первом экране. Ему нужен фокус, тренд и доверие к цифре. Например:

После совещания доля звонков с зафиксированным следующим шагом росла три недели, а затем резко вернулась к исходному уровню.

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

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

РОПу нужен не просто «контроль». Ему нужно понимать, с кем и о чем работать сегодня

По книжкам

Коммерческий директор или РОП покупает:

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

Но в жизни его рабочая ситуация может звучать так:

Я не могу каждый день слушать сотни звонков.

Менеджеры говорят, что все делают, но показатель не растет.

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

После совещания все согласились, а через неделю вернулись к старой работе.

Я вижу слабый результат, но не понимаю, что именно разбирать с человеком.

В отличие от собственника, РОПу недостаточно сигнала «нужно вмешательство». Он и есть тот человек, который должен вмешаться. Ему нужно увидеть:

• какой критерий проседает;
• это системная проблема или локальная;
• у каких сотрудников есть отклонение;
• в каких коммуникациях оно проявилось;
• как выглядит сильный пример;
• согласован ли сам критерий;
• какое действие разумно сделать дальше.

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

У Иванова низкая оценка.

А:

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

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

Менеджеру нужен не «удобный инструмент». Ему нужно понимать, почему его оценили именно так и что делать дальше

По книжкам

Менеджер покупает:

• удобство;
• автоматизацию рутины;
• персональные подсказки;
• обучение;
• рост личной эффективности.

Но человек, которого начинает оценивать новая система, может думать совсем о другом:

Почему звонок оценили именно так?

Что конкретно я должен был сделать иначе?

Это правило действительно принято в компании или его только что придумала нейросеть?

Мне опять дадут еще один отчет и заставят что-то заполнять?

Эта система помогает мне продать или просто дает руководителю новый способ меня контролировать?

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

• какой критерий проверялся;
• где именно в его коммуникации система увидела выполнение или нарушение;
• на какой цитате основана оценка;
• как этот критерий понимает руководитель;
• можно ли аргументированно не согласиться;
• какой следующий шаг поможет исправить ситуацию в текущей сделке.

Менеджеру недостаточно показать, что он «красный» в отчете. Ему нужно объяснение:

Следующий шаг не зафиксирован, потому что в разговоре нет конкретной договоренности о дате, времени или действии сторон.

И дальше не общий совет «продавайте лучше», а рабочая помощь:

В этой ситуации разумно вернуть инициативу и предложить конкретное время обсуждения отправленного КП.

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

• мои коммуникации;
• понятные критерии;
• цитаты;
• объяснение оценки;
• возможность дать обратную связь;
• следующий шаг по сделке;
• сильные примеры из практики компании.

Пока это продуктовая гипотеза. Но мне все сложнее представить, что менеджер и РОП должны постоянно смотреть на систему через один и тот же экран.

Маркетингу нужен не просто «голос клиента». Ему нужно отделить плохой трафик от плохой обработки

По книжкам

Маркетинг покупает:

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

В реальности разговор часто начинается жестче:

Продажи опять говорят, что лиды плохие.

Мы приводим заявки, но не видим, что происходит после передачи.

Почему один сегмент доходит до сделки, а другой останавливается?

Какие слова клиенты сами используют, когда объясняют проблему?

Мы меняем рекламные сообщения, но не понимаем, попадаем ли в реальный спрос.

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

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

Маркетингу важен агрегированный слой коммуникационного следа:

• сегменты;
• повторяющиеся вопросы;
• формулировки клиентов;
• боли;
• возражения;
• причины остановки;
• различия между успешными и проваленными цепочками.

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

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

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

QA нужен не просто «автоматический контроль». Ему нужно поддерживать единый стандарт, которому доверяют

По книжкам

Контроль качества покупает:

• автоматизацию проверок;
• покрытие большего числа коммуникаций;
• единую оценку;
• снижение ручной работы;
• стандартизацию.

В реальной работе запрос может звучать так:

Я физически не могу проверить весь объем.

Два проверяющих ставят одному звонку разные оценки.

Мне нужно быстро находить спорные случаи, а не пересматривать все подряд.

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

AI поставил оценку, сотрудник не согласен, а доказать никто ничего не может.

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

• сформулировать проверяемый критерий;
• увидеть опорную цитату;
• сравнить оценку AI и человека;
• собрать спорные случаи;
• провести калибровку;
• увидеть, где расходятся собственник, РОП и сотрудники;
• уточнить правило;
• сохранить историю решений.

Тогда оценка перестает быть «мнением системы». Она становится частью общего рабочего стандарта, который компания обсудила, проверила и синхронизировала. Поэтому для QA логичнее отдельное пространство критериев, калибровки и расхождений, а не очередная копия отчета РОПа.

Один продукт не обязательно должен выглядеть как один кабинет

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

Для каждой роли нужны свои слова.

Потом стало понятно:

Для каждой роли нужны свои ситуации, доказательства и сценарии демо.

А теперь следующий вопрос:

Если люди принимают разные решения и ежедневно выполняют разную работу, почему они должны постоянно видеть один и тот же интерфейс?

Возможно, «Дожми Продажи» в будущем потребуется несколько ролевых рабочих пространств:

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

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

Еще предстоит проверить:

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

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

Что это меняет на сайте

Раньше естественным казался один общий маршрут:

1. объяснить проблему;
2. показать платформу;
3. перечислить, кому она полезна;
4. пригласить на демо. Теперь я думаю, что одного маршрута недостаточно. На сайте могут понадобиться отдельные входы.

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

Не страница «аналитика продаж для владельца бизнеса», а узнаваемая ситуация:

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

Дальше:

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

Для РОПа

Вход через ежедневную работу:

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

Дальше:

• команда;
• критерии;
• отклонения;
• конкретные примеры;
• калибровка;
• управленческое действие.

Для менеджера

Вход не через контроль:

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

Для маркетинга

Вход через разрыв между заявкой и продажей:

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

Для QA

Вход через единый стандарт:

Можно проверять не только больше коммуникаций, но и поддерживать одинаковое понимание критериев у AI, руководителей и сотрудников.

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

Что это меняет в презентациях и раздаточных материалах

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

Поэтому рабочая гипотеза выглядит так:

• короткая версия для собственника;
• операционная презентация для РОПа;
• отдельный лист или экран для менеджера;
• аналитический материал для маркетинга;
• методический материал по критериям и калибровке для QA.

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

Что это меняет в демо

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

Собственнику:

Команда удерживает выбранный фокус или уже требуется ваше вмешательство?

РОПу:

Где именно просел критерий, у кого и на каких коммуникациях это видно?

Менеджеру:

Почему система поставила такую оценку и что можно сделать дальше по текущей сделке?

Маркетингу:

Какие боли, возражения и сегменты повторяются в успешных и остановившихся цепочках?

QA:

Где расходятся оценки, что именно означает критерий и какие случаи требуют калибровки? Одна платформа. Один массив звонков, переписок, писем, CRM-событий и истории сделок. Но пять разных маршрутов к полезному результату.

Что я беру в работу

Для меня эта статья не про красивую сегментацию покупателей. Она про достаточно неприятное признание: мы пытались объяснять много-ролевой продукт одной общей историей.

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

Сейчас я беру в работу несколько гипотез:

1. Собрать живые формулировки каждой роли, а не ограничиваться словами «деньги», «контроль», «удобство» и «автоматизация».
2. Пересобрать страницы сайта вокруг реальных ситуаций и решений конкретных участников.
3. Подготовить разные версии презентаций и раздаточных материалов.
4. Проводить демо по ролевому сценарию, а не по меню платформы.
5. Проверить, где достаточно разных входов, а где действительно нужны отдельные рабочие пространства.
6. Сохранить общую систему данных, но не заставлять всех пользователей смотреть на нее одинаково.

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