SQL(Sales Qualified Lead)

SQL (Sales Qualified Lead) — это лид (потенциальный клиент), который был квалифицирован отделом продаж как готовый к началу коммерческих переговоров. В отличие от MQL (маркетинговой квалификации), SQL означает, что менеджер лично проверил наличие у лида бюджета, полномочий, конкретной потребности и сроков (модель BANT). Это точка, где гипотеза маркетинга превращается в реальную возможность для бизнеса. В этой статье подробно разберем, что такое SQL простыми словами, чем он принципиально отличается от MQL, как применять критерии BANT на практике и приведем конкретные примеры SQL-лидов в B2B.

SQL (Sales Qualified Lead) что это простыми словами?

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

Читать подробнее о MQL >>

SQL в маркетинге и продажах: чей это лид? SQL — это однозначно «зона ответственности» отдела продаж. Маркетинг делает свою работу, передавая MQL. Менеджер по продажам, как финальный фильтр, проводит вторичную, более глубокую квалификацию через личный контакт (звонок, встречу). Если MQL — это «похоже на нашего клиента», то SQL — это «готов стать нашим клиентом». Таким образом, SQL — это последний этап перед созданием карточки Сделки (Opportunity) в CRM.

Цель SQL: зачем нужна вторичная квалификация?

Основных целей две:

  1. Повысить эффективность работы продавцов. Менеджеры не тратят время на «холодные» или нецелевые контакты, а фокусируются на реальных возможностях. Это напрямую влияет на конверсию и выручку.
  2. Обеспечить чистоту данных для прогнозирования. Только на основе проверенных SQL можно строить точный sales pipeline (воронку продаж) и давать реалистичные прогнозы продаж по выручке. Количество и качество SQL — ключевой KPI для отдела продаж на входе воронки.

SQL в воронке продаж

SQL и MQL: в чем разница?

Главное различие — в глубине проверки и ответственности. MQL оценивается по цифровым следам и формальным признакам, SQL — по результатам личного диалога. Процесс перехода MQL → SQL: диалог с менеджером. Переход не происходит автоматически. Это всегда результат первого содержательного диалога. При классификации часто используется модель BANT:

  • B (Budget) — наличие утвержденного бюджета на покупку;
  • A (Authority) — полномочия контакта принимать решения;
  • N (Need) — осознанная потребность в решении;
  • T (Timeline) — четкие сроки реализации проекта.

Стандартный скрипт звонка менеджера по продажам по модели BANT

Стандартный скрипт звонка/встречи менеджера по продажам строится вокруг уточнения критериев BANT:

  • Установление контакта и подтверждение интереса: «Здравствуйте, [Имя]. Я видел, вы интересовались нашим решением для [проблема]. Это все еще актуально?»
  • Исследование потребности (N): «С какой основной задачей или трудностью вы надеетесь справиться с помощью такого решения?»
  • Выявление процесса и полномочий (A): «Кто еще в вашей компании вовлечен в обсуждение подобных проектов? Как обычно проходит процесс принятия решения?»
  • Уточнение сроков (T): «Насколько срочно для вас решить этот вопрос? Есть ли у вас желаемые сроки запуска?»
  • Обсуждение бюджета (B): «На решение подобных задач обычно выделяются средства. Вы уже оценивали возможный бюджет для этого проекта?»
  • Если в ходе такого диалога менеджер получает положительные и конкретные ответы по ключевым пунктам BANT, лид переводится в статус SQL.
Критерий MQL (Marketing Qualified Lead) SQL (Sales Qualified Lead)
Кто квалифицирует Маркетинг (автоматически по правилам или аналитик). Менеджер по продажам (после личного контакта).
Основа для оценки Поведение в цифровой среде (действия на сайте, в email). Личный диалог, ответы на уточняющие вопросы.
Готовность к покупке Потенциальная. Интерес подтвержден, но коммерческие детали неизвестны. Высокая. Есть подтвержденные коммерческие параметры (BANT).
Ключевой вопрос для квалификации «Интересен ли этот лид нашей целевой аудитории?» «Готов ли этот лид купить наш продукт сейчас?»
Следующее действие Передача в продажи согласно SLA. Начало коммерческих переговоров, создание Сделки.

