Квалификация лида (MQL, SQL)

Происхождение и история подхода

Истоки квалификации связаны с личными продажами: прежде чем подробно представлять товар, продавец определяет, есть ли смысл обсуждать покупку с данным человеком. В традиционной семиступенчатой модели поиск и квалификация составляют первый этап. Учебник The Power of Selling описывает эту модель как многолетнюю основу обучения продавцов и отдельно рассматривает, как Интернет расширил обмен сведениями между покупателем и продавцом. ^[6]

Развитие подхода затронуло не только способы записи контактов. В историческом обзоре того же учебника разовая продажа сопоставлена с поддержанием отношений и накоплением знаний о клиентах. ^[6] Современные статусы добавляют разделение ответственности: в документации HubSpot отдельно фиксируются оценки маркетинга и продаж. ^[2] Отбор становится общей работой двух команд: одна передаёт контакт, другая проверяет возможность продолжать продажу. ^[2]

Как работает квалификация

Сначала команда определяет, для кого предназначено предложение и какие обстоятельства делают следующий разговор полезным. Затем собирает сведения, проверяет их и выбирает действие. OpenStax отличает этот отбор от первоначального поиска контактов: запись в базе может относиться к человеку, которому продукт не подходит. ^[4]

Разберём два вопроса на учебном примере. Компания обслуживает промышленное оборудование. Соответствие означает, что она работает с нужной моделью и может выполнить задачу заказчика. Готовность продолжать покупку означает, что есть повод для предметного обсуждения: например, заказчик описал неисправность и согласовал обследование. Одно не заменяет другого: подходящее оборудование ещё не говорит о потребности в ремонте сейчас.

Для записи решения можно использовать CRM — систему управления отношениями с клиентами. Например, HubSpot хранит этап работы как свойство контакта или компании; обновление бывает ручным и автоматическим. ^[2] Название поля не объясняет качество проверки: для читателя карточки важны сами сведения и критерии перехода.

MQL, SQL и модели оценки

MQL расшифровывается как Marketing Qualified Lead, то есть лид, квалифицированный маркетингом. SQL — Sales Qualified Lead, лид, квалифицированный отделом продаж. Смысл этих статусов зависит от документации и принятого процесса. ^{[1] [2]}

Таким образом, одинаковое сокращение не гарантирует одинаковых требований. В HubSpot есть и отдельный этап Opportunity: контакт или компания связаны с потенциальной сделкой. ^[2] Не следует автоматически приравнивать его к SQL.

Модель проверки отвечает на вопрос, какие сведения нужны для решения. Например, Salesforce описывает BANT: бюджет (Budget), полномочия (Authority), потребность (Need) и срок (Timeline). Тот же источник предупреждает, что такой набор может оказаться слишком простым, а потенциальный покупатель — не знать всех ответов. ^[1] Поэтому отсутствие ответа требует уточнения, а не выдуманного значения в карточке.

Как применяется на практике

Продолжим учебный пример российской сервисной компании. Инженер заполнил форму: указал организацию, оборудование и интерес к обслуживанию. По правилам примера маркетинг присваивает MQL, если услуга подходит и есть запрос на обсуждение. Это правила вымышленной компании, а не обязательное определение для рынка.

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

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

Программная операция при этом зависит от настройки. В Dynamics 365 Sales квалификация может сопровождаться созданием записей клиента, контакта и возможности сделки. Документация допускает и статус Qualified без создания возможности: тогда следующий этап бизнес-процесса не запускается. ^[3] Поэтому для отчёта нужно проверять результат операции, а не только название статуса.

Как измерить или проверить

Для учебной проверки передачи лидов возьмём долю обращений, которые продажи приняли по согласованным критериям:

Доля принятых обращений = число принятых / число переданных × 100%.

В примере за неделю передали 40 разных обращений, из них продажи приняли 30, а остальные вернули на уточнение или отклонили. Расчёт: 30 / 40 × 100% = 75%. Знаменатель включает все переданные обращения этой группы; повторная отправка той же карточки не создаёт новое обращение. Это определение учебного показателя, а не рекомендуемая норма качества.

Предположим, из тех же 30 принятых обращений через месяц восемь завершились покупкой. Доля покупок среди принятых равна 8 / 30 × 100% ≈ 26,7%, а среди всех переданных — 8 / 40 × 100% = 20%. Оба ответа верны, но описывают разные вопросы. Поэтому рядом с процентом нужны название группы, период поступления и дата проверки результата.

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

Ошибки и ограничения

Скоринг — присвоение баллов по выбранным признакам — может помогать квалификации; Salesforce рассматривает его как часть модели оценки. ^[1] Однако в учебной модели пять открытых писем не превращаются в подтверждённый бюджет. Балл отражает правила расчёта, а сведения о покупке всё ещё требуют проверки. Это особенно заметно на пограничных случаях: интерес есть, но срок или полномочия неизвестны.

Другая ошибка — сравнивать количества после изменения определения. Если вчера MQL означал запрос консультации, а сегодня включает любую подписку, рост числа MQL ещё не показывает улучшения работы. Для такого сравнения редакционная рекомендация — сохранять версию критериев и объяснять изменение состава группы.

Квалификация оставляет неопределённость. Даже в учебном примере с согласованным обследованием клиент может отложить ремонт или выбрать другого исполнителя. Статус обосновывает продолжение работы, но не подменяет её результат.

Правовой аспект

Если карточки содержат персональные данные, для российской обработки важны требования статьи 5 Федерального закона № 152-ФЗ в редакции от 26.07.2026. Части 2, 4 и 5 связывают состав сведений с заранее определёнными законными целями и запрещают избыточность; часть 7 ограничивает срок хранения целями обработки с предусмотренными законом исключениями. ^[5]

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

Частые вопросы

Связанные термины

• lid
• lidogeneratsiya
• crm-sistema
• voronka-prodazh
• konversiya
• otdel-prodazh