21 августа 2026 г. · Maksim Shchegolev

MQL и SQL: передача заявки из маркетинга в продажи

MQL это утверждение маркетинга, что заявка соответствует критериям, записанным обеими командами. SQL это подтверждение продаж после контакта, что сделка реальна. Граница держится только тогда, когда записаны 3 вещи: критерии приёма в виде доказательств, причина отказа из закрытого списка и срок на первую попытку контакта.

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

MQL и SQL это не термины из словаря, а граница, которую две команды согласились соблюдать. Маркетинг передаёт карточку, продажи решают, брать ли её в работу, и кто-то должен был заранее записать, что делает такую передачу правомерной. Большинство ответов в выдаче заканчивается на расшифровке аббревиатур. Аббревиатуры никогда и не были проблемой.

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

Одним предложением

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

Что такое MQL и что такое SQL

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

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

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

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

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

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

Чем этап отличается от ярлыка

Этап это состояние в системе: у него есть доказательство входа, ровно один текущий обладатель, заданный набор разрешённых переходов и обязательное следующее действие с ответственным. Ярлык это описание, которое кто-то повесил на карточку, потому что так показалось правильным.

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

MQL и SQL обязаны вести себя как этапы. «Горячий», «тёплый», «в интересе» это ярлыки, и им место в поле балла или в метке, а не на границе. Механика переходов, разрешённых движений и задач от этапа настраивается один раз для всей воронки и описана в гайде про автоматизацию обработки заявок в CRM, где и лежит таблица переходов. Здесь решается только то, что обязано быть верно в два момента пересечения границы между командами.

Зачем вообще нужна граница и во что обходится её отсутствие

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

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

Цена конкретна, и она по большей части вообще не про качество заявок.

Задержка ответа это симптом, который виден снаружи компании. Harvard Business Review в 2011 году прошёлся по 2 241 американской компании: у тех, кто отвечал, медиана первого ответа встала около 42 часов. Исследование старое, описывает одну выборку и не является современным ориентиром. Читайте его как описание того, насколько далеко уезжает передача, когда ничто в карточке не обязывает человека действовать к конкретному сроку. Механика не изменилась: у карточки без владельца нет срока, а карточка в состоянии спора по определению без владельца.

Критерии приёмки как доказательства, а не как балл

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

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

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

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

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

Как написать соглашение о передаче заявок

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

В нём семь частей и больше ничего. Определения MQL, принятой заявки, SQL и дисквалификации вашими словами. Таблица критериев приёмки. Коды причин отказа. Обязательства по срокам с обеих сторон. Порядок разрешения споров с названным арбитром. Определение общего отчёта. История версий с датами вступления в силу.

Подпишите его в самом прямом смысле: оба руководителя письменно подтверждают согласие, ставится дата, файл лежит там, где обе команды найдут его за десять секунд. Соглашение, которое невозможно найти, это соглашение, которого нет.

Одно предупреждение по форме. Не пишите критерии так, чтобы их могла выразить только ваша текущая настройка CRM. Критерии описывают покупателей, а определения покупателей живут дольше инструментов. Если критерий невозможно проверить без конкретной функции конкретного продукта, вы написали заметку по настройке, и она тихо истечёт при следующем переезде. Границу между тем, что живёт в узле приёма, и тем, что живёт в CRM, разбирает гайд Lead Hub или CRM; узел приёма это одна точка, через которую заявка проходит до CRM.

Что происходит, когда продажи отклоняют заявку

Отказ это функция, а не исключение. Граница без пути отказа это пожелание, а отказ без записи это тихо остывающая карточка с чьим-то мнением рядом.

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

Обратите внимание, что именно разделяют эти коды. «Критерии не выполнены» и «Недоступен» говорят, что заявка была не такой, как обещали, и маркетинг должен исправление. «Не в этом периоде» и «Задача не названа» говорят, что заявка была ровно такой, как обещали, и всё равно не стала сделкой, и здесь никто никому ничего не должен. Ради этого различия коды причин и существуют. Без него любой отказ читается как обвинение, менеджеры перестают отказывать, чтобы не ссориться, и граница тихо исчезает.

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

Соглашение без записи отказов бесполезно. Если ваша CRM не может показать все отказы за прошлый квартал с кодом, автором и датой, у вас нет границы. У вас есть общее ощущение по поводу качества заявок, которое никто не может проверить.

Что означает нулевая доля отказов

Она означает, что критерии перестали работать, а не что заявки стали идеальными.

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

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

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

