Что это означает на практике
MQL помогает маркетингу не передавать в продажи весь сырой поток. SQL добавляет проверку коммерческого контекста: есть ли реальная задача, релевантность решения, возможность продолжить диалог и следующий шаг. В разных бизнесах определения отличаются, поэтому спор «кто прав» бессмыслен без документа. Главное — чтобы переход MQL → SQL был наблюдаемым, причины rejection фиксировались, а критерии регулярно проверялись по pipeline и выигранным сделкам.
Почему здесь легко ошибиться
У вопроса «Чем MQL отличается от SQL в B2B?» есть практический смысл только тогда, когда он связан с наблюдаемым решением. Не стоит делать вывод по одному признаку. Например, сигнал «продажи говорят «лиды плохие»;» важен в связке с «маркетинг считает все формы одинаковыми;», а результат разумно проверять через MQL volume;, MQL → SQL; и SQL → opportunity;. Такой подход защищает от локальной оптимизации: показатель может улучшиться, а коммерческий результат — нет. Поэтому сначала фиксируется baseline, затем изменение процесса, и только потом сравнивается downstream-эффект.
Когда вопрос особенно важен
- продажи говорят «лиды плохие»;
- маркетинг считает все формы одинаковыми;
- нужно считать CPQL;
- CRM не показывает, где заканчивается marketing qualification;
- есть большой разрыв между лидами и opportunities;
- нужно настроить SLA.
Как действовать
- Опишите ICP и hard disqualifiers.
- Определите MQL: какие данные маркетинг может проверить до продавца.
- Определите SQL: что продажи должны подтвердить.
- Сделайте причины MQL rejection и SQL rejection явными.
- Настройте стадии и timestamps в CRM.
- Раз в месяц сравнивайте критерии с downstream pipeline/won.
Практический пример
Лид от производственной компании нужного размера с запросом на автоматизацию может стать MQL после проверки firmographic fit. После разговора выясняется, что проект планируется в следующем году и есть согласованный следующий шаг — продажи принимают его как SQL. Другой MQL может быть отклонён как нерелевантный use case.
Как принять решение
Как интерпретировать эту матрицу
- Соответствует ICP, но задача не подтверждена. MQL / nurture, в зависимости от модели. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
- Fit и реальная задача подтверждены. Кандидат в SQL. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
- Контакт активен, но компания не подходит. Не повышайте статус только за intent. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
- Менеджер «чувствует, что лид плохой». Нужна формальная причина rejection. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
Что измерять
- MQL volume;
- MQL → SQL;
- SQL → opportunity;
- rejection reasons;
- CPQL;
- pipeline per SQL;
- win rate by qualification path.
Как читать метрики
Сами по себе MQL volume; и MQL → SQL; ещё не доказывают эффект. Их нужно сравнивать с исходным уровнем, учитывать сегмент и смотреть, что происходит дальше по процессу. Если локальная метрика улучшается, а win rate by qualification path. ухудшается или не меняется, это повод проверить, не оптимизируется ли система на удобный, но слабый proxy-показатель.
Типичные ошибки
- превращать MQL/SQL в бюрократические статусы;
- делать SQL только после подтверждённого бюджета в любой модели;
- не фиксировать причины отказа;
- изменять критерии ради выполнения KPI;
- не учитывать разные сегменты.
Где есть ограничения
Некоторым бизнесам два статуса не нужны: простая воронка может работать без MQL. Термины полезны лишь там, где реально уменьшают хаос передачи лидов.
Что проверить руководителю перед изменениями
- Что именно должно измениться, если ответ на вопрос «Чем MQL отличается от SQL в B2B?» внедрён правильно?
- Какой baseline по показателю «MQL volume;» у нас есть сейчас?
- Кто владеет следующим действием и где оно фиксируется?
- Как мы отличим улучшение процесса от случайной волатильности?
- Какой сигнал заставит остановить или пересобрать гипотезу?
План проверки на ближайшие 30 дней
- Зафиксировать текущий процесс и исходные данные до изменений.
- Проверить два наиболее явных сигнала: «продажи говорят «лиды плохие»;» и «маркетинг считает все формы одинаковыми;».
- Внедрить первые 1–2 шага из плана, не меняя одновременно всю систему.
- Через согласованное окно сравнить MQL volume;, MQL → SQL; и downstream-результат.
Короткий чек-лист
- ✓ есть чёткое определение результата, который хотим улучшить;
- ✓ есть данные до изменений — baseline;
- ✓ критерии одинаково понимают участники процесса;
- ✓ есть владелец следующего действия;
- ✓ эффект проверяется не одной метрикой, а по всей воронке;
- ✓ понятно, когда гипотезу нужно остановить или пересмотреть.