Ошибки в квалификации лида: как перестать “гоняться не за теми”

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

Сигналы, что квалификация лидов дает сбой

• Продажи жалуются на "много мусора", а маркетинг - на "продажи не обрабатывают".
• Конверсия из лида в встречу/демо падает, при этом трафик и заявки растут.
• Менеджеры тратят время на лидов без бюджета/полномочий/сроков, а "горячие" теряются в очереди.
• Скоринг показывает "высокий балл", но сделки не доходят до этапа коммерческого предложения.
• Воронка выглядит красиво, но выручка не коррелирует с количеством MQL/SQL.
• Дубли, пустые поля и разнобой в стадиях мешают понять, кто реально качественный.

Типичные симптомы: куда утекает бюджет и время

• "Лиды есть, продаж нет": много входящих, мало квалифицированных встреч.
• Переизбыток лидов на менеджера: скорость первого контакта проседает, растет доля "не дозвонились".
• Непредсказуемость: один канал дает "идеальных", завтра - сплошные неподходящие.
• Удержание внимания не туда: менеджеры охотнее берут простые лиды (быстро закрыть задачу), а сложные B2B-решения простаивают.
• Стадия "квалификация" превращается в формальность: лиды двигаются по воронке без подтвержденных критериев.

Мини-пример buyer persona. В SaaS для бизнеса: "Операционный менеджер" оставляет заявку на "тест", но покупать может только "Финансовый директор". Если квалификация не проверяет роль и влияние на решение, лиды будут массово "интересные", но непокупающие.

Ошибочные критерии: какие маркеры обманчивы

Симптом: лиды выглядят "теплыми" по поведению, но не конвертируются в сделку. Причина: вы оцениваете прокси-сигналы вместо подтверждения потребности/фита. Шаг: пройдитесь по чек-листу и отметьте, где вы полагаетесь на ложные маркеры.

• Считать "корпоративную почту" признаком качества без проверки размера компании и отрасли.
• Давать высокий скоринг за посещение страниц "Цена/Тарифы" без признаков намерения (запрос КП, бриф, согласование).
• Приравнивать "скачал PDF/вебинар" к готовности покупать в B2B-длинном цикле.
• Ставить приоритет по должности в форме (CEO/Owner), не проверяя, реальная ли это роль и есть ли процесс закупки.
• Использовать количество визитов как главный сигнал, игнорируя источник (например, студенты/конкуренты/партнеры).
• Считать "заполнил все поля" качеством, если поля легко фальсифицируются и не верифицируются.
• Определять SQL по факту "создали сделку" вместо подтвержденных критериев (срок, бюджет, полномочия, use case).
• Считать "город/страна" достаточным ограничением, не учитывая юридические требования, язык поддержки, валюту, сегмент.
• Доверять автоподстановкам (industry/company size) из enrichment без выборочной проверки.
• Оценивать качество по "вежливому разговору": лид приятный, но задачи и денег нет.

Мини-пример buyer persona. Для агентства: "Маркетолог" активно читает кейсы и просит прайс, но решение принимает "Коммерческий директор". Добавьте обязательную проверку: кто владелец бюджета и как выглядит процесс согласования.

Процесс оценки: где теряются полезные фильтры

Симптом: много лидов проходит в SQL, но дальше воронка "осыпается". Причина: критерии квалификации либо нефиксированы, либо не исполняются одинаково. Шаг: сначала проверьте процесс на данных (read-only), затем меняйте правила.

