MQL и SQL: как договориться, кого считать готовым лидом

Спор о том, кого считать готовым лидом, обычно выглядит так: маркетинг рапортует, что привёл двести лидов, а продажи отвечают, что работать не с кем. Обе стороны честны в своих отчётах. Просто под словом «лид» они держат разное — и пока это разное не записано в одном определении, спор неразрешим в принципе. MQL и SQL — не термины из учебника, которые нужно выучить правильно. Это граница ответственности внутри вашей компании, и провести её можете только вы.

Определение — это граница ответственности, а не термин

MQL (marketing qualified lead) и SQL (sales qualified lead) описывают не свойства человека, а момент передачи ответственности. MQL — это заявка, про которую маркетинг говорит: «я сделал свою работу, дальше ваше». SQL — это та же заявка, про которую продажи отвечают: «согласен, беру в работу как своего клиента». Между этими двумя точками проходит граница отделов, и весь смысл определений — сделать её видимой и проверяемой.

Отсюда следует неудобное: не существует правильного определения MQL, которое можно подсмотреть у соседа и внедрить. Определение зависит от вашего продукта, цикла сделки, среднего чека и того, кто у вас принимает решение о покупке. Чужое определение описывает чужую границу. Ваше — записывается один раз двумя отделами вместе и потом правится по данным, а не по настроению.

Определение лида — это не про то, какой лид «хороший». Это про то, где заканчивается зона маркетинга и начинается зона продаж.

Что обычно кладут в MQL, а что в SQL

В MQL кладут два условия, и оба обязательны. Первое — соответствие профилю: это компания и человек из вашего сегмента, а не студент, конкурент или частник, случайно заполнивший форму. Второе — проявленный интерес: человек сделал что-то осмысленное, а не просто попал в базу. MQL — это «похож на клиента и подал признак жизни». Ни одного из условий по отдельности не хватает: интерес без профиля — нецелевой трафик, профиль без интереса — холодный список, который маркетинг не имеет права выдавать за лид.

В SQL кладут подтверждение того, что сделка вообще реальна. Обычно это три вещи: подтверждённая потребность (есть задача, которую ваш продукт решает, а не абстрактный интерес), полномочия (вы говорите с тем, кто влияет на решение, или у вас есть путь к нему) и реалистичный срок (покупка обсуждается в обозримом будущем, а не «когда-нибудь посмотрим»). На стадии MQL мы говорили «похож на клиента». SQL поднимает планку: подтверждено, что это клиент и что сделка реально может состояться.

• Признаки MQL. Сегмент и размер компании совпадают с профилем; запрос по адресу; контакт не в стоп-листе; есть проявленное действие — заявка, демо, ответ на письмо.
• Признаки SQL. Названа конкретная задача; понятно, кто принимает решение; есть срок или триггер покупки; нет очевидных дисквалификаторов вроде явно неподъёмного для клиента бюджета.
• Что НЕ является ни тем, ни другим. Скачанный лид-магнит без ответа на письмо, визитка с конференции, подписка на рассылку. Это верх воронки — интерес, но ещё не лид, переданный в продажи.

Почему одно и то же действие значит разное

Главная ошибка при копировании чужого определения — перенос конкретных действий как критериев. Возьмите «скачал прайс». В оптовом B2B это сильный сигнал: прайс запрашивают, когда считают закупку, значит потребность близко. В рознице или в продукте с публичной ценой то же действие не значит почти ничего — прайс смотрят из любопытства, и десять скачиваний не стоят одного звонка с вопросом про сроки поставки. Одно действие, два бизнеса, противоположный вес.

Поэтому критерии MQL нельзя списать — их выводят из собственной истории. Посмотрите на клиентов, которые реально купили, и на действия, которые они совершали до сделки. Действия, которые системно предшествуют покупке именно у вас, и есть ваши сигналы. Всё остальное — интерес верхнего уровня воронки (TOFU), который приятно считать, но нельзя выдавать продажам за готовый лид.

Механика передачи: кто, когда и что при отказе

Определение без механики передачи мертво. Нужно договориться о трёх вещах: кто переводит лид со стадии на стадию, в какой срок продажи обязаны отреагировать и что происходит, когда продажи с квалификацией не согласны. Первые две — про скорость и владельца. Третья — про то, где в большинстве компаний рвётся: про отказ.

Ключевое правило: отказ продаж — это возврат лида в маркетинг, а не удаление. Когда продавец «не берёт» MQL и лид просто исчезает, вы теряете две вещи сразу: возможного клиента, до которого дошли раньше времени, и обратную связь, из которой маркетинг чинит закупку трафика. Возврат означает, что лид с меткой уходит обратно — на догрев, в следующий квартал или на пересмотр критериев.

И причина возврата обязана быть из закрытого списка, а не свободным текстом. «Не тот сегмент», «нет бюджета», «не дозвонились за N попыток», «преждевременно, вернуть через квартал» — это данные, по которым видно закономерность. «Плохой лид», написанное в поле комментария, — это эмоция, которую невозможно сосчитать. Закрытый список превращает отказы в статистику причин, а статистика причин — это и есть то, чем маркетинг правит закупку, а обе стороны правят определение.

