AI для обработки заявок: как автоматизировать входящие письма, формы и PDF

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

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

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

Базовый процесс можно представить так:

Письмо, форма или PDF

→ получение события из канала

→ сохранение исходного сообщения и вложений

→ определение типа обращения

→ извлечение текста и таблиц

→ приведение данных к единой структуре

→ проверка обязательных полей

→ сопоставление со справочниками

→ применение бизнес-правил

→ AI-анализ неоднозначного текста

→ создание черновика в CRM

→ проверка сотрудником

→ ответ, расчёт или передача в работу.

Подключение почты выполняется через API, webhook или другой поддерживаемый механизм уведомлений. Например, Gmail API позволяет подписаться на изменения в почтовом ящике и передавать уведомления серверному приложению, но обработчик всё равно должен учитывать повторную доставку, задержки и периодическую синхронизацию.

В промышленной системе каждый этап должен оставлять лог: какой объект получен, какая версия файла обработана, какие поля извлечены, какие правила сработали, что изменил сотрудник и какой результат ушёл в CRM. Без этого автоматизация превращается в «чёрный ящик», который сложно проверять и поддерживать.

Входящие письма

Почтовый обработчик получает тему, отправителя, получателей, текст, цепочку сообщений и вложения. Затем система:

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

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

Формы сайта

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

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

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

PDF и другие вложения

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

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

Особенно внимательно проверяют:

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

Не каждый этап обработки заявок следует передавать языковой модели.

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

Ниже показана возможная структура интерфейса, а не скриншот существующей системы.

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

Проверка должна проходить на нескольких уровнях.

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

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

Справочная проверка сопоставляет компанию, товар, договор, склад, регион и ответственного с внутренними системами. Здесь важны точные идентификаторы и правила приоритета.

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

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

Правила валидации могут проверять согласованность полей и арифметику документа — например, совпадает ли сумма строк с итогом. Такие проверки полезно выполнять отдельно от модели, чтобы ошибка была воспроизводимой и объяснимой.

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

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

Рассмотрим условный пример.

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

Система выполняет следующие действия:

• Сохраняет письмо, цепочку и исходный PDF.
• Определяет тип обращения как запрос на расчёт.
• Извлекает контакт из подписи.
• Получает текстовый слой PDF и разбирает таблицу.
• Нормализует единицы измерения.
• Сопоставляет 16 позиций с каталогом.
• Для двух строк показывает по два возможных аналога.
• Проверяет наличие обязательных полей.
• Создаёт черновик заявки в CRM.
• Назначает менеджеру задачу проверить аналоги и подтвердить срок.
• После подтверждения формирует черновик ответа.

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

Похожий прикладной контур показан в кейсе AI-системы для B2B-поставщика: заявки из почты, мессенджеров, Excel и PDF сопоставляются с данными 1С, склада и CRM, а менеджеру остаются проверка, переговоры и финальное решение.

Пилот лучше ограничить одним типом заявки и одним дальнейшим действием. Например: письма с PDF-спецификациями → черновик карточки в CRM → ручное подтверждение.

Для подготовки нужны:

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

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

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

Подход к выбору первого процесса подробнее разобран в материале «Автоматизация бизнес-процессов: что автоматизировать первым», а граница между обычной интеграцией и AI — в статье «Когда бизнесу действительно нужен ИИ». На сайте engineer. этот принцип сформулирован прямо: сначала разбираются процесс, данные и точка полезного эффекта, затем выбирается технология.

Стоимость определяет не само наличие AI, а границы процесса. На оценку влияют:

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

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