Когда возвращать заявку в прогрев, а когда дисквалифицировать

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

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

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

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

Взаимные обязательства по срокам, включая скорость самой приёмки

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

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

Скорость приёмки и скорость ответа покупателю это разные таймеры. Таймер приёмки измеряет, за сколько менеджер решает, соответствует ли карточка критериям. Таймер ответа измеряет, сколько покупатель ждёт живого человека. Они стартуют в один момент и отвечают на разные вопросы, а определения таймеров, порядок эскалации и отчётность по ним принадлежат гайду про скорость ответа на заявку, где SLA расшифровывается как норматив времени ответа.

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

Кто разбирает споры и с какой периодичностью

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

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

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

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

Общий отчёт, который читают обе команды

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

Один отчёт, один набор определений, один человек, который его публикует. Обе команды читают один и тот же файл, и ни одна не делает собственную версию за тот же период.

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

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

Как пересматривать соглашение, не переписывая историю

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

Относитесь к соглашению как к версионному документу с датами вступления в силу.

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

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

Где MQL и SQL стоят относительно уже настроенных систем

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

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

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

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

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

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

Как все пять модулей соединяются и какой из них строить первым, разложено в гайде про операционный стек для входящих заявок. Если поток идёт из мессенджеров, полезно заранее посмотреть, как передача выглядит в связке amoCRM и Битрикс24 и как заявки из Telegram попадают в CRM: в переписке доказательства собираются иначе, чем в форме.

Когда границу лучше оставить неформальной

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

Разделяет здесь не численность, а то, один ли человек добывает заявку и работает с ней. Как только это два человека с двумя руководителями и двумя наборами чисел, граница существует независимо от того, записал её кто-нибудь или нет. До этого момента одна страница критериев и привычка отмечать, почему заявку бросили, дадут больше, чем процесс, который вам нечем кормить по объёму.

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

Практическая последовательность внедрения

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

1. Разберите пятьдесят передач. Возьмите пятьдесят карточек, с которыми продажи недавно работали, и разложите на три стопки: стали сделками, работали и ничего не вышло, вообще не тронули. Третья стопка и объясняет вашу проблему с границей.
2. Вытащите реальные критерии. По первой стопке выпишите, что фактически было в карточке в момент передачи. Это и есть черновик критериев приёмки, и он обычно короче и конкретнее того, что любая из команд предложила бы по памяти.
3. Напишите коды с двумя менеджерами. Коды причин отказа пишутся с теми, кто будет их нажимать, а не с руководителями. Держите список короче десяти позиций.
4. Соберите соглашение на одну страницу. Определения, критерии, коды, обязательства обеих сторон, арбитр, общий отчёт, версия один с датой.
5. Сначала приборы, потом требования. Заведите события приёмки и отказа, поле кода причины, поле версии критериев и время приёмки. Убедитесь, что все четыре видны в выгрузке.
6. Четыре недели в режиме наблюдения. Все фиксируют приёмку и отказы, но ни с кого пока не спрашивают по числам. Именно здесь выясняется, что коды написаны неправильно.
7. Запустите еженедельный разбор. Десять спорных карточек, двадцать минут, решения записываются с первой же встречи.
8. Опубликуйте общий отчёт. Один файл, обе команды, одни и те же числа, с первого же месяца.
9. Пересмотрите критерии на квартале. Оформите поправку как версию два с датой вступления в силу и сравните соседние когорты.

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

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

Тревожный признак для оператора

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

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

Выход короткий. Запишите критерии как доказательства. Заведите коды причин. Опубликуйте один отчёт. Месяц проводите еженедельный разбор выборки. И только потом решайте, надо ли двигать порог в модели оценки.

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

Salesforce описывает правила назначения заявок с упорядоченными записями и ответственным по умолчанию, а HubSpot описывает автоматизацию воронки заявок, где зафиксированная попытка связи и ответ покупателя двигают карточку вперёд. В amoCRM и Битрикс24 роль такой границы обычно играют этап сделки и обязательные поля, но саму формулировку критериев ни одна система за вас не напишет. Методология NIST по управлению рисками ИИ формулирует смежную мысль, которая шире искусственного интеллекта: автоматическими решениями можно управлять, только если их можно проследить. Если ваша система умеет переводить карточку из MQL в принятую, вы должны уметь ответить, кто или что это решил, на каком основании и по какой версии критериев. Актуальное поведение продуктов сверяйте по их документации.

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

Цены