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

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

Компания: mid-size SaaS (B2B), цикл сделки 2–4 месяца
Задача: перестать мерить маркетинг “лидами” и показать, что происходит с конверсией дальше по воронке. Руководству нужен был один экран для RevOps (маркетинг + продажи + customer success) с прозрачной логикой от привлечения до выручки: где теряем и какие сегменты реально двигают сделки. Дополнительно — из-за privacy-first атрибуции — требовалась устойчивость отчётов при изменении источников трекинга.

Решение (Power BI): сделали “сквозной” дашборд на 4 слоя
— Источники и кампании: таблица касаний по каналам (контекстная реклама, контент/SEO, вебинары, рассылки, партнёрские упоминания). Важно: нормализовали справочник кампаний, чтобы одинаковые смыслы не жили в 10 разных названиях.
— Лид-объекты и статусы: единая модель этапов (lead → MQL → SQL → opportunity → won/lost → клиент). Все статусы брали из CRM, а даты — из единого “event log” (дата создания, дата смены статуса, дата квалификации).
— Customer success и удержание: добавили статус “активный аккаунт” и 90-дневное (rolling) прохождение в value-этап — чтобы маркетинг видел не только победы, но и качество привлечения.
— Выручка и contribution: вместо “последнего клика” строили вклад по окнам атрибуции (например, 30/60/90 дней до opportunity create). Для управленческих выводов заложили инкрементальный подход на уровне отчётной логики: сравнение сегментов по схожести (компания/отрасль/размер) и анализ uplift по cohort, а не по единственной точке конверсии.

Как именно это выглядит на экране
— Карта воронки с 3 слайсерами: сегмент (отрасль/размер), источник первого касания и “тип кампании” (информационная, demand-gen, ABM-активность).
— Детализация по влиянию на revenue: таблица “кампания → доля SQL/доля won → средний ARR (или контрактная выручка) → доля аккаунтов, дошедших до value-этапа за 90 дней”.
— Диагностика потерь: срез “где проседаем” по переходам MQL→SQL и SQL→won, плюс подсказка по вероятным причинам (скорость обработки, доля неподходящих сегментов, качество страницы/материалов, повторные касания).

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

Урок для читателя (что повторить у себя)
— Не начинайте со “счётчика лидов”. Начните с событийной модели статусов и согласованного справочника кампаний: без этого Power BI будет красиво рисовать хаос.
— RevOps-дашборд должен отвечать на один управленческий вопрос: “какие сегменты и активности двигают выручку с приемлемым качеством?”. Поэтому обязательно добавьте downstream-метрику (won/выручка + качество/удержание value-этапа), иначе маркетинг всегда будет спорить с продажами.
— В эпоху privacy-first делайте отчёт устойчивым: показывайте вклад по окнам атрибуции и cohort-сравнения, а не надеетесь на единственный last-click.

Если хотите, могу разобрать структуру такой модели в Power BI: какие таблицы нужны (fact_events, dim_campaign, dim_account, bridge_statuses), и как собрать переходы статусов в один “event log” для прозрачной воронки.

— @PowerBIforMarketing