Первое обращение редко содержит всё, что нужно продавцу. Один человек подробно описывает задачу, но не называет бюджет. Другой оставляет телефон без пояснений. Третий просит услугу, которой компания не оказывает. Если оценивать их одним баллом, можно потратить время на неподходящие заявки и одновременно потерять перспективную.
Рабочая квалификация лида отвечает не на вопрос «купит ли он», а на более узкий: соответствует ли обращение предложению, каких данных не хватает и кто должен сделать следующий шаг. После статьи вы сможете составить матрицу оценки и правило передачи обращения менеджеру. Это учебная схема: критерии, пороги и формулировки нужно проверить на истории вашей компании.
Какую задачу решает квалификация
Квалификация лидов помогает разделить три разных вывода:
- Соответствие предложению. Компания оказывает нужную услугу, работает с таким типом задачи и может выполнить обязательные ограничения.
- Готовность к контакту. Человек оставил доступный способ связи, согласен продолжить разговор или указал удобный следующий шаг.
- Вероятность покупки. У обращения есть признаки возможной сделки, но квалификация не предсказывает её исход.
Эти выводы нельзя склеивать. Подходящий профиль ещё не означает готовность разговаривать. Неизвестный бюджет не доказывает отсутствие денег. Полное совпадение с критериями не гарантирует выручку: решение может измениться, проект — остановиться, а компания — выбрать другого исполнителя.
Сначала определите, какое решение должна поддерживать оценка. Обычно вариантов немного: передать менеджеру сейчас, запросить конкретное уточнение, оставить на согласованное развитие интереса или отклонить с записанной причиной. Квалификация становится полезной, когда каждому выводу соответствует действие.
Формальная оценка не нужна, если обращений мало и руководитель сам разбирает каждое; все заявки относятся к одному продукту и требуют разговора; цена ошибочного отказа выше экономии времени; данных для устойчивых правил пока нет. В такой ситуации достаточно короткого перечня обязательных полей и причины следующего действия. Матрицу стоит вводить, когда поток вырос, сотрудники по-разному понимают «хорошую заявку» или команда не может объяснить, почему обращение потерялось.
Какие стадии и типы лидов различать
Единые стадии нужны не ради терминов, а ради одинаковых действий. Запишите определение, владельца и условие перехода для каждой стадии.
| Стадия | Что уже известно | Что стадия не означает | Следующее действие |
|---|---|---|---|
| Контакт | Есть доступный способ связи или идентификатор обращения | Интерес к продукту не подтверждён | Проверить источник и контекст |
| Заинтересованный посетитель | Человек совершил выбранное командой целевое действие: задал вопрос, запросил материал или начал заявку | Он ещё не обязательно соответствует предложению | Получить минимальные сведения о задаче |
| Квалифицированный маркетингом лид | По внутренним правилам обращение похоже на целевое и проявило достаточный интерес | Продажи ещё не подтвердили возможность продолжения | Передать на проверку менеджеру |
| Квалифицированный продажами лид | Менеджер подтвердил значимую задачу, возможность продолжить разговор и следующий шаг | Покупка и выручка не гарантированы | Вести обращение по процессу продаж |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Это рабочий словарь для проектирования, а не обязательная классификация для любой компании. Названия можно заменить терминами вашей CRM. Важно, чтобы сотрудники одинаково отвечали на три вопроса: какие факты нужны для статуса, кто его присваивает и какое действие он запускает. Формулировка «качественный лид» без этих правил не помогает выбрать следующий шаг.
Не превращайте стадии в характеристику человека. «Не квалифицирован» означает только то, что обращение сейчас не прошло заданную проверку. Причиной может быть несоответствие продукту, отсутствие обязательных данных, неподходящий срок или отказ от дальнейшего контакта. Для этих случаев нужны разные статусы: иначе команда не отличит настоящий отказ от незавершённого сбора сведений.
В конкретной CRM переходы могут работать иначе. Например, официальная документация Dynamics 365 описывает квалификацию как настраиваемый процесс: в зависимости от конфигурации система переводит лид на следующую стадию и может создавать связанные записи, а при обнаружении похожего контакта предлагает проверить дубль. Это пример поведения одного продукта, а не универсальное правило для всех CRM.
Какие критерии и модели выбрать
Критерии квалификации лидов начинаются с профиля подходящего клиента — ICP, то есть принятого внутри компании описания целевого клиента. В матрице его нужно превратить в проверяемые условия: тип клиента, подходящая задача, география работы, обязательные ограничения и признаки явного несоответствия.
К профилю добавляют сведения о конкретном обращении:
- задача: что человек хочет изменить или получить;
- полномочия: какую роль собеседник играет в обсуждении и кто ещё участвует в решении;
- срок: когда требуется результат и есть ли событие, которое задаёт дату;
- бюджет: известен ли диапазон, кто его согласует и готов ли клиент обсуждать состав работ;
- следующий шаг: что согласились сделать клиент и менеджер.
Каждый критерий должен опираться на наблюдаемый ответ. «Серьёзный клиент» нельзя проверить, а «описал задачу и согласился на разговор с участником согласования» — можно.
Когда достаточно явных критериев
Явных правил достаточно, когда граница предложения понятна, поток умеренный, а решение можно объяснить несколькими условиями. Например: задача относится к услуге, доступен контакт, нет запрещающего ограничения, клиент согласен на следующий разговор. Такое правило легко проверить на спорных случаях и исправить.
Жёсткий отсев оправдан только для достоверного стоп-критерия. Если компания не работает в нужной стране или не оказывает запрошенную услугу, причина понятна. Если бюджет просто не указан, стоп-критерия нет: значение неизвестно.
Где полезны BANT и скоринг
BANT и SPIN нельзя внедрять только потому, что команда узнала знакомые названия. В предоставленных для этой статьи источниках нет первоисточников, которые позволяли бы надёжно расшифровать эти модели, описать их состав или рекомендовать конкретный способ применения. Поэтому до выбора запросите утверждённое описание используемой методики: её поля, вопросы, допустимые пропуски, условия решения и владельца процесса.
Если компания уже применяет BANT или SPIN, перенесите в автоматизацию именно её документированную версию. Сначала сопоставьте каждый вопрос с действием: влияет ли ответ на передачу менеджеру, запускает ли уточнение или только дополняет контекст. Название модели само по себе не объясняет, что считать пройденной квалификацией.
Скоринговая модель начисляет внутренние баллы за выбранные командой признаки. Она может помочь расставлять приоритеты в большом потоке, но вес каждого признака остаётся гипотезой, пока команда не сравнила результат с собственной историей. Балл нельзя выдавать за объективную вероятность покупки без такой проверки.
| Подход | Когда рассматривать | Что определить до запуска | Ограничение |
|---|---|---|---|
| Явные критерии | Граница предложения описывается несколькими условиями | Подтверждающие факты, стоп-критерии и действия | Грубое правило может не учитывать нюансы |
| BANT | В компании уже есть утверждённое описание этой модели | Поля, вопросы, пропуски, условия решения и ответственного | Без внутреннего регламента название не задаёт процесс |
| SPIN | В компании уже есть утверждённое описание этой модели | Цель вопросов, порядок применения и связь со следующим действием | Без первоисточника и регламента нельзя приписывать модели конкретный состав |
| Скоринг | Поток велик и накоплены решения продаж | Признаки, веса, порог и способ проверки | Случайные веса создают ложную точность |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Универсального победителя нет. Небольшая команда может начать с явных критериев. BANT или SPIN стоит использовать только в той версии, которую компания определила и согласовала. Скоринг имеет смысл проверять после накопления решений и обратной связи от продаж.
Какие вопросы задать и откуда брать данные
Собирайте только сведения, которые меняют маршрут обращения или помогают менеджеру подготовиться. Для каждого поля задайте практический вопрос: какое решение изменится после ответа? Если никакое, поле не должно блокировать передачу.
Минимальный набор обычно включает контакт, краткое описание задачи, существенное ограничение и желаемый следующий шаг. Срок, бюджет, роль собеседника и сведения о компании добавляют, если без них нельзя выбрать маршрут. Для каждого поля заранее определите, допустим ли ответ «неизвестно».
Вопросы о задаче и ограничениях
В форме или диалоге можно спросить:
- «Какую задачу хотите решить?»
- «Как команда выполняет эту работу сейчас?»
- «Какой результат нужно передать сотруднику?»
- «Какие системы участвуют в процессе?»
- «Есть ли дата или событие, к которому нужен результат?»
- «Кто будет проверять решение и участвовать в согласовании?»
Бот или помощник не должен задавать весь список подряд. Если человек уже написал «нужно распределять заявки из формы между менеджерами», повторно спрашивать задачу не нужно. Следующий вопрос может уточнить правило распределения или используемую CRM.
CRM может дать историю контактов, владельца записи, прошлые решения и текущий статус, если эти сведения ведутся и доступны помощнику. Разрешённые справочники можно использовать для дополнения данных, когда источник согласован для процесса. Внешняя запись не должна незаметно заменять ответ клиента: она может устареть или относиться к другой компании с похожим названием.
Каждому значению полезно хранить источник: «ответ в форме», «сообщение клиента», «поле CRM», «разрешённый справочник» или «требует подтверждения». Тогда менеджер понимает, на что можно опираться.
Что делать с неизвестным бюджетом
Неизвестный бюджет — отдельное состояние, а не ноль и не отказ. Помощник может спросить: «Бюджет уже определён, его нужно оценить после уточнения состава работ или этот вопрос решает другой участник?» Ответы ведут к разным действиям.
Если человек не готов назвать сумму, зафиксируйте это без догадки. Для предварительной квалификации может хватить задачи, соответствия предложению и согласия обсудить состав работ. Бюджет уточнит менеджер после того, как обе стороны поймут границы проекта.
Ответы, извлечённые ИИ из свободного текста, нужно показывать вместе с исходным фрагментом или другим понятным основанием. Если фраза допускает несколько толкований, поле остаётся неизвестным до подтверждения.
Как устроить процесс и передачу менеджеру
У каждого обращения должен быть один текущий статус, ответственный и срок следующего действия. Иначе даже верная оценка не защищает заявку от потери.
Рабочий маршрут выглядит так:
- Система принимает обращение и проверяет, не существует ли уже связанная запись.
- Фиксирует исходный текст, канал, время и доступный контакт.
- Собирает обязательные сведения или отмечает пропуски.
- Применяет правила квалификации и сохраняет причину решения.
- Передаёт подходящее или спорное обращение назначенному сотруднику.
- Записывает срок следующего действия и отправляет уведомление.
- Менеджер подтверждает или меняет решение и указывает причину.
Карточка передачи должна отвечать на вопросы менеджера без повторного чтения всей переписки:
- кто обратился и как связаться;
- какую задачу описал;
- какие критерии подтверждены;
- каких данных не хватает;
- почему присвоен текущий статус;
- что уже обещано клиенту;
- какой следующий шаг и к какому сроку согласован;
- где находится исходная переписка.
Причина решения важнее одного балла. Запись «передано: задача соответствует услуге, контакт подтверждён, срок обсуждается» позволяет проверить логику. Запись «82 балла» без расшифровки — нет.
После разговора менеджер возвращает обратную связь: статус подтверждён, данных недостаточно, обращение не подходит или правило сработало неверно. Без этого квалификация остаётся односторонним фильтром и не улучшается.
Учебная матрица оценки обращений
Ниже — вымышленные обращения для демонстрации подхода. Они не описывают клиентское внедрение и не задают готовые пороги для другой компании.
| Критерий | Лид А: подходящий | Лид Б: неподходящий | Лид В: пограничный |
|---|---|---|---|
| Задача | Распределять входящие заявки и передавать контекст менеджеру | Купить готовую бухгалтерскую систему | Уточнять заявки и создавать черновик карточки CRM |
| Соответствие предложению | Да | Нет: запрошенного продукта нет | Предварительно да |
| Контакт и готовность к разговору | Контакт есть, встреча согласована | Контакт есть | Контакт есть, готов обсудить процесс |
| Полномочия | Руководитель продаж | Не влияют на несоответствие услуги | Специалист собирает варианты для руководителя |
| Срок | Обсуждается после согласования требований | Не относится к предложению | Точный срок ещё не согласован |
| Бюджет | Будет определён после состава работ | Не влияет на текущее решение | Неизвестно |
| Решение | Передать менеджеру | Отклонить с точной причиной | «Данных недостаточно», ручной пересмотр |
| Следующий шаг | Разобрать процесс и примеры заявок | Сообщить о несоответствии | Уточнить участника решения, срок и порядок оценки бюджета |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Подходящий и неподходящий лид
Лид А проходит минимальные критерии: задача относится к предложению, контакт доступен, человек готов показать процесс. Отсутствие утверждённой суммы не мешает передаче, потому что состав будущих работ ещё предстоит определить. Менеджер получает задачу, подтверждённые сведения и план разговора.
Лид Б не подходит по проверяемой причине: человек просит продукт, которого нет в предложении. Не нужно снижать абстрактный балл за роль, срок и активность. Достаточно записать причину несоответствия и корректно завершить обработку.
Пограничное обращение и ручной пересмотр
У лида В понятная задача, но неизвестны срок, участник окончательного решения и бюджет. Система не должна придумывать эти значения или превращать пропуски в отрицательные ответы.
Объяснимое решение выглядит так: «Статус — данных недостаточно. Задача предварительно соответствует услуге; контакт подтверждён; бюджет и срок не указаны; собеседник собирает варианты. Требуется ручной пересмотр». Ответственный видит исходное сообщение и решает, задать ли уточняющие вопросы или сразу подключить менеджера.
Запрет должен быть явным: нельзя отклонять обращение только потому, что модель не нашла бюджет в тексте. Сначала поле получает значение «неизвестно», затем запускается уточнение или ручная проверка.
Не назначайте жёсткий проходной балл, пока не сравнили его с собственной историей. Возьмите обезличенные обращения, восстановите доступные на тот момент данные и проверьте, какие решения дала бы матрица. Отдельно разберите ошибочные отказы и обращения, которые формально выглядели сильными, но не продвинулись.
После такого разбора можно изменить критерии, а при достаточном объёме данных — проверить скоринг. До проверки матрица остаётся рабочей гипотезой, а не измерителем вероятности сделки.
Когда состав задачи понятен, можно обсудить помощника продаж Switch On AI. Для проекта сначала определяют вопросы, поля, права, правила передачи и спорные случаи; прототип ключевого сценария не считается полноценным внедрением.
Как автоматизировать квалификацию без потери обращений
Бот удобен, если диалог идёт по фиксированным шагам: запросить контакт, выбрать тип задачи, уточнить обязательное поле и показать статус. ИИ-помощник нужен, когда обращения приходят в свободной форме и системе приходится извлекать сведения, выбирать следующий вопрос или готовить краткую сводку. Обычная интеграция передаёт известные поля между формой, CRM и уведомлениями. Эти роли можно сочетать, но не следует называть их одним решением.
Сценарий автоматизации:
- Помощник сохраняет исходное обращение и ищет возможный дубль по согласованным признакам.
- Извлекает только сведения, которые присутствуют в тексте, и отмечает источник каждого поля.
- Задаёт один нужный вопрос, если пропуск мешает выбрать маршрут.
- Применяет явные правила и формирует объяснение решения.
- Передаёт подходящие и спорные случаи человеку; автоматически отклоняет только по подтверждённому стоп-критерию.
- Записывает результат в существующую карточку или создаёт новую по правилам процесса.
Права ограничивают по операциям. Помощнику можно разрешить читать утверждённые материалы и готовить черновик карточки, но запретить менять коммерческие условия, удалять записи или закрывать спорное обращение. Решение об особой скидке и нестандартных обязательствах остаётся за сотрудником.
Для защиты от дублей задают признаки совпадения и поведение при сомнении. Совпавший телефон не всегда доказывает, что это одна сделка: одна компания может обсуждать несколько задач. Поэтому система может связать повтор с найденной карточкой и показать менеджеру контекст, а не молча удалить событие.
Сбой CRM тоже не должен выглядеть как успешная передача. Обращение сохраняют для повторной обработки, а ответственному сообщают, что запись не завершена. В журнале различают получение сообщения, попытку записи, успешное сохранение и уведомление менеджера.
Как проверить качество и исправлять ошибки
Качество квалификации видно не по числу отклонённых заявок, а по ошибкам маршрута и результатам следующих стадий. Минимальный набор наблюдений:
- ошибочные отказы: какие отклонённые обращения после проверки оказались подходящими;
- полнота данных: какие обязательные поля заполнены, а какие честно отмечены как неизвестные;
- скорость передачи: сколько времени проходит от обращения до назначения ответственного;
- конверсия по стадиям: какая доля обращений переходит между заранее определёнными статусами;
- расхождение решений: как часто менеджер меняет автоматический статус и почему;
- дубли и сбои: какие повторы объединены правильно и какие записи не удалось передать.
Конверсия сама по себе не объясняет причину. Изменение может быть связано с источником обращений, предложением, сезоном или новыми правилами. Поэтому сохраняйте версию критериев и сравнивайте не только итог, но и причины решений.
Краткий чек-лист перед запуском:
- определения стадий записаны и понятны маркетингу и продажам;
- для каждого критерия указан источник данных;
- «неизвестно» отделено от «нет»;
- стоп-критерии проверяемы и имеют понятную причину;
- спорный случай уходит на ручной пересмотр;
- карточка содержит ответственного и срок следующего действия;
- повтор не создаёт лишнюю запись без проверки;
- сбой интеграции не маскируется под успех;
- менеджер может исправить решение и вернуть причину;
- правила проверены на обезличенной выборке обычных, пограничных и ошибочных случаев.
Switch On AI может помочь описать процесс, подготовить прототип ключевого сценария и проверить маршрут от сообщения до карточки менеджера. Состав подключений, права, критерии приёмки и эксплуатационные расходы согласуются для конкретной системы. Чтобы оценить применимость, пришлите обезличенный пример процесса: обычное обращение, пограничный случай и действующие правила передачи. Пароли, ключи и персональные данные для первого обсуждения не нужны.
Вопросы по этой задаче
Можно ли отклонить лид, если он не указал бюджет?
Нет, один пропуск не доказывает отсутствие бюджета или намерения купить. Поле нужно отметить как «неизвестно», запросить уточнение либо передать обращение на ручной пересмотр.
Чем квалификация отличается от прогноза продажи?
Квалификация проверяет соответствие предложения, достаточность данных и готовность к следующему действию. Даже квалифицированный лид не гарантирует сделку или выручку.
Что передавать менеджеру вместе с лидом?
Контакт, исходное обращение, краткое описание задачи, подтверждённые критерии, пропуски, причину статуса, обещания клиенту, следующий шаг и его срок.
Когда нужен ИИ-помощник, а когда достаточно бота или интеграции?
Фиксированный бот подходит для известных вопросов и полей, интеграция — для передачи данных между системами. ИИ-помощник полезен при свободной формулировке обращений и выборе уточняющего вопроса, но его выводы и права нужно ограничить.
Нужно ли сразу вводить балльный скоринг?
Нет. Сначала можно применять несколько явных критериев и собирать обратную связь продаж. Веса и проходной балл стоит вводить только после проверки на собственной истории обращений.