RevOps-метрики в дашборде: как я собираю «сверху вниз» вместо набора KPI

RevOps-метрики в дашборде: как я собираю «сверху вниз» вместо набора KPI

В 2026 я всё чаще вижу одну и ту же проблему в BI: дашборд превращается в витрину метрик, которые «вроде важные», но не отвечают на главный вопрос бизнеса — что именно двигает выручку и почему. Особенно в B2B, где связка лидогенерации MQL/SQL уже не даёт того эффекта, который от неё ожидают. Маркетинг всё сильнее становится частью RevOps (общей ответственности маркетинга, продаж и customer success за выручку), а значит и измерять нужно не активность по воронке, а экономику результата.

Моё правило для RevOps-дашборда: сначала проектирую агрегатную модель, потом только под неё подбираю метрики и визуализации. Не наоборот.

1) Начинаю не с воронки, а с единицы стоимости
Для меня единица стоимости в B2B почти всегда одна из двух:
— «выручка на аккаунт/контракт» (в зависимости от модели продаж)
— «маржинальная выручка на сделку/портфель»

Дальше я задаю вопрос: какие события в данных гарантированно коррелируют с ростом этой единицы? Обычно это не «количество лидов», а:
— прогресс по qualification (качественные сигналы, а не факт контакта)
— скорость прохождения стадий, где есть деньги на горизонте (time-to-next-step)
— удержание/расширение (expansion) и повторяемость потребления (для продуктовых договоров)

2) Собираю KPI как систему уравнений, а не как список
В классическом отчёте часто есть разрозненные KPI: CAC, конверсии, pipeline coverage, MQL/SQL. В RevOps это ломается, потому что нет общей логики «маркетинг → продажа → успех → деньги».

Я делаю так:
— верхний уровень: **Net Revenue** (чистая выручка) и её маржинальная компонента
— средний уровень: contribution марктинга/CS в Net Revenue через интерпретацию влияния (не через last-click, а через согласованные окна и инкрементальность где возможно)
— нижний: объясняющие драйверы (доля аккаунтов с нужным fit, конверсия в нужный next-step, удержание, расширение)

Да, это сложнее, зато дашборд перестаёт быть «складом цифр» и становится инструментом диалога между функциями.

3) Делаю один «сквозной» разрез, который всё объединяет
В B2B чаще всего сквозную идентификацию ломают: то всё на lead-уровне, то на deal-уровне, то на подписке/контракте. Я закладываю один главный разрез — Account (аккаунт) или Contract (контракт) — и уже к нему подтягиваю:
— маркетинговые касания и их агрегаты (количество релевантных касаний, источники тем/контента)
— активность продаж (steps, встречи, stage duration)
— success-активности (onboarding milestones, usage, health score)

Ключ: один разрез — один «ключ правды». Тогда обсуждения не превращаются в спор о том, что считать конверсией.

4) Отдельно: почему я не верю одному числу «конверсия»
В privacy-first реальности и при уходе от простого last-click почти любая одиночная конверсия становится контекстно-неполной. Поэтому я в дашбордах держу «конверсию с условиями»:
— конверсия в next-step при наличии fit-сигналов
— конверсия при корректном SLA обработки (время ответа/передачи)
— конверсия по когорте входа (например, месяц старта кампании или месяц первого релевантного взаимодействия)

Это не просто красиво — это предотвращает ложные выводы. Когда у команды проседает pipeline, всегда есть риск свалить причину на маркетинг, хотя на деле провал в скорости реакции или в сегментации.

Наблюдение из практики (цифра)
На одном из внедрений мы сравнили два BI-способа описания воронки:
— «витринный» подход: лиды → MQL → SQL → deal
— RevOps-логика: аккаунты → прогресс по qualification-стадиям → контракт → расширение

В первом случае команды объясняли падение квартала тем, что «мало MQL». Во втором — выяснилось, что MQL были, но доля аккаунтов с нужным fit-сегментом уменьшилась, и ключевой эффект был не в объёме касаний, а в качестве попадания (агрегация по источникам тем и триггерам квалификации). Как результат, корректирующие действия пошли не в увеличение лидов, а в пересборку message-to-audience (соответствие послания аудитории) и в фильтры handoff. В метриках это отразилось как снижение потерь на стадии qualification и сокращение stage duration.
…