Как ИИ квалифицирует B2B-заявку и передаёт её менеджеру
Квалификация — не автоматическая отметка «перспективный» или «неперспективный». Это упорядочивание сведений, которые помогают понять запрос и выбрать следующий шаг. Для B2B-продажи это могут быть задача компании, обстоятельства её возникновения, сроки, участники обсуждения и вопросы, на которые пока нет ответа.
ИИ может обработать текст заявки или диалога по заданным правилам: извлечь факты, отделить их от предположений, отметить пробелы и подготовить краткое резюме. Менеджеру легче начать с уточнения существенного, а не повторного сбора уже сообщённых данных. Если критерии подходящего обращения не определены, модель не выведет их надёжно из общего представления о «хорошем лиде».
Практическая автоматизация отдела продаж здесь — подготовка информации и предложение маршрута по согласованным правилам, а не передача модели права решать, кому продавать. Человек сохраняет ответственность за неоднозначные случаи и решения, последствия которых важны для клиента или компании. Сценарий ИИ-квалификации и обработки заявок связан именно с организацией такой работы.
Что показывает пример Siemens
В публикации Salesforce от 15 сентября 2026 года описан кейс Siemens: поставщик сообщает, что ИИ-квалификацией охвачено 100% рассматриваемых входящих лидов в 132 странах. В описанной схеме агент использует контекст CRM, уточняет сведения и сохраняет ответы; среди тем названы бюджет и сроки.
Это заявленный охват конкретного входящего потока, а не показатель точности, конверсии или роста выручки. Публикация поставщика не является независимым аудитом, а описанный результат нельзя автоматически переносить на другую компанию или считать доказательством готовности любого решения.
Условный пример: от текста заявки к полезной сводке
Представим, что в форме написано: «Нужна система для нескольких филиалов, хотим понять варианты до следующего квартала». Это условный пример, а не история внедрения. ИИ может выделить явно названные сведения: несколько филиалов и ориентир по сроку. Он не должен сам приписывать компании бюджет, число пользователей или утверждённое решение о покупке.
В сводке полезно разделить подтверждённое и неизвестное. Например: «Запрос касается нескольких филиалов; варианты хотят оценить до следующего квартала. Бюджет и участники выбора не указаны». Далее можно предложить менеджеру уточнить, что именно требуется сравнить, кто будет пользоваться системой и есть ли конкретная дата принятия решения. Так сотрудник видит не только краткий пересказ, но и происхождение пробелов.
Различие между фактом и выводом важно и при передаче обращения. Фраза клиента «обсуждаем обновление процесса» не подтверждает ни наличие утверждённого проекта, ни срочную потребность. Если модель всё же предлагает категорию или маршрут, интерфейс и правила должны позволять увидеть основание и исправить классификацию. Иначе аккуратно сформулированная догадка может выглядеть как достоверная запись в CRM.
Как проверить сценарий перед расширением
Для первой проверки возьмите примеры заявок, по которым сотрудники знают контекст и ожидаемый следующий шаг. Сопоставьте результат системы с разметкой специалистов, включая неполные и противоречивые обращения. Критерии согласуйте заранее: иначе после просмотра результатов легко принять удобное, но несущественное совпадение за качество.
| Что проверять | Как оценить | Роль сотрудника |
|---|---|---|
| Извлечённые сведения | Сверить каждое поле с исходным текстом; отметить пропуски и ошибки | Подтвердить важные данные и исправить неверные |
| Факты и предположения | Проверить, не превратила ли система намёк или формулировку клиента в неподтверждённый вывод | Решить, что можно сохранить как факт, а что оставить вопросом |
| Предложенный маршрут | Сравнить решение с заранее заданными правилами на обычных и неоднозначных примерах | Разобрать исключения и определить, когда требуется ручное решение |
| Подготовка к разговору | Оценить, помогают ли сводка и вопросы быстро понять следующий шаг | Уточнить контекст, который нельзя восстановить из заявки |
| Результат теста | Отдельно посчитать ошибки по полям, долю ручных проверок или время подготовки на выборке | Сопоставить показатели с исходным процессом и решить, что менять |
Какие ошибки мешают передаче менеджеру
Один показательный сбой — заполнить неизвестную дату уверенным предположением. В исходной заявке сказано «до следующего квартала», а система записывает конкретный день. В рабочем варианте срок остаётся интервалом из слов клиента, а точную дату менеджер уточняет. Это не мелкая правка формулировки: ошибочное поле может повлиять на приоритет и ожидания команды.
Проверяйте также, не превращается ли сводка в длинный машинный отчёт. Менеджеру нужны ключевой запрос, подтверждённые сведения, открытые вопросы и основание маршрута; повтор всего диалога затрудняет работу. Для каждого поля полезно определить источник, допустимое значение «неизвестно» и способ исправления. Неоднозначные ответы, особые условия и противоречия должны быть заметны, а не скрыты за итоговым баллом.
Для оценки выберите показатели, соответствующие задаче: например, долю верно извлечённых полей на проверенной выборке, частоту исправлений маршрута или время подготовки сотрудника к первому разговору. Это параметры собственного теста, а не заранее известные результаты. Сравнение следует проводить на одинаково описанных примерах и разбирать причины ошибок, а не только суммировать их.
После проверки решите, какие правила требуют уточнения, какие случаи следует передавать человеку и кто будет пересматривать критерии при изменении процесса продаж. Если меняются формы заявок, поля CRM или правила маршрутизации, прежние проверки могут перестать отражать реальную работу. Отдельно полезно изучить, как проверять передачу обращения между этапами продаж, когда задача затрагивает не только первичную квалификацию, но и дальнейшее движение заявки.