Как собрать данные из письма и вложений в карточку заявки

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

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

Когда единая карточка действительно нужна

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

Процесс удобно разделить на четыре шага:

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

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

Формулировка темы основана на задаче потенциального заказчика. Частотность запроса и поисковая выдача не измерялись, а коммерческая близость остаётся редакционной гипотезой.

Какие источники объединяются в одну заявку

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

В n8n операция Get для ресурса Thread узла Gmail получает одну переписку по Thread ID. При включённом упрощённом ответе документация n8n указывает идентификаторы сообщений, метки и заголовки From, To, CC, BCC и Subject. Это подтверждает способ получить метаданные переписки, но не гарантирует получение всех тел сообщений и вложений в конкретной конфигурации. Подключение, права и фактический ответ Gmail нужно проверить на данных заказчика.

Для каждого входного элемента полезно сохранить:

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

Если письмо нельзя устойчиво связать с заявкой, система не должна присоединять его по догадке. Такой случай передают сотруднику.

Схема карточки и происхождение каждого поля

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

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

Значения стоит разделить на четыре группы:

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

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

Как получить данные из вложений

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

Документация платформы n8n описывает узел Extract From File: он извлекает данные из бинарного файла и преобразует их в JSON для дальнейшей обработки workflow. В документации перечислены операции для CSV, HTML, JSON, ICS, ODS, PDF, RTF, текстовых файлов, XLS и XLSX.

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

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

Как собрать структурированный черновик

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

В n8n узел Information Extractor предназначен для извлечения структурированной информации из входящих данных. Документация платформы позволяет задать формат результата тремя способами: описаниями атрибутов, примером JSON или вручную через JSON Schema.

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

Соответствие результата JSON-схеме означает лишь то, что данные имеют заданную структуру. Оно не подтверждает, что организация, дата, сумма или количество извлечены из правильного места и совпадают с исходником.

Пропуски, противоречия и участие сотрудника

Правила обработки исключений задают до подключения записи во внешнюю систему:

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

Для будущего решения можно согласовать состояния карточки: «черновик», «требуется уточнение», «требуется проверка», «подтверждена», «передана в систему» и «ошибка передачи». Это проектные требования, а не встроенные состояния n8n по умолчанию.

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

Условный пример: письмо, PDF и таблица

Ниже — синтетическая демонстрация ожидаемого поведения. Это не клиентский кейс, не выполненный тест и не результат внедрения Switch On AI.

Клиент пишет о поставке оборудования. В теме указан объект, в тексте — контакт, желаемая дата и количество 12 единиц. PDF содержит перечень позиций, а XLSX — те же позиции с количеством 10. Система готовит черновик, но не выбирает одно из конфликтующих чисел.

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

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

Проверка перед записью в рабочую систему

Формирование черновика, подтверждение человеком и внешняя запись — три разные операции. Успешное извлечение текста или соответствие JSON-схеме не означает, что сведения верны.

На обезличенных или разрешённых примерах проверяют:

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

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

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

Ограничения и подготовка к внедрению

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

Для первой оценки понадобятся:

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

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

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

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