MQL, SQL и квалифицированный лид: как договориться об этапах
Как определить MQL и SQL через проверяемые условия, настроить передачу лида, причины отказа и расчёт переходов в B2B-воронке.
Не начинайте с расшифровки аббревиатур
MQL и SQL часто выглядят как общепринятый стандарт, хотя команды используют их по-разному. В документации HubSpot MQL связан с готовностью к передаче в продажи по оценке маркетинга, а SQL — с квалификацией со стороны продаж. Это отправная точка для разговора, но не готовые критерии конкретного бизнеса.
Спросите, какое решение меняет переход на следующий этап. Кто должен связаться с человеком, что уже известно и чего ещё не хватает? Если переход ничего не меняет в работе, дополнительная метка может только усложнить отчёт. Для небольшой команды иногда достаточно обращения, принятого в работу лида и возможности продажи, если определения остаются ясными.
Разделите соответствие профилю и проявленный интерес
Скачивание материала показывает действие, но не обязательно потребность в покупке. Соответствие компании целевому сегменту тоже не означает готовность обсуждать договор. Проверяйте эти две оси отдельно: подходит ли клиент по существенным условиям и есть ли наблюдаемая причина для следующего контакта. Не пытайтесь заменить оба вопроса одной произвольной суммой баллов.
Выберите признаки, которые команда может подтвердить без догадок. Это может быть подходящая задача, допустимая география работы, согласованный следующий шаг или обозначенный срок. Не делайте отсутствие информации отрицательным ответом автоматически: статус «неизвестно» помогает отделить необходимость уточнения от реального несоответствия. Поля должны описывать факты разговора, а не впечатление менеджера от перспективности человека.
Составьте небольшое соглашение о передаче
Для каждого этапа задайте условие входа, владельца и допустимый следующий результат. Отдельно определите отказ и возврат на уточнение. Пример ниже условный: он показывает структуру соглашения, которую нужно адаптировать под продукт, а не универсальную воронку. Для сложных продаж могут понадобиться дополнительные этапы после квалификации.
Согласуйте срок принятия и проверки лида с реальной загрузкой команды. Укажите, как заметить необработанное обращение и кто разбирает спорные случаи. Само назначение ответственного в CRM не доказывает, что контакт состоялся; полезно различать передачу, принятие и выполненное действие.
| Этап | Условный критерий | Следующий результат |
|---|---|---|
| MQL | Соответствие целевой задаче и причина для контакта | Продажи принимают или возвращают с причиной |
| SQL | Продажи подтвердили задачу и следующий шаг | Создание возможности или обоснованное закрытие |
| На уточнении | Не хватает обязательного факта | Ответственный собирает сведения |
| Не подходит | Зафиксировано существенное несоответствие | Причина доступна для анализа источника |
Проверьте правила на выборке записей
До автоматизации возьмите несколько недавних обращений из разных источников и попросите маркетинг и продажи независимо присвоить этапы. Затем сравните результаты. Расхождения покажут, какие формулировки допускают два толкования и какие сведения отсутствуют. Это полезнее спора об идеальном определении SQL без привязки к реальным разговорам.
Уточните правила для дублей, повторных запросов и возврата клиента. Определите единицу учёта: контакт, компания, обращение или возможность. Один человек может обсуждать два проекта, а одна компания — иметь нескольких участников сделки. Если единица меняется между этапами, коэффициент перехода может стать бессмысленным даже при аккуратно заполненной CRM.
Считайте переходы по сопоставимой когорте
Допустим, в условной группе было 80 MQL, а после достаточного времени на обработку 24 стали SQL. Переход составляет 30%. Но эта цифра ничего не говорит об эффективности без определения этапов, источника и периода созревания. Она не является отраслевой нормой и не должна автоматически становиться планом для другой команды.
Инструмент funnel-check помогает разобрать введённые объёмы этапов и возможные узкие места. Он не подключается к CRM и не подтверждает правильность статусов. Перед расчётом проверьте, относятся ли числа к одной группе, нет ли дублей и завершена ли обработка. Отдельно показывайте необработанные записи: их нельзя незаметно считать отказами или успешной квалификацией.
Используйте причины отказа для изменений
Выберите короткий список причин, которые ведут к разным действиям: не подходит задача, недоступна география, нет контакта, срок ещё не наступил. Не смешивайте их в одну категорию «некачественный лид». Первая причина может требовать изменения рекламы, другая — проверки формы или процесса обработки. Уточняйте код свободным комментарием, когда он действительно помогает.
Регулярно разбирайте несколько спорных и потерянных обращений вместе. Если критерии изменились, отметьте дату и версию правил в отчёте. Рост доли SQL после смягчения определения не равен улучшению маркетинга. Сопоставляйте качество этапов с последующими возможностями и продажами, чтобы система квалификации оставалась полезной для бизнеса.
Применить на практике
Частые вопросы
Обязательно ли использовать одновременно MQL и SQL?
Нет. Используйте столько этапов, сколько требуется для реальной передачи и контроля. Важнее проверяемые критерии, ответственность и понятные следующие действия.
Можно ли квалифицировать лид только по баллам?
Баллы могут помогать сортировать поток, но их правила нужно проверять на фактических результатах. Они не заменяют обязательные условия и не превращают неизвестные сведения в подтверждённые.