MQL vs SQL vs PQL: практическая квалификация B2B лидов (2026)

MQL vs SQL vs PQL — три стадии квалификации лидов, которые большинство B2B команд используют для передачи проспектов между маркетингом, продажами и продуктом. Определения выглядят чисто в учебниках и ломаются в продакшене: у каждой команды, с которой я работал, чуть-чуть разные версии, и у большинства определения устаревшие и больше не соответствуют тому, как они реально квалифицируют. Эта статья даёт практические определения каждого, объясняет где они ломаются и предоставляет рамку для проектирования квалификации, которая реально работает для вашего motion, на основе продакшен-опыта AFF Lab и более широких категорийных паттернов. Пара со сводным руководством B2B lead generation, lead scoring для outbound и build ICP и buyer persona.

MQL vs SQL vs PQL в 2026 практические определения: MQL = marketing-touched лид с достаточным behavioral или demographic сигналом, чтобы заслуживать звонок sales-rep (типичная конверсия в SQL: 15-30%); SQL = лид, которого sales-rep принял, квалифицировал и решил активно преследовать (типичная конверсия в opportunity: 30-50%); PQL = product-touched лид в product-led growth motion с usage-сигналами достаточно сильными для sales-вовлечения (типичная конверсия в opportunity: 30-60%, часто самая высоко-конвертирующая категория). Рамка работает — пока у команды нет устаревших определений или неясных handoffs.

Что значит каждый

MQL (Marketing Qualified Lead)

Лид с достаточным сигналом от marketing-touchpoints, что sales-команда считает его заслуживающим звонка.

Типичные MQL-триггеры:

• Demo или contact-form submission
• Множественные просмотры high-value страниц (pricing, case studies)
• Скачивания whitepaper или ebook в паре с company-fit
• Посещение event с target-account match
• Регистрация на marketing-driven webinar с engagement
• Преодоление порога lead score (варьирует по команде)

Реальности MQL volume: Типичная B2B SaaS команда генерирует 100-500 MQL/мес. Качество дико варьирует. Около 15-30% конвертируются в SQL в здоровых программах; под 10% указывает, что критерии квалификации слишком расслабленные.

Типичные провалы определений MQL:

• “Кто угодно, скачавший ebook” — слишком расслабленное, генерирует SDR-усталость
• “Кто угодно в нашем ICP, кто посетил сайт” — анонимный трафик не квалифицирующий
• “Кто угодно с marketing scored выше X” — пороги score дрейфуют; ревизируйте ежеквартально

SQL (Sales Qualified Lead)

Лид, которого sales принял, квалифицировал по своим критериям и активно преследует.

Критерии акцептации SQL обычно включают:

• Лид соответствует ICP (индустрия, размер компании, роль, география)
• Лид выразил intent (задавал вопросы, запрашивал информацию, посетил demo)
• Лид указал какую-то форму бюджета, авторитета, потребности или timeline (BANT) или эквивалент
• Sales решил активно вовлечься (не просто принять и забыть)

Реальности SQL volume: 30-150 SQL/мес для mid-market SaaS команды. Около 30-50% конвертируются в opportunity в здоровых программах.

Типичные провалы определений SQL:

• “MQL, которые sales-rep принял” — слишком расслабленное; не требует активного engagement
• “Кто угодно с бюджетом” — игнорирует fit и потребность
• BANT применяется жёстко, даже когда стадия prospect не имеет смысла (early-stage prospects редко имеют полностью артикулированный BANT)

PQL (Product Qualified Lead)

Лид с сильными product-usage сигналами в product-led growth motion, заслуживающими sales-вовлечения.

Типичные PQL-триггеры:

• Free trial пользователь с high-engagement паттернами (частые входы, использование функций)
• Free-tier аккаунт, достигающий upgrade-trigger лимитов
• Multi-user активация в одной компании
• Конкретные high-intent product-поведения (настройка интеграций, приглашение teammates, завершение onboarding)
• Usage на масштабе компании, оправдывающее более высокий tier

Реальности PQL volume: Сильно варьирует по продукту. Сильные PLG продукты генерируют 50-500 PQL/мес. Конверсия в opportunity часто выше MQL или даже SQL, потому что product-usage сигналы genuine интерес и fit.

Типичные провалы определений PQL:

• Обращение с каждой free-trial регистрацией как с PQL (слишком расслабленное)
• Игнорирование company-fit на PQL (у вас отличные usage-сигналы, но компания не может платить)
• Не спроектированный handoff: кто получает PQL, когда и что делает с ним

Где определения ломаются

Учебные определения чистые. Продакшен ломает их в этих паттернах:

Дрейф определений. Определения, написанные 3 года назад, больше не соответствуют тому, что команды реально делают. Периодически аудитируйте: реальные критерии всё ещё то, что задокументировано?