Симптом	Возможные причины	Как проверить	Как исправить
SQL растет, а КП/демо не растут	SQL присваивается "по ощущению"; нет обязательных полей (use case, срок, роль)	Read-only: выборка 30-50 последних SQL, доля заполненных ключевых полей, причины проигрыша	Сделать definition of done для SQL: минимальный набор подтверждений; запретить перевод без заполнения
Много "нецелевых" по словам менеджеров	Маркетинг оптимизирует кампании на лиды, а не на сделки; форма не фильтрует сегмент	Сверить топ-каналы по выручке/этапам vs по лидам; посмотреть поисковые запросы и креативы	Перенастроить цели на более "глубокие" события; добавить сегментационные вопросы в форму/лендинг
Долгая реакция на входящие	Очередь распределения не учитывает приоритет; нет SLA; нет владельца лида	Read-only: время до первого контакта по сегментам/каналам; доля лидов без владельца	Ввести SLA и автоматическое назначение; приоритизировать по ICP/намерению
Хорошие лиды "пропадают" после первого касания	Скрипт квалификации не выявляет потребность; менеджер не фиксирует next step	Прослушка 10-20 звонков/чатов; аудит полей "следующий шаг/дата/ответственный"	Шаблон квалификации + обязательный next step; короткий список вопросов под ICP
Воронка "засорена" дублями	Нет дедупликации по email/телефону/домену; лиды создаются из разных источников	Read-only: отчет по дублям, совпадениям домена/телефона, доля merged	Правила дедупликации и merge; единый идентификатор аккаунта (Account-based)
Конверсия резко меняется после изменений на сайте	Сломан трекинг, события считаются неверно; формы отправляют "пустые" лиды	Read-only: сравнить события аналитики и фактические лиды в CRM; выборочно проверить 20 отправок	Починить событие/атрибуцию; валидировать поля формы; фильтр антиспама

Быстрая пересборка "ворот" MQL → SQL

1. Зафиксируйте ICP. 1-2 сегмента, где вы реально выигрываете (отрасль/размер/география/сложность).
2. Определите MQL. Какие действия и атрибуты обязательны, а какие только повышают приоритет.
3. Определите SQL. Что должно быть подтверждено: роль, проблема, контекст внедрения, срок, следующий шаг.
4. Согласуйте "стоп-лист". Нецелевые отрасли, невозможная география, неподходящий размер компании, запрещенные use case.
5. Внедрите единый шаблон квалификации. Один экран в CRM, минимум полей, одинаковая логика для всех.

Инструменты и данные: что выдают ложные индикаторы

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

1. Read-only: сверка счетчиков. Сравните количество отправок форм/заявок в аналитике с созданными лидами в CRM за те же периоды. Ищите систематический разрыв.
2. Read-only: контроль дублей. Проверьте, как часто один и тот же контакт/домен создает несколько лидов, и что происходит с такими лидами в воронке.
3. Read-only: аудит обязательных полей. Посмотрите долю пустых/мусорных значений по "роль", "компания", "телефон", "источник".
4. Read-only: согласованность стадий. Проверьте, не используют ли разные менеджеры одни и те же стадии по-разному (по времени на стадии, по причинам закрытия).
5. Read-only: проверка UTM/источников. Найдите лидов с пустыми/странными источниками (direct/unknown) и сопоставьте их с фактическими кампаниями.
6. Низкий риск: нормализация справочников. Уберите "зоопарк" значений (отрасли/размеры/статусы), настройте единые варианты и правила заполнения.
7. Средний риск: корректировка скоринга. Уберите или уменьшите вес сигналов "любопытства" (просмотры, скачивания), добавьте вес "намерения" (запрос КП, согласование, бриф, повторный контакт).
8. Средний риск: изменение правил маршрутизации. Приоритизируйте лидов по ICP/намерению, выделите отдельную очередь на "неясных" для доуточнения.
9. Повышенный риск: изменение форм и лендингов. Добавляйте вопросы только те, что реально влияют на решение (роль в покупке, размер, use case), и тестируйте поэтапно, чтобы не "уронить" поток.

Мини-пример buyer persona. В B2B-автоматизации "специалист" заполняет форму, потому что ищет инструкцию, а "руководитель отдела" приходит по рекомендации и сразу просит звонок. В скоринге второй должен выигрывать даже при меньшем количестве просмотров.

