Детистов Бесплатный аудит
Продажи Гайд

Как настроить скоринг лидов с помощью AI и быстрее разбирать заявки

Объясняем, как превратить поток заявок в понятную очередь: AI извлекает признаки, правила задают приоритет, менеджер подтверждает важные решения.

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

В условную B2B-компанию за утро пришло 36 обращений. Часть клиентов заполнила форму на сайте. Несколько человек написали в мессенджер. Два запроса содержат технические задания, четыре похожи на сервисные обращения, у семи отсутствует название компании.

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

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

Центральный тезис гайда: полезный скоринг объясняет приоритет через факты и назначает следующий шаг. AI извлекает признаки из текста и документов, правила компании связывают их с маршрутом.

Что такое скоринг лидов простыми словами

Скоринг лидов — это способ оценить входящее обращение по заранее выбранным критериям. Результат помогает распределить время отдела продаж.

Обычно учитываются три группы признаков:

  1. Соответствие профилю. Отрасль, регион, размер компании, подходящий продукт и допустимый формат сделки.
  2. Сила задачи. Конкретность потребности, объём, срок, бюджет, участники решения и приложенные материалы.
  3. Готовность к следующему шагу. Запрос расчёта, согласие на встречу, повторное обращение или заполненное техническое задание.

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

Главное — каждый статус должен объясняться фактами из заявки.

Сначала зафиксируйте решение после оценки

Сценарий начинается с вопроса: что изменится для менеджера?

Например:

  • заявка категории A получает ответ в течение 15 минут и назначается старшему менеджеру;
  • категория B получает список уточняющих вопросов;
  • технический запрос передаётся инженеру вместе с заполненной карточкой;
  • сервисное обращение направляется в поддержку;
  • запрос вне профиля получает согласованный ответ.

Так оценка превращается в действие. У каждой категории появляются срок, ответственный и критерий завершения.

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

Критерии должны опираться на доступные данные

Компания иногда добавляет в модель признак «серьёзность клиента». Менеджеры понимают его по-разному, а система начинает угадывать.

Разложите абстрактную оценку на наблюдаемые поля:

Критерий Возможные значения Источник
Продукт подходит, требуется подбор, вне профиля текст заявки, каталог
Регион обслуживается, требует проверки, вне зоны адрес, справочник
Срок до месяца, квартал, позже, отсутствует письмо, форма, разговор
Объём диапазон или конкретное количество заявка, приложение
Роль контакта инициатор, пользователь, закупщик, неизвестно подпись, CRM, разговор
История новый, повторный, активный клиент CRM
Полнота все поля, есть пропуски, критические пропуски карточка обращения

Для каждого поля задайте правило поведения при отсутствии информации. Пустой срок может снижать уверенность и создавать вопрос менеджеру. Он не должен автоматически означать слабую потребность.

AI и правила выполняют разные операции

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

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

Пример рабочего разделения:

  • AI читает письмо и извлекает признаки;
  • справочник проверяет продукт и регион;
  • формула рассчитывает категорию;
  • система показывает причины;
  • менеджер подтверждает спорные поля;
  • CRM назначает задачу и срок.

Так ИИ для CRM становится частью процесса. Подробная схема извлечения, карточки и маршрута есть в гайде по автоматизации разбора заявок.

Пример прозрачной модели

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

Критерий Условный вес
Продукт входит в рабочую линейку 30
Регион входит в зону обслуживания 20
Указаны объём и технические параметры 20
Есть срок запуска или закупки 15
Клиент уже взаимодействовал с компанией 15

Запрос набрал 70 баллов: продукт и регион подходят, техническое задание приложено, срок отсутствует. Система присваивает категорию «приоритетное уточнение», назначает менеджера и готовит вопрос о сроке.

Рядом находится заявка на 85 баллов с явным сроком и историей прошлой покупки. Она попадает в очередь срочного ответа.

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

Уверенность системы хранится отдельно от ценности лида

Два числа часто смешиваются.

Ценность лида отражает соответствие коммерческим критериям. Уверенность показывает качество распознавания данных.

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

Маленький типовой заказ может иметь среднюю ценность и высокую уверенность. Его удобно обработать стандартным сценарием.

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

Маршрут полезнее рейтинга

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

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

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

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

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

Разворот: скоринг первым делом оценивает качество самой воронки