BANT и рамки квалификации: где чек-лист помогает

Чтобы не выдумывать критерии SQL с нуля, берут готовую рамку. Самая известная — BANT: четыре вопроса, на которые продавец отвечает перед тем, как признать лид своим.

• B — Budget. Есть ли у клиента деньги на решение и понимает ли он порядок цены.
• A — Authority. Говорите ли вы с тем, кто принимает решение, или знаете путь к нему.
• N — Need. Есть ли реальная задача, которую ваш продукт закрывает.
• T — Timeline. Есть ли срок или триггер, к которому покупка привязана.

BANT — это чек-лист, а не закон, и его уместность зависит от сделки. На коротком цикле и дешёвом продукте он избыточен: пока продавец выясняет бюджет и полномочия по заявке, которую можно было закрыть за один звонок, он теряет больше, чем экономит. Здесь достаточно двух вопросов — «нужно ли» и «когда». BANT полезен там, где сделка длинная и дорогая, решение принимает несколько человек, а цена ошибки продавца в неделях потраченного времени. Тогда четыре вопроса экономят месяцы работы с сделкой, которой не было.

Альтернативы существуют — их придумали как раз для сложных сделок, где BANT кажется слишком грубым: одни рамки смещают акцент с бюджета на боль клиента, другие добавляют вопрос про то, кто внутри компании клиента продвигает покупку. Превращать статью в справочник по ним смысла нет. Принцип один: рамка — это подсказка, какие вопросы задать, а не бланк, который надо заполнить целиком, чтобы поставить галочку SQL.

Как договориться за одну встречу

Определение MQL и SQL не рождается из переписки — оно собирается за одну очную встречу маркетинга и продаж, где обе стороны в одной комнате и договорённость фиксируется сразу. Вот порядок, который на ней работает.

1. 01
   Добейтесь, чтобы разбор начали с закрытых сделок

   Пусть команда возьмёт десять клиентов, которые реально купили, и разберёт, из какого они сегмента и что делали до сделки. Определение выводится из этих людей, а не из статей про идеального лида.

2. 02
   Проверьте, что профиль MQL записан признаками, а не кнопками

   Сегмент, размер компании, тип запроса, стоп-признаки. Требуйте формулировок, по которым человек со стороны применит критерий к новой заявке и получит тот же ответ.

3. 03
   Добейтесь критерия SQL, который признают продажи

   Возьмите рамку вроде BANT и вычеркните из неё лишнее для вашего цикла. Считается здесь не длина списка. Важно одно: продавцы согласны, что лид, прошедший эти вопросы, — их клиент.

4. 04
   Требуйте согласованный срок ответа и правило возврата

   За сколько продажи реагируют на MQL и как возвращают его с причиной из закрытого списка. Без срока и возврата определение остаётся на бумаге.

5. 05
   Проверьте, что список причин отказа закрыт

   Пять-семь формулировок, которые покрывают реальные отказы. Свободный текст под запретом: причина должна складываться в статистику, а не в комментарий.

6. 06
   Назначьте дату пересмотра

   Определение — живое. Через квартал соберите тех же людей с теми же цифрами и поправьте критерии, если доля MQL, дошедших до SQL, поехала.

Как проверить, что определение работает — и что его ломает

У рабочего определения есть три признака, и все три проверяются без чужих бенчмарков. Никакой «нормальной конверсии MQL в SQL» не существует — под этим числом у разных бизнесов лежат несопоставимые воронки. Смотреть надо на свою динамику и своё поведение отделов.

Первый признак — доля MQL, дошедших до SQL, стабильна и осмысленна. Посчитайте её на своих данных по когортам (что стало с MQL января, а не что перешло в SQL в январе) и наблюдайте за динамикой. Если доля близка к нулю — маркетинг называет MQL то, что продажи в упор не признают, критерий слишком мягкий. Если доля почти стопроцентная — маркетинг перестраховывается и отдаёт в продажи только совсем горячее, а значит, много годных лидов застревает раньше. Здоровое определение держит эту долю в узнаваемом коридоре, и её колебание — сигнал разобраться, а не повод для паники.

Второй признак — продажи не жалуются на качество передаваемого. Пока в CRM копятся возвраты с причиной «не тот сегмент», определение MQL расходится с реальностью, и это видно по статистике причин, а не по громкости на планёрке. Третий признак — маркетинг не подгоняет цифру под план. Как только в конце месяца в MQL начинают записывать пограничные заявки, чтобы дотянуть до плана, определение размывается, а доля перехода в SQL падает. Расхождение этих двух чисел — MQL растёт, SQL стоит — самый надёжный индикатор того, что границу двигают руками.

В сухом остатке всё просто. Готовый лид — это то, о чём маркетинг и продажи договорились и записали так, чтобы договорённость можно было проверить. Пропишите профиль MQL признаками, критерий SQL опишите тем, что готовы признать продажи, а отказ сделайте возвратом с причиной. Дальше следите за одним числом — долей MQL, которые дошли до SQL. Держится оно в разумном коридоре — граница работает. Поехало — садитесь и разбирайтесь, где определение разошлось с реальностью. Виноватых при этом искать незачем: это техническая настройка воронки, а не суд.