Как устроена квалификация входящих заявок и что здесь делает ИИ-агент
Обычно заявка проходит несколько простых, но обязательных шагов. Менеджер читает сообщение, уточняет задачу, проверяет контакты, выясняет бюджет или масштаб проекта, определяет срочность и решает, что делать дальше. Одного клиента нужно сразу передать специалисту, другому — отправить уточняющие вопросы, третьему — объяснить, что компания не занимается его задачей.
Пока обращений немного, эта работа почти незаметна. С ростом потока она начинает занимать существенную часть дня. Заявки приходят из формы на сайте, почты, мессенджеров и социальных сетей. В одном обращении есть подробное описание, в другом — только фраза «Сколько стоит?». Менеджеру приходится собирать разрозненные сведения, переносить их в CRM, назначать статус и следить, чтобы перспективный контакт не потерялся среди случайных запросов.
В этом контексте ИИ-агент для бизнеса — это программная система, которая получает обращение, анализирует его по заданным правилам, запрашивает недостающие сведения и выполняет разрешённые действия в подключённых сервисах. Например, создаёт карточку в CRM, заполняет поля, ставит задачу менеджеру или направляет заявку в нужное подразделение.
Квалификация здесь означает не продажу и не окончательное решение за сотрудника. Её задача — привести входящее обращение к понятному виду: кто обратился, с какой задачей, насколько запрос соответствует профилю компании и какой следующий шаг требуется. Более подробное объяснение самого подхода есть в статье Что такое ИИ-агент для бизнеса.
Чем ИИ-агент отличается от ручной работы, чат-бота и обычной автоматизации
При полностью ручной квалификации качество зависит от загрузки и внимательности конкретного сотрудника. Опытный менеджер быстро замечает важные детали, но даже ему приходится перечитывать сообщения, задавать похожие вопросы и переносить одни и те же данные между системами. Преимущество такого подхода — гибкость. Недостаток — высокая доля повторяющихся действий.
Обычная автоматизация хорошо работает там, где заранее известны условия. Если клиент выбрал в форме определённую услугу, система назначает ответственного менеджера. Если поле телефона пустое, форма не отправляется. Такие сценарии надёжны, но плохо справляются со свободным текстом. Формулировки «нужен личный кабинет для дилеров» и «хотим дать партнёрам доступ к заказам» могут описывать близкую задачу, хотя формально не совпадают.
Чат-бот ведёт диалог по подготовленному сценарию или отвечает на вопросы. Его основная роль — общение. Он может собрать имя, телефон и несколько ответов, но сам по себе не обязан учитывать весь контекст заявки и продолжать работу в других системах.
ИИ-агент объединяет понимание свободного текста с последовательностью действий. Он может извлечь из сообщения факты, сопоставить их с критериями компании, заметить пробелы и выбрать предусмотренный маршрут. Если клиент уже указал регион и желаемый срок, повторно спрашивать их не нужно. Если сведений недостаточно, агент задаёт только необходимые вопросы.
Практический смысл не в том, что один подход всегда лучше остальных. Чёткие проверки удобнее оставить обычным правилам, разговор — диалоговому интерфейсу, а обработку неоднородных обращений и передачу контекста между этапами можно поручить агенту.
Какие задачи можно передать агенту, а где решение должен принимать человек
Для передачи ИИ лучше подходят операции, у которых есть понятный вход и проверяемый результат. Агент может определить тему обращения, выделить контактные данные, кратко изложить задачу, найти упоминание бюджета и срока, проверить заполненность обязательных полей. Ему также можно поручить подготовку уточняющих вопросов, присвоение предварительной категории и выбор очереди, в которую попадёт заявка.
Полезен и первичный отсев очевидных обращений не по адресу: предложений о сотрудничестве, резюме, спама или запросов на услугу, которой компания не занимается. Однако безопаснее не удалять такие сообщения автоматически, а складывать их в отдельную очередь для выборочной проверки. Ошибка классификации не должна приводить к безвозвратной потере контакта.
Решение за человеком стоит сохранять там, где цена ошибки высока или правила допускают несколько трактовок. Это относится к отказу важному клиенту, оценке сложного проекта, обещанию срока, согласованию нестандартной цены и выбору условий договора. Не стоит поручать агенту и окончательную оценку человека по расплывчатым признакам вроде «серьёзности» или «перспективности», если компания сама не может объяснить эти критерии.
Практичная граница проходит между рекомендацией и обязательством. Система может написать: «В заявке указан подходящий тип проекта, но нет данных о сроке» — и предложить следующий шаг. Подтвердить коммерческое решение должен сотрудник.
Контроль особенно важен в начале. Менеджеру нужно видеть исходное сообщение, вывод агента и причину присвоенной категории. Тогда ошибку можно обнаружить и поправить, а правило — уточнить. Полная автономность здесь не является целью сама по себе. Ценность появляется тогда, когда рутинная часть сокращается, а ответственные решения остаются прозрачными.
Какие данные, правила и интеграции нужны системе
Основа такой системы — не языковая модель, а договорённость внутри компании о том, что считается качественной заявкой. Нужен короткий перечень обязательных сведений: например, тип задачи, контакт, регион, предполагаемый срок и особенности проекта. Состав полей зависит от бизнеса. Бюджет важен не всегда, а попытка узнать его слишком рано иногда только мешает разговору.
Второй элемент — правила маршрутизации. Они описывают, куда направлять разные обращения и когда нужно подключить сотрудника. Правила лучше формулировать на реальных примерах: какие заявки относятся к целевым, какие требуют уточнения, какие подразделения отвечают за конкретные темы. Отдельно фиксируются действия, которые агенту запрещены.
Далее нужны источники знаний. Это может быть описание услуг, география работы, требования к заказу, актуальные ответы на частые вопросы и внутренние инструкции для менеджеров. Материалы должны быть непротиворечивыми. Если на сайте, в CRM и в памятке сотрудника указаны разные условия, агент не сможет самостоятельно определить, какой вариант верный.
Интеграции связывают обработку текста с рабочим процессом. Обычно это каналы поступления заявок, CRM и средство уведомления сотрудников. Интеграция — просто техническое соединение сервисов, через которое система получает обращение и возвращает результат. На старте необязательно подключать всё. Иногда достаточно одного источника заявок и создания черновика карточки, который проверяет менеджер.
Наконец, нужен журнал действий: исходный текст, извлечённые данные, заданные вопросы, выбранная категория и внесённые сотрудником исправления. Без такой истории трудно понять, где система действительно помогает, а где лишь создаёт дополнительную проверку.
Как выбрать процесс для пилота и проверить результат
Для первого пилота лучше взять один однородный поток заявок. Подойдёт, например, конкретная форма на сайте или обращения по одной услуге. Если сразу смешать продажи, поддержку, партнёрские предложения и обращения соискателей, оценка получится размытой: у этих потоков разные цели и правила.
Хороший кандидат для проверки имеет заметную долю повторяющихся действий, достаточное количество понятных примеров и сотрудника, который отвечает за текущий процесс. Важно заранее определить, какую проблему должен решить пилот. Это может быть долгое первичное чтение, незаполненные карточки, неверная маршрутизация или потеря контекста при передаче заявки.
Результат стоит оценивать не по впечатлению от красивых ответов, а по нескольким наблюдаемым показателям. Можно сравнить полноту заполнения карточек, долю верно назначенных категорий, количество исправлений менеджера, время до первого осмысленного ответа и число заявок, которые пришлось разбирать заново. При этом нужна ручная проверка выборки: автоматический отчёт не покажет, насколько корректно система поняла нестандартное обращение.
Пилот разумно начать в режиме подсказок. Агент обрабатывает реальные или заранее обезличенные обращения, но его вывод сначала подтверждает сотрудник. Исправления записываются и разбираются по типам. После этого можно открыть автоматическое выполнение только для тех действий, где ошибки редки, заметны и легко обратимы. Выбору узкого сценария также посвящён материал Как выбрать процесс для первого AI-пилота.
Чтобы проверить применимость идеи к своему процессу, достаточно взять несколько десятков недавних заявок и вручную отметить повторяющиеся операции, недостающие сведения и точки принятия решений. Если большую часть подготовительной работы можно описать ясными правилами, а спорные случаи передать человеку, такой процесс подходит для небольшого контролируемого пилота.