Трение handoff MQL-SQL. Маркетинг думает, что каждый MQL должен преследоваться; sales думает, что половина — мусор. Реальность: критерии не совпадают между командами, или маркетинг оптимизирует lead volume, а sales — lead quality. Фикс: общие критерии и общая ответственность.

Gaming конверсии SQL. Если sales-reps измеряются по SQL-конверсии, они принимают меньше лидов. Если по opportunity-конверсии — принимают всё и позволяют конверсионной математике разобраться. Выбирайте правильную метрику для вашего motion.

Определения PQL, скопированные у PLG компаний. SaaS компании без product-led growth motion, перенимающие PQL-терминологию, потому что звучит современно. Без реальных product-usage сигналов “PQL” становится бессмысленным ребрендингом.

Путаница multi-touch атрибуции. Когда маркетинг, sales и продукт все коснулись лида, кто его claim? Без чётких правил атрибуции команды дерутся за ту же конверсию.

Паттерны recycle-back. Лиды, которые были MQL → стали SQL → дисквалифицированы → возвращаются в маркетинг для nurture → снова становятся MQL. Без чётких recycle-правил один и тот же лид входит в множественные стадии множественные разы, загрязняя метрики.

Как спроектировать квалификацию, которая реально работает

Практическая рамка для проектирования квалификации лидов в вашем motion:

Шаг 1: Сначала картируйте свой реальный GTM motion.

• Pure inbound + sales-led? Нужны MQL и SQL в основном.
• Inbound + product-led growth? Нужны MQL, SQL и PQL.
• Outbound + sales-led? Нужен SQL в основном, с опциональной “Marketing-Engaged” стадией.
• Account-based? Стадии должны мапиться на account-стадии, не индивидуальные лиды.

Шаг 2: Определите каждую стадию через поведение, не score.

• “MQL = лид со score 50+” плохо — что значит 50?
• “MQL = лид, запросивший demo, с компанией в ICP, с title в ICP” хорошо — наблюдаемое, аудитируемое.

Шаг 3: Задокументируйте ожидания конверсии.

• MQL → SQL: цельтесь в 15-30%. Меньше значит определение MQL слишком расслаблено.
• SQL → Opportunity: цельтесь в 30-50%. Меньше значит критерии акцептации SQL слишком расслаблены.
• Opportunity → Closed-Won: цельтесь в 15-30% (дико варьирует по продукту).

Шаг 4: Установите handoff SLA.

• MQL → SQL акцептация: в течение 1 business day.
• SQL → первый outreach: в течение 1 business day.
• Без SLA лиды стареют до того, как получат внимание.

Шаг 5: Установите recycle-правила.

• SQL дисквалифицирован в “не сейчас” идёт в marketing nurture на X дней, потом переоценивается.
• SQL дисквалифицирован в “wrong fit” выходит из воронки.
• Избегайте, чтобы один и тот же лид прыгал между стадиями бесконечно.

Шаг 6: Ревизируйте ежеквартально.

• Двигаются ли rates конверсии как ожидалось?
• Соответствуют ли определения тому, как команды реально квалифицируют?
• Соблюдаются ли SLA?
• Обновляйте определения, когда дрейфуют.

Анти-паттерны, которых нужно избегать

Зацикливание на vanity-метриках. Команды оптимизируют MQL volume, потому что его легко измерить. MQL volume без конверсии в SQL и downstream pipeline — vanity.

Marketing и sales оптимизируют разные метрики. Marketing измеряется по MQL volume, sales — по closed-won. Обе команды оптимизируют свои метрики; handoff деградирует.

Маршрутизация лидов без ownership. Лид входит в систему, его трогают 3 команды, никто не владеет конверсией. Установите одного ответственного владельца на стадию.

Обращение со всеми MQL одинаково. Demo-запрос от 500-человечного fit-account — не то же, что ebook-скачивание от 5-человечного стартапа. Tier MQL по силе сигнала и маршрутизируйте соответственно.

Score-based квалификация без observability. “Score выше 80 = MQL” без понимания того, что score реально измеряет, создаёт непрозрачную квалификацию, которую нельзя аудитировать.

Нет feedback loop. Sales говорит marketing “MQL плохие” без специфики; marketing не имеет способа улучшиться. Стройте структурированный feedback loop, где sales тэгает качество MQL и marketing итерирует на критериях.

Позволять PQL сидеть проигнорированными. Product-led growth компании часто имеют отличные PQL-сигналы, но не имеют sales-motion действовать на них. PQL-система без sales follow-up не захватывает ценность.

Bottom line: MQL, SQL и PQL — полезные рамки в 2026, когда определения соответствуют вашему реальному GTM motion, handoffs имеют SLA, и конверсионная математика честно измеряется. Они ломаются, когда определения дрейфуют, команды оптимизируют разные метрики, или квалификация становится score-театром, а не behavior-based. Используйте рамку выше, чтобы спроектировать квалификацию, которая выживает в продакшен-реальности, не учебные определения, выглядящие чисто, но производящие шум.