ИИ для обработки заявок: как разобрать поток обращений

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

Ниже — как выглядит такая обработка по шагам, где ИИ ошибается, какие метрики считать до и после пилота и что придётся решить по персональным данным.

Куда уходят заявки в обычном режиме

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

Пример условный. Компания получает 600 заявок в месяц по пяти каналам. На разбор одной заявки уходит 6 минут: прочитать, скопировать в CRM, ответить, назначить ответственного. Это 60 часов в месяц — полторы недели работы одного человека. Из них большая часть уходит не на разговор с клиентом, а на перенос текста между окнами.

Потери появляются в конкретных местах:

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

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

ИИ для обработки заявок: что он делает, а что остаётся человеку

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

Шаг	Что делает ИИ	Что делает человек
Приём	Забирает заявку из канала, сохраняет исходный текст и ID события	Настраивает каналы и отвечает за доступы
Классификация	Определяет тему, срочность, продукт, регион; помечает сомнительные обращения	Проверяет новые категории и правит правила
Поля	Извлекает имя, контакт, предмет обращения, сумму, срок; пустое поле оставляет пустым	Подтверждает данные в спорных заявках
Дубли	Ищет совпадения по контакту, тексту и времени	Решает, объединять ли записи и какую оставить
Ответ	Готовит черновик по шаблону и истории обращения	Отправляет всё, что содержит цену, сроки и особые условия
Маршрут	Предлагает ответственного и очередь по правилам	Меняет правило, если оно даёт неверный маршрут
Контроль	Собирает сводку: сколько пришло, что не обработано, где низкая уверенность	Разбирает выборку и отвечает за качество

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

Шесть шагов обработки входящей заявки

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

1. Один вход и ID события

У каждого обращения должен быть идентификатор, по которому его можно найти в исходном канале: номер письма, ID сообщения, запись звонка. Дальше вся цепочка ссылается на этот ID. Если интеграция упала на середине, по нему видно, создалась ли карточка, и повтор не приводит к второй заявке.

2. Нормализация

Письмо, сообщение и ответ формы приводятся к одному виду: кто обратился, откуда, что просит, какие поля заполнены. Исходный текст сохраняется целиком — к нему придётся возвращаться при спорной классификации.

3. Классификация

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

4. Поля из текста

Из письма извлекают контакт, предмет обращения, количество, срок и бюджет, если клиент его назвал. Главное правило — не заполнять пробелы догадками. Пустой телефон остаётся пустым, а заявка получает пометку «нужно уточнить». Модель, которая «восстанавливает» номер или сумму, создаёт ошибку, которую потом ищут вручную.

Поля удобно зафиксировать заранее. В проекте есть учебная карточка заявки в CSV: канал, ID события, пропуски, ответственный, статус и проверка. Её можно взять как основу для своей таблицы. Данные в файле условные, к системам он не подключается.

5. Черновик ответа и маршрут

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

6. Журнал и проверка

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

Что считать в обработке заявок

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

• Время первого ответа. Не среднее, а медиана и 90-й процентиль: хвост из заявок, которые ждали сутки, важнее среднего.
• Доля заявок без ответа за согласованный срок. Например, за два рабочих часа.
• Доля дублей. Сколько карточек создано повторно на одно обращение.
• Точность полей. Доля заявок, где контакт и ключевые поля верны без правки. Считается по выборке вручную.
• Доля переделок. Сколько черновиков ответа менеджер переписал существенно, а не поправил одно слово.
• Стоимость обработки. Часы сотрудников плюс расходы на модели и поддержку, делённые на число заявок.
• Доля заявок, доведённых до квалификации. Сколько обращений превратилось в разговор с понятной потребностью.

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

Где модель ошибается

Ошибки предсказуемы, и их проверяют на своих данных до запуска.

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

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

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

Клиенты с историей. Постоянный клиент пишет «как в прошлый раз». Без обращения к CRM модель не поймёт, о чём речь. Такой заявке нужен доступ к истории сделок, а не более умная формулировка в ответе.

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

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

Персональные данные и 152-ФЗ

Заявка почти всегда содержит персональные данные: имя, телефон, почту, иногда адрес доставки. Обработка должна опираться на законное основание — согласие или исполнение договора (152-ФЗ, ст. 6). Принцип минимизации требует брать только те поля, которые нужны для задачи: если для консультации хватает телефона, паспортные данные в форме не нужны.

Три вопроса, которые решают до запуска:

1. Где обрабатываются данные. Внешний сервис или собственный контур компании — от этого зависят договор, сроки и доступ сотрудников.
2. Кто отвечает за качество и удаление. У заявки должен быть владелец, а у данных — срок хранения.
3. Что попадает в логи. Если в журнал пишется полный текст обращения, он тоже содержит персональные данные и требует защиты.

Если разбор идёт через сторонний сервис, условия обработки закрепляют договором поручения по ч. 3 ст. 6 152-ФЗ. Отдельно проверяют согласие на рекламные рассылки: ответ на заявку и маркетинговое сообщение — разные основания. Схему покажите юристу: изменения в практике Роскомнадзора и разъяснения по обработке (сайт ведомства) сверяют на момент запуска.

Пилот на двух неделях

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

Порядок такой. Сначала выбирают канал с самым большим потоком и понятными правилами. Затем две недели собирают исходные метрики вручную, без ИИ. После этого включают разбор в режиме черновика — модель готовит поля и ответ, сотрудник проверяет и отправляет. В конце сравнивают метрики и решают, расширять ли охват.

Пример правил приёмки, цифры условные.

Критерий	Как проверяем	Порог для продолжения
Все заявки на месте	Сверка числа обращений в канале и записей в журнале	Расхождений нет
Поля без выдумок	Ручная проверка 100 заявок	Ошибочных заполнений нет
Дубли	Сверка карточек по контакту и тексту	Повторных карточек не больше согласованного числа
Черновики ответов	Доля существенных правок в выборке	Не выше согласованного уровня
Время ответа	Медиана и 90-й процентиль до и после	Заметное сокращение без роста ошибок

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

Что меняется в работе менеджера

Разбор заявок не убирает менеджера из процесса, а меняет набор действий. Вместо копирования текста он проверяет поля, читает черновик и разговаривает с клиентом. Появляется новая ответственность — следить за правилами: если новая тема заявки определилась неверно, кто-то должен поправить классификацию, а не просто исправить одну карточку.

Команде нужно объяснить, что модель не оценивает людей, а снимает рутину. Первые недели разбирайте спорные заявки вместе: так видно, где правило сформулировано нечётко. Обучение работе с такими инструментами в проекте идёт отдельным шагом — на странице обучение сотрудников работе с ИИ описано, как это устроено.

С чего начать

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

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

Источники

• Федеральный закон № 152-ФЗ «О персональных данных»: pravo.gov.ru, текст с изменениями на consultant.ru.
• Роскомнадзор, разъяснения по обработке персональных данных: pd.rkn.gov.ru.