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