MQL и SQL: как маркетингу и продажам договориться о качестве рекламных заявок

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

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

Маркетинг передал лид. Продажи получили вопрос

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

Буквы MQL и SQL не исправляют это автоматически. Если переименовать все контакты в квалифицированные лиды, качество процесса останется прежним, только отчёт станет международным. Нужны критерии, основания передачи, подтверждение приёма и понятный возврат. Тогда маркетинг знает, что готовить, продажи — что принимать, а руководитель видит конкретное место следующего действия.

Начните с одного входа. Человек оставляет запрос на расчёт услуги. До передачи нужно понять предмет, контакт и доступные исходные данные. Продажи должны получить не просто номер, а контекст запроса и причину, почему он передан именно сейчас. Если данных пока мало, это отдельное состояние с владельцем уточнения, а не повод незаметно объявить обращение плохим или уже готовым к сделке.

В ведении рекламы 404ai обращения рассматривают вместе с работой менеджера и доступными данными CRM. До оптимизации полезно согласовать, какой запрос маркетинг передаёт в продажи и как продажи подтверждают приёмку. По ссылке показан подход к запуску и контролю, а критерии для своей компании определяют отдельно.

MQL и SQL описывают разные этапы проверки

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

В HubSpot lifecycle stages разделяют Marketing Qualified Lead и Sales Qualified Lead по сторонам квалификации. Это определение стадий конкретного продукта и полезный пример общего языка. Оно не назначает обязательные критерии всем компаниям. Внедрение начинается с вопроса, какие сведения и действия позволяют вашей команде принять следующий этап.

Между передачей и признанием SQL удобно различать факт принятия в работу. Его часто обозначают SAL, sales accepted lead. Такое промежуточное разделение не обязательно требует отдельной сложной стадии CRM. Важно сохранить событие: продажи получили поручение, проверили достаточность пакета и назначили исполнителя. «Принят в работу» не означает «клиент готов купить».

Критерий должен объяснять готовность, а не нравиться в презентации

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

Не нужно требовать полной готовности к договору на самом первом этапе. В сложной продаже часть условий выясняет менеджер. Если маркетинг обязан заранее узнать всё, продажи могут получить очень чистую и почти пустую очередь. Если не обязан узнать ничего, очередь заполнится контактами без объяснения. Граница выбирается по задаче и стоимости уточнения, а не по желанию одной команды переложить работу на другую.

Критерии полезно делить на обязательные, уточняемые и исключающие. Обязательные позволяют начать следующий шаг. Уточняемые остаются вопросами менеджеру. Исключающие имеют понятную причину и подтверждение. Неизвестное значение не всегда равно несоответствию: «бюджет не назван» и «названный бюджет не позволяет предложить подходящий вариант» — разные состояния.

Пакет передачи: что получает менеджер

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

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

Отдельно фиксируют, что обещано после формы или разговора. Бесплатная памятка, обратный звонок, предварительная оценка и готовое предложение — разные результаты. Менеджер должен продолжать выбранную задачу, а не начинать собственный сценарий с нуля. Это вопрос качества передачи, независимо от того, какой рекламный кабинет привёл обращение.

Для конкретной лид-формы есть отдельный разбор пути заявок из VK. Здесь договорённость шире: одинаковый смысл передачи для разных входов. Мы не разбираем причины несовпадения рекламного обещания с разговором; сначала нужно установить, какой рабочий результат вообще считается принятым продажами.

Принятие в работу — действие с владельцем

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

Срок принятия выбирают по процессу и режиму работы, но важнее сам контракт. Кто видит новую задачу, кто подхватывает её при отсутствии основного сотрудника и что происходит при неполном пакете? Без этого маркетинг может считать лид переданным, а продажи — ожидать, что кто-нибудь другой сначала уточнит данные. На этой границе особенно хорошо размножаются ничьи обращения.

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

Возврат должен назначать работу, а не выражать недовольство

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

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

Возврат должен быть виден обеим сторонам. Если менеджер написал причину в личном чате, система не сможет объяснить изменение статуса. Если маркетинг исправил пакет, повторная передача связывается с прежним обращением, а не создаёт нового человека ради отчёта. Иначе каждое уточнение станет новой победой генерации лидов.

SQL не появляется из одного удачного поля

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

Результат квалификации должен быть проверяемой записью. Что человек хочет, что компания может предложить, какие условия выяснены и какой следующий шаг принят. Это ещё не договор и не оплата. В сложной продаже потенциальный покупатель может долго согласовывать решение. Если SQL объявляет будущую продажу завершённой, прогноз становится оптимистичным романом с неизвестной датой выхода финала.

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

Разбор одной передачи от маркетинга до принятого следующего шага

Возьмём условный запрос на внедрение системы для обработки обращений. В форме названы задача, компания и удобный контакт, но не описана текущая CRM. Маркетинг считает пакет достаточным для первичного разговора, потому что задача относится к предложению, а недостающее поле входит в работу менеджера. Это правило зафиксировано заранее, а не придумано после спорной заявки.

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

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

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

Метрики должны считать переходы, а не только заполненные карточки

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

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

Google Ads различает qualified leads и converted leads, связывая дальнейшие события с процессом компании. Это пример того, что рекламное измерение может работать глубже отправки формы. Но выбор категории в кабинете не определяет деловой смысл за вас. Сначала компания устанавливает критерий и фактическое событие, затем настраивает его наблюдение.

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

Подробности измерения есть в статье об офлайн-конверсиях и CRM. Здесь мы остаёмся на предыдущем уровне: что именно передавать и почему это событие произошло. Автоматизация отчёта полезна после договорённости, а не вместо неё.

Где могут помочь агенты

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

Общие роли разбираются в статье про ИИ-агентов отдела продаж. Для MQL/SQL важнее не число ролей, а устойчивый контракт: что одна сторона передаёт, что другая проверяет и как оформляется исключение. Иногда простое правило с хорошим интерфейсом даст больше пользы, чем сложная агентская оценка с непрозрачным баллом.

Если используется автоматический скоринг, его результат должен иметь понятное применение и проверку. Балл может приоритизировать очередь, но не обязан заменять факт принятия. Сотрудник должен иметь возможность исправить решение с причиной. Не стоит делать систему, где человеческое уточнение исчезает при следующем пересчёте, а неподтверждённая модельная уверенность возвращается снова.

Приёмка договора между командами

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

Не обязательно добавлять в интерфейс все английские сокращения. Маленькой команде могут быть удобнее понятные русские названия. Но различие смысла должно сохраниться: обращение, готово к передаче, принято в работу, квалифицировано. Хороший словарь объясняет действия; плохой лишь делает внутреннюю переписку похожей на инструкцию к аэропорту.

С чего начать на следующей планёрке

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

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