Компания запускает модель ради поиска лучших лидов. Через несколько недель выясняется, что значительная часть заявок получает низкую уверенность из-за формы и дисциплины CRM.

Один канал передаёт продукт и регион. Второй создаёт карточку без источника. Менеджеры по-разному заполняют отрасль. Повторные клиенты заводятся как новые. Технические задания лежат в переписке без связи со сделкой.

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

Условный отчёт по 120 заявкам может содержать такие наблюдения:

  • у 34 обращений отсутствует срок;
  • 22 карточки созданы без категории продукта;
  • 17 повторных клиентов определены как новые;
  • 13 заявок ждут ответа дольше согласованного времени;
  • в восьми случаях техническое приложение осталось только в почте.

Это пример структуры диагностики. Реальные значения появляются после разбора потока конкретной компании.

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

Обратная связь превращает модель в рабочий инструмент

Решение менеджера нужно возвращать в журнал:

  • подтверждён ли продукт;
  • изменена ли категория;
  • какой признак оказался неверным;
  • назначен ли другой маршрут;
  • состоялся ли следующий шаг;
  • стала ли заявка коммерческой возможностью.

Если сотрудник меняет оценку, он выбирает короткую причину. Например: «неверно распознан регион», «повторный клиент», «срок указан в приложении», «обращение сервисное».

Раз в неделю владелец процесса просматривает причины. Часть ошибок исправляется справочником, часть — формой, часть — уточнением инструкции для AI.

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

Пилот стоит ограничить одним потоком

Подходящий пилот длится четыре недели и охватывает один тип заявок.

Неделя 1. Карта критериев

Руководитель и два опытных менеджера разбирают 30–50 прошлых обращений. Они фиксируют признаки, решение и следующий шаг.

Разногласия обсуждаются. Если два сотрудника по-разному понимают «готовность», критерий уточняется до автоматизации.

Неделя 2. Извлечение данных

AI заполняет карточки по текстам и приложениям. Команда сравнивает результат с ручным разбором.

Отдельно проверяются пустые поля, отраслевые термины и противоречия между письмом и CRM.

Неделя 3. Теневая очередь

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

Так можно найти слабые критерии без влияния на клиентов.

Неделя 4. Ограниченный запуск

Одна очередь начинает работать по новой схеме. Сотрудники подтверждают карточки и отмечают причины изменений.

После недели компания оценивает качество и решает, какой поток подключать следующим.

Метрики пилота должны быть связаны с процессом

Для первого этапа подходят:

  1. Доля заявок с заполненными обязательными полями.
  2. Доля оценок, подтверждённых менеджером без изменения.
  3. Время от поступления до первого осмысленного действия.
  4. Доля обращений с назначенным владельцем и сроком.
  5. Количество важных заявок, поднятых после ручной проверки.
  6. Причины расхождений между системой и сотрудником.

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

Частые ошибки при запуске

Один балл без объяснения

Менеджер не доверяет оценке, руководитель не может проверить причину. Показывайте признаки, источники и правило расчёта.

Смешение разных типов обращений

Тендер, типовой заказ и сервисный вопрос требуют разных критериев. Создайте отдельные маршруты.

Штраф за отсутствие данных

Важная заявка может быть короткой. Система должна создавать задачу на уточнение и учитывать уверенность отдельно.

Обучение на старых решениях без проверки

История CRM содержит прошлые привычки команды. Выборку следует пересмотреть и согласовать с текущей стратегией.

Отсутствие владельца

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

Частые вопросы

Подходит ли скоринг малому отделу продаж?

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

Нужна ли большая история сделок?

Для правил и AI-извлечения можно начать с нескольких десятков качественно разобранных обращений. Прогнозная модель требует больше данных и отдельной проверки.

Может ли AI автоматически отклонять заявки?

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

Как связать скоринг лидов с помощью AI и CRM?

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

Что делать, если менеджеры спорят с критериями?

Возьмите несколько реальных заявок и попросите сотрудников объяснить решение через факты. Разногласия показывают, какое определение требует уточнения.

Как часто обновлять модель?

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

Следующий шаг

Соберите небольшую выборку заявок и попросите команду объяснить их приоритет через наблюдаемые признаки. Эта работа даст основу для карточки, правил и маршрутов.

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

Продолжить тему

Вернуться в блог