Бизнес / Продажи и воронка
Конверсия MQL в SQL по воронке продаж
Конверсия MQL в SQL показывает, какая доля маркетинговых лидов прошла согласованные критерии продаж и стала рабочими SQL. Метрика помогает проверить качество входящего потока и стык маркетинга с продажами, если статусы CRM и период отбора зафиксированы заранее.
Формула
Обозначения
- MQL to SQL Conversion
- доля маркетинговых лидов, принятых продажами, %
- $SQL$
- количество лидов, признанных продажами квалифицированными, лиды
- $MQL$
- количество маркетинговых квалифицированных лидов, лиды
Условия применения
- В знаменателе учитываются только MQL за выбранный период; SQL признаются по заранее согласованному статусу CRM, а не по ручной оценке после отчета.
- Канал, сегмент, продуктовая линия и команда продаж выделены заранее, чтобы маркетинговые лиды и принятые SQL описывали один поток.
- Дубли лидов, тестовые формы, повторные обращения и лиды без достаточных данных исключаются до расчета по одному правилу.
Ограничения
- Метрика не показывает качество дальнейшей продажи: высокий переход в SQL может сочетаться со слабой конверсией в договор.
- Результат чувствителен к определению MQL и SQL; изменение скоринга, формы заявки или порога квалификации ломает сравнение.
- Вывод делают вместе с SQL-to-deal, стоимостью лида, источником трафика и комментариями продаж по причинам отклонения.
Подробное объяснение
Формула «Конверсия MQL в SQL» связывает конкретный управленческий результат с базой, из которой этот результат получен. Она нужна не для красивого процента или коэффициента, а для ответа на практический вопрос: какая часть потока, капитала, времени, качества или рынка действительно дошла до нужного состояния. Величина результата имеет смысл только вместе с периодом, сегментом и единицами измерения.
Логика расчета проста: числитель отражает выбранное событие или ресурс, знаменатель задает базу сравнения, а множитель 100% используется только там, где нужен процент. Для этой формулы ключевой смысл такой: показывает, какая часть лидов, переданных маркетингом, действительно соответствует критериям отдела продаж. Если база выбрана неверно, арифметика останется правильной, но управленческий вывод станет опасным.
При изменении числителя результат движется прямо: больше целевых событий, денег, часов работы или положительных ответов повышают показатель. При росте знаменателя без такого же роста числителя показатель снижается или коэффициент показывает более слабую эффективность. Поэтому перед сравнением важно проверить, не изменилась ли сама база: например, объем заявок, состав долгов, календарный период, складская номенклатура или границы рынка.
На практике расчет применяют для контроля отклонений, планирования ресурсов и разговора между подразделениями на одном языке. Если показатель падает при росте MQL, вероятны завышенные обещания в рекламе, слабая форма квалификации или расхождение между маркетингом и продажами. Хороший управленческий вывод появляется после второго шага: число сравнивают с планом, прошлым периодом, нормативом SLA, ковенантом, мощностью или целевой экономикой продукта.
Перед подстановкой стоит проверить качество данных: нет ли дублей, отмененных операций, незавершенных циклов, ручных исправлений и смешения единиц. Если показатель выглядит слишком высоким или слишком низким, сначала проверяют определение числителя и знаменателя, а уже затем ищут причины в работе команды, процессе, рынке или финансовой модели.
Как пользоваться формулой
- Определите период, сегмент, канал или объект расчета, чтобы все входные данные относились к одной управленческой задаче.
- Соберите исходные величины: SQL, MQL; проверьте единицы измерения и источник каждой величины.
- Исключите дубли, отмененные операции, тестовые записи и незавершенные события, если они не входят в принятое правило учета.
- Подставьте значения в формулу, сохраните промежуточное вычисление и округлите только итоговый результат.
- Сравните результат с планом, прошлым периодом, нормативом или соседней метрикой и отдельно запишите возможное ограничение расчета.
Историческая справка
Метрика «Конверсия MQL в SQL по воронке продаж» выросла из практики управления продажами, планирования квот и последующего CRM-учета. В середине XX века команды фиксировали территориальные планы, звонки и личные отчеты менеджеров, но переходы между этапами часто оставались в ручных таблицах. С распространением компьютерных CRM в 1980-1990-х годах появились единые статусы лидов, задач, возможностей и сделок, поэтому воронку стало возможно измерять как процесс, а не только как итоговую выручку.
Именно переход MQL в SQL стал важен после разделения маркетинговой генерации спроса и коммерческой квалификации: компании начали фиксировать, какие лиды действительно готовы к работе отдела продаж. Современная запись не принадлежит одному автору. Она закрепилась в B2B-продажах, контакт-центрах и маркетинговой аналитике как практическое правило: событие в числителе должно относиться к той же базе, периоду и сегменту, что и знаменатель.
Историческая линия формулы
Формула «Конверсия MQL в SQL по воронке продаж» принадлежит прикладной традиции управления продажами и CRM-аналитики. Ее корректнее связывать с развитием воронок, SLA и единых статусов лидов, чем с одним автором. Смысл задают определения этапов, период, канал и правило исключения дублей.
Пример
Дано: за месяц маркетинг передал 240 MQL, продажи приняли 96 из них как SQL. Нужно найти конверсию MQL в SQL. Подстановка: 96 / 240 * 100% = 40%. Ответ: 40%. Проверка: единицы согласованы, потому что числитель и знаменатель относятся к одному периоду и одной базе наблюдений; итог выражен как %. Если использовать другой период, другой статус события или смешать деньги с количеством операций, результат нельзя сравнивать с этим примером. Управленческий вывод: число показывает не всю картину бизнеса, а конкретный срез, который нужно читать вместе с планом, динамикой и качеством исходных данных.
Частая ошибка
Частая ошибка - делить SQL на все входящие обращения, а не только на MQL. Тогда метрика смешивает генерацию спроса с приемкой лидов продажами. Еще одна ошибка - сравнивать периоды, где изменились канал, SLA, статусная модель или правило дублей: воронка начинает описывать другой процесс. Итог лучше считать по исходным числам без раннего округления и смотреть рядом с соседним этапом воронки.
Практика
Задачи с решением
Прямой расчет
Условие. Для показателя «Конверсия MQL в SQL» даны значения из примера. Выполните подстановку и найдите итог.
Решение. 96 / 240 * 100% = 40%
Ответ. 40%
Проверка базы расчета
Условие. Почему показатель «Конверсия MQL в SQL» нельзя сравнивать между двумя периодами, если в одном периоде изменили правило отбора данных?
Решение. При изменении правила отбора числитель или знаменатель начинает описывать другой набор событий, денег, часов или единиц. Тогда отличие может быть вызвано методикой, а не реальным изменением процесса.
Ответ. Сравнение корректно только при одинаковом периоде, сегменте, единицах и правиле учета.
Дополнительные источники
- Salesforce: Sales Metrics Guide
- HubSpot: Sales Pipeline and Lead Management Metrics
- OpenStax Introduction to Business: selling and customer relationships
Связанные формулы
Бизнес
Конверсия SQL в выигранную сделку
Конверсия SQL в выигранную сделку связывает принятые продажами возможности с фактическими договорами. Она показывает, насколько квалификация и работа менеджеров доводят поток до выручки, если сравнивать завершенный пул SQL одного периода.
Бизнес
Среднее время ответа менеджера
Среднее время ответа менеджера измеряет путь от обращения до первого содержательного контакта. Показатель нужен для контроля SLA и распределения нагрузки, особенно когда каналы, рабочие часы и автоматические уведомления отделены от реальных ответов.
Бизнес
Доля просроченных лидов в работе
Доля просроченных лидов в работе показывает, какая часть активной базы вышла за согласованный срок следующего действия. Метрика помогает увидеть риск потери клиентов и дисциплину CRM, если правило просрочки одинаково для всех сравниваемых периодов.
Бизнес
Скорость обработки заявок
Скорость обработки заявок оценивает, сколько обращений команда доводит до первичного решения за единицу времени. Ее используют для поиска перегрузки на входе, но считают только по заявкам с одинаковым статусом завершения обработки.