RevOps-дашборд для B2B: как связали маркетинг, продажи и CS в одну воронку выручки

RevOps-дашборд для B2B: как связали маркетинг, продажи и CS в одну воронку выручки

В 2026 у многих B2B-команд лидогенерация (MQL/SQL как KPI) перестала быть “достаточной”: маркетинг приносит поток, но ответственность за выручку распределяется между маркетингом, продажами и customer success (CS). В результате главная боль — несостыковка метрик и “разные правды” в BI: маркетинг смотрит на лидов, продажи — на возможности/сделки, CS — на ретеншн, а CFO хочет видеть выручку и маржинальность.

Бренд/компания
Крупный B2B SaaS (типовой сценарий: подписка, несколько продуктовых пакетов, жизненный цикл клиента с онбордингом и успешностью).

Задача
Построить управляемую систему аналитики, где:
— маркетинг видит, какие каналы дают сделки с нужными параметрами (а не просто “лиды”)
— продажи управляют качеством на входе (lead scoring/qualification) и прогнозом
— CS отвечает за продление и снижает отток, но при этом не “выпадает” из общего результата
— одна и та же сущность (например, компания/контракт/подписка) имеет единый идентификатор во всех системах

Решение
Сделали не очередной “витринный” дашборд, а модель данных и дэшборд в логике RevOps-воронки:

1) Единые ключи и слой соответствий
— Склеили справочники по компании: CRM Account ↔ billing customer ↔ продуктовые идентификаторы (подписки)
— Для людей (контактов) оставили связку через “основной контакт” и роли (инициатор/ЛПР/покупатель), но главная склейка шла по компании, а не по контакту
Зачем: иначе отчётность распадается, когда один клиент меняет контактное лицо.

2) Метрики на уровне событий, а не только статусов
Создали календарные метрики:
— входящие лиды → квалификация → SQL/опп (в терминах CRM) → won/lost → активация (первое успешное использование/онбординг-этап) → продление
Это перевело разговор с “количество лидов” на “какие этапы проваливаются и почему”.

3) Связка источников трафика с воронкой выручки
— настроили выбор источника на уровне компании/контракта: “первичный источник” и “источник последнего касания” (оба, но с разными задачами)
— для privacy-first атрибуции добавили слой агрегированного вклада: там, где last-click нестабилен, используем более устойчивые сигналы (например, медиаматчи на стороне сервера + контроль инкрементальности через тестовые регионы/кампании, где было возможно)
Важно: дашборд не претендует на “истину последнего клика”, он объясняет вклад с допусками.

4) Дашборд с тремя экранами для разных ролей
— Маркетинг: CAC-логика (в разрезе кампаний и этапов до опп), качество SQL (доля won, скорость прохождения), разрез по сегментам ICP
— Продажи: конверсия квалификации, доля “не дошли до next step”, прогноз по стадиям с отклонениями
— CS: активация и удержание, влияние ранних провалов (например, задержка онбординга) на продление
Сводные метрики всегда идут через одну таблицу “company journey”.

Конкретный результат
После внедрения модель данных и дашборд стали “единой системой координат”. По итогам 1–2 кварталов команда зафиксировала:
— сокращение расхождений в отчётности между маркетингом и продажами: с типичных “разных чисел” до согласованного набора конверсий по ключевым этапам (лид→опп→won)
— рост точности управленческих выводов: доля решений, которые теперь проверяются фактами по этапам (а не по ощущениям), увеличилась — команда перестала “лечить” кампании, не понимая, где ломается воронка
— ускорение времени подготовки регулярных отчётов (обычно это 1–2 дня ручной сборки → часы автоматизации за счёт витрин и единых ключей)

Урок для читателя
1) Начинайте с ключей и сущностей (company/contract), а не с красивых графиков. Если склейка “плывёт”, дашборд будет честно показывать ошибку.
2) Метрики RevOps должны быть событийными: этап → причина → следующий шаг. Статусы в CRM без контекста “зачем” редко управляемы.
3) У атрибуции в 2026 должны быть границы применимости: last-click — для части задач, инкрементальность/агрегации — для стратегических выводов.
4) Один дашборд на всех — не значит один взгляд. Дайте три экрана под роли, но одну модель данных.
…