Исправление ошибок: практические сценарии и чек-листы

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

Сценарий 1: "Лидов много, менеджеры не успевают"

• Ввести SLA на первый контакт и автоматическое назначение владельца.
• Разделить поток: ICP-в-приоритет, остальное - в "доуточнение" (SDR/маркетинг-оператор).
• Ограничить "ручные" переводы стадий: SQL только при заполненном минимуме.

Сценарий 2: "Все лиды выглядят одинаково, непонятно, кого брать первым"

• Сделать 3 уровня приоритета: A (ICP+намерение), B (ICP или намерение), C (прочее).
• Переобучить команду на единый набор квалификационных вопросов.
• Добавить в карточку лида видимые поля: сегмент, роль, use case, следующий шаг.

Сценарий 3: "Каналы спорят: маркетинг винит продажи, продажи - маркетинг"

• Утвердить один документ definitions: MQL/SQL/Close lost reasons.
• Раз в неделю разбирать 10 лидов: 5 "лучших", 5 "худших" по мнению продаж, и фиксировать изменения в правилах.
• Перевести часть оптимизации с "количества лидов" на "качество на выходе" (встречи/КП).

Когда эскалировать к специалисту/поддержке

• Есть признаки сломанной интеграции (лиды не создаются, поля не приезжают, источники "прыгают"), а чтение логов/истории синхронизации недоступно без админа.
• Нужно менять модель данных (account-based, объединение контактов/аккаунтов), а текущая структура CRM не поддерживает безопасный merge-процесс.
• Скоринг и маршрутизация завязаны на кастомный код/вебхуки, и любые правки без тестового контура рискованны для прода.
• Есть юридические/комплаенс-ограничения по данным (персональные данные, хранение, передачи) - лучше подключить DPO/юриста и администратора CRM.

Метрики и контроль: как измерять качество квалификации лидов

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

1. Скорость первого контакта по сегментам и по приоритетам (A/B/C), а не средняя "по больнице".
2. Доля лидов без владельца и доля лидов без следующего шага (next step) после первого касания.
3. Конверсия в встречу/демо отдельно для ICP и не-ICP.
4. Конверсия SQL → КП/оффер как индикатор того, что SQL присваивается не слишком рано.
5. Причины проигрыша/закрытия с нормализованным справочником (нецелевой сегмент, нет бюджета, нет полномочий, нет срока, конкуренты, другое).
6. Доля дублей и доля объединенных записей (merged) как операционная гигиена данных.
7. Стабильность по каналам: резкие "перекосы" чаще указывают на трекинг/креативы/таргетинг, чем на рынок.
8. Выборочный аудит качества: регулярная проверка карточек (заполненность ключевых полей и соответствие критериям) на небольшом сэмпле.

Частые сценарии проблем и быстрые решения

Почему лид с высоким скорингом не покупает?

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

Продажи говорят, что лиды нецелевые, но маркетинг видит хорошие цифры

Вы сравниваете разные метрики: маркетинг - MQL, продажи - встречи/КП. Зафиксируйте единые определения MQL/SQL и начните разбор 10 лидов в неделю с решениями по правилам.

Как понять, что проблема в трекинге, а не в аудитории?

Сверьте отправки форм в аналитике с созданными лидами в CRM и проверьте источники/UTM у выборки лидов. Если разрывы систематические, сначала чините данные.

Что делать, если менеджеры по-разному присваивают SQL?

Введите definition of done для SQL и запретите перевод стадии без минимального набора заполненных полей. Добавьте короткий шаблон квалификации в CRM.

Какие поля в форме реально помогают квалификации, а не снижают конверсию?

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

Как перестать терять "хорошие" лиды из-за очереди?

Разделите поток по приоритетам (ICP+намерение отдельно), задайте SLA на первый контакт и автоматическое назначение владельца. Контролируйте долю лидов без next step.