Критерии SQL и применение модели BANT

Модель BANT — классический и самый надежный инструмент для квалификации SQL в B2B. SQL — это лид, который дает четкие, подтвержденные ответы по 3-4 пунктам из модели BANT.

B (Budget) — Бюджет: Как подтвердить наличие средств?

  • Цель — не узнать точную сумму, а понять, есть ли выделенные или запланированные финансовые ресурсы.
  • Примеры вопросов: «Запланированы ли средства на этот проект в текущем квартале/году?», «В каком диапазоне бюджетов вы рассматриваете решения?», «Проходили ли аналогичные проекты по внутреннему согласованию бюджета?»
  • Что не считается SQL: «Деньги найдутся, если понравится» или «Сначала расскажите, сколько стоит».

A (Authority) — Полномочия: Как выявить ЛПР и процесс принятия решений?

  • Цель — понять, является ли контакт лицом, принимающим решение (ЛПР), или может повлиять на него, и знать процесс согласования.
  • Примеры вопросов: «Кто кроме вас будет принимать окончательное решение?», «Какой процесс закупок принят в вашей компании для таких проектов?», «Нужно ли техническое заключение от IT-отдела?»
  • Что не считается SQL: Контакт не знает, кто принимает решение, или процесс неясен даже ему.

N (Need) — Потребность: Как выявить и конкретизировать боль клиента?

  • Цель — перевести интерес в конкретную, острую бизнес-проблему, которую нужно решить.
  • Примеры вопросов: «Что произойдет, если эту проблему не решить в ближайшее время?», «Как вы сейчас справляетесь с этой задачей и какие сложности это вызывает?», «Каковы ваши ключевые требования к решению?»
  • Что не считается SQL: Расплывчатые ответы: «нам интересно», «хотим посмотреть, что есть на рынке».

T (Timeframe) — Сроки: Как определить реальные временные рамки сделки?

  • Цель — понять реальную степень срочности и привязать возможность к календарю.
  • Примеры вопросов: «К какому сроку вам важно получить результат?», «Когда вы планируете начать выбор решения / внедрение?», «Связан ли этот проект с каким-либо другим событием в компании (отчетный период, запуск филиала)?»
  • Что не считается SQL: «Когда-нибудь», «пока не знаем», «это не срочно».

Примеры SQL-лидов в B2B

Пример 1: Лид на корпоративное ПО (CRM-систему)

  • B (Бюджет): «Да, на цифровизацию отдела продаж в бюджете этого года заложено 1.5 млн рублей. Мы рассматриваем решения в этом диапазоне».
  • A (Полномочия): «Решение принимаю я, как IT-директор, совместно с коммерческим директором. Потребуется согласование с финансовым отделом».
  • N (Потребность): «Наши менеджеры теряют до 30% лидов из-за плохого учета в Excel. Нужна система, которая автоматизирует воронку и напоминания».
  • T (Сроки): «Хотим выбрать решение до конца квартала, чтобы начать внедрение в следующем».
    Вердикт: Это SQL. Все критерии BANT подтверждены конкретикой.

Пример 2: Лид на консалтинговые услуги по оптимизации процессов

  • B (Бюджет): «У нас есть бюджет на внешних консультантов в рамках общего плана по оптимизации. Общий пул — около 2 млн».
  • A (Полномочия): «Я руковожу рабочей группой по этому проекту. Итоговое решение — за генеральным директором, но мое рекомендательное письмо будет ключевым».
  • N (Потребность): «Скорость согласования договоров упала на 40%. Нужно провести аудит и внедрить регламенты, чтобы сократить цикл».
  • T (Сроки): «Проект должен быть запущен в следующем квартале. Сейчас этап сбора предложений».
    Вердикт: Это SQL. Есть конкретная проблема, процесс принятия решений и временные рамки.

Пример 3: Лид на сложное промышленное оборудование

  • B (Бюджет): «Средства выделены по инвестиционной программе. Мы сравниваем 3 вендора».
  • A (Полномочия): «Я — главный инженер, отвечаю за подготовку техзадания. Окончательный выбор — за комитетом по закупкам, но мое ТЗ — основа».
  • N (Потребность): «Нужно заменить линию А на более производительную, с точностью до Х. Вот наше ТЗ».
  • T (Сроки): «Тендер объявлен, итоги подведем через 45 дней, поставка — до конца года».
    Вердикт: Это идеальный SQL. Все формализовано: бюджет, полномочия (роль в процессе), потребность (ТЗ), жесткие сроки (тендер).

Что делать с SQL: дальнейшие шаги в воронке продаж


Статус SQL — не финал, а старт активной стадии продаж. 

1. Первый шаг после квалификации — конвертировать SQL в Сделку в CRM. В карточке сделки указывается:

  • Прогнозная сумма (на основе обсуждения бюджета).
  • Этапы продажи (например: Подготовка КП, Презентация, Согласование договора, Закрытие).
  • Планируемая дата закрытия (на основе сроков).
  • Вероятность успеха (на раннем этапе — 20-30%, после подачи КП — 50% и т.д.).

2. Назначение этапов и планирование следующих контактов
Работа со сделкой — это управление pipeline:

3. Следующий шаг: Немедленно запланировать действие — подготовить и отправить коммерческое предложение, организовать демонстрацию для комитета.

4. Контроль точек контакта: Запланировать последующие звонки для получения обратной связи по КП, ответов на вопросы.

5. Работа с возражениями: Фиксировать все возражения в карточке сделки и прорабатывать их.

SQL — это топливо для воронки продаж. Без постоянного потока качественных SQL pipeline иссякает, а прогнозы по выручке становятся нереалистичными. Грамотная квалификация по BANT — это фундамент эффективных и предсказуемых продаж в B2B.

Вам может быть интересно:

ELMA365

FAQ: Работа с SQL (Sales Qualified Lead)

Что такое SQL в маркетинге?

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

Какие существуют критерии SQL?


Основным и наиболее признанным стандартом являются критерии BANT:

  • B (Budget) — подтвержденный бюджет или финансовые возможности.
  • A (Authority) — полномочия контакта влиять на решение о покупке или статус ЛПР (лица, принимающего решение).
  • N (Need) — четкая, конкретная и актуальная бизнес-потребность (боль).
  • T (Timeframe) — определенные сроки реализации проекта или покупки.
    Лид считается SQL, если в ходе диалога с менеджером получены положительные и конкретные ответы по большинству этих пунктов (обычно 3 из 4).

Что делать, если лид соответствует не всем критериям BANT?

Такого лида нельзя считать полноценным SQL. Его следует отнести к категории «в разработке» (или аналогичному статусу). Дальнейшие действия менеджера зависят от недостающего критерия:

  • Нет бюджета или сроков: Можно оставить в «холодной» базе для периодических напоминаний (например, через email-рассылку) и повторной проверки позже.
  • Нет полномочий: Необходимо просить контакт представить вас реальному ЛПР или лицам, влияющим на решение.
  • Нет четкой потребности: Нужно продолжить работу на выявление и формулировку «боли» через дополнительные вопросы или образовательный контент.

Кто должен менять статус лида на SQL — менеджер или система?

Статус на SQL всегда должен менять менеджер вручную после проведенного квалифицирующего диалога. Автоматическое присвоение статуса SQL недопустимо, так как оно требует человеческого анализа и интерпретации ответов. Система (CRM) может лишь подсказывать и автоматизировать смежные действия: создавать задачу на звонок для MQL, предлагать шаблон скрипта или автоматически создавать сделку после того, как менеджер вручную поставил статус SQL.

Какой главный KPI отдела продаж, связанный с SQL?

Ключевой операционный KPI — конверсия SQL в сделку (или в закрытую сделку/выручку). Однако не менее важен входной KPI — количество качественных SQL в единицу времени (в неделю/месяц). Он показывает, с какой скоростью отдел продаж наполняет свою воронку проверенными возможностями. Отслеживание этого показателя помогает прогнозировать будущую выручку и регулировать нагрузку на менеджеров.