RevOps-дашборд для B2B: как связали маркетинг-воронку с выручкой и сократили цикл согласования MQL→SQL

RevOps-дашборд для B2B: как связали маркетинг-воронку с выручкой и сократили цикл согласования MQL→SQL

Компания: производственная B2B-сервисная группа (несколько продуктовых линий, продажи через аккаунт-менеджеров и пресейл)
Задача: уйти от «маркетинг смотрит на лиды, sales — на сделки» к общей ответственности за выручку. Требовалось:
— видеть, какие источники и кампании реально двигают MQL→SQL→сделки;
— ускорить согласование статусов лидов (кто и когда переводит, где застревает);
— заменить атрибуцию “последнего клика” на более честную картину влияния (privacy-first: опора на серверные события и правила инкрементальности внутри отчёта).

Решение в Power BI (как построили модель)
1) Единая витрина данных
— таблица фактов “Pipeline events”: создание лида, конверсия в MQL, перевод в SQL, создание возможности (opportunity), стадия в CRM, закрытие win/loss;
— справочники “Кампания”, “Источник/канал”, “Продуктовая линия”, “Сегмент компании”, “Владелец аккаунта”;
— маппинг UTM/кампаний к CRM-объектам на уровне идентификаторов (чтобы не терять связность при смене статусов).

2) Дашборд по RevOps-логике
Сегменты экрана:
— “Финансовая воронка”: сумма в pipeline (stage-weighted) и закрытия по времени и по комбинациям “канал × продукт”;
— “Лид-качество”: доля MQL, доля SQL, доля сделок из SQL, медианное время прохождения этапа (time-in-stage) и разрез по сегментам;
— “Узкие места процесса”: где чаще всего “зависают” лиды (MQL→SQL или SQL→сделка), с приоритетом по объёму и влиянию на выручку;
— “Кампания и вклад”: набор метрик, где маркетинг оценивает не только объём, но и вероятность продвижения лида дальше по воронке (через агрегированные конверсии).

3) Инкрементальность без магии
Чтобы не обещать то, чего нет в данных, в отчёте используют практику “серверные события + контрольные срезы”:
— показываем динамику в разрезах “проводилось/не проводилось” по периодам кампаний;
— отдельно считаем эффекты по когортам (когда лид попал в период воздействия) и сравниваем с соседними периодами без кампаний;
— в тексте рядом с графиками фиксируем предположения: это не “окончательная causal модель”, но инструмент для менеджерских решений и проверки гипотез.

Конкретный результат (что получили)
— Ускорили цикл согласования статусов: время от создания лида до решения по MQL/SQL стало меньше за счёт прозрачности “узких мест” (кластеры по этапам и владельцам) и единого SLA-виджета в одном экране.
— Повысили управляемость: команды перестали спорить “кто прав по последнему клику”, потому что видели конверсии на каждом переходе и вклад кампаний через продвижение по стадиям.
— Улучшили качество планирования: доля “нерелевантных” лидов для конкретных продуктовых линий снизилась за счёт сегментации источников и контроля воронки MQL→SQL по сегментам.

Урок для читателя
1) В RevOps дашборд строится не вокруг “количества лидов”, а вокруг “продвижения по стадиям”, потому что выручка рождается не на первом касании.
2) Обязательно фиксируйте причинно-следственные ограничения: если используете инкрементальные сравнения, проговаривайте, что это проверка гипотез на доступных данных, а не гарантия эффекта.
3) Если у вас много продуктовых линий — модель должна поддерживать разрез “канал × продукт × сегмент”, иначе маркетинг и продажи вернутся к локальным метрикам и снова начнутся разногласия.

Хотите, разберём типовую схему модели “Pipeline events” (звезда/снежинка) и список DAX-мер для: stage-weighted pipeline, conversion gates (MQL→SQL→win) и time-in-stage?

— @PowerBIforMarketing