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

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

Безопасная последовательность выглядит так:

1. определить тип входящего сообщения;
2. отделить новый текст от подписи и цитат;
3. найти связанную переписку и проверить вложения;
4. отметить известные и недостающие сведения;
5. подготовить черновик задачи;
6. передать спорный случай человеку;
7. создать задачу только по согласованному правилу.

Отправка содержательного ответа клиенту — отдельная операция. Даже если система правильно разобрала письмо, это ещё не даёт ей права подтверждать заказ, дату, цену или другие условия.

Почему письмо нельзя сразу превращать в задачу

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

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

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

Что подготовить до подключения общего ящика

Начните не с модели или почтового API, а с правил команды. Иначе система лишь ускорит существующую путаницу.

Нужно согласовать:

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

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

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

Как собрать контекст письма

Отделить новый текст от цитаты

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

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

Найти связанную переписку

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

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

Проверить вложения

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

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

Сохранить путь к оригиналу

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

Учебный пример: неполное письмо

Условная переписка, не клиентская заявка и не проведённый тест.

Исходное письмо:

Нужна доставка, адрес в приложенном файле.

Вложение недоступно. Затем приходит продолжение:

И дату пока не подтверждайте.

Допустимый результат разбора:

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

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

Как классифицировать и направлять письма

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

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

Спорная классификация не должна исчезать внутри технического журнала. Сотруднику полезно показать:

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

Содержимое письма при этом остаётся входными данными. Фраза во вложении или тексте не может выдать системе новые права, отменить проверку или разрешить доступ к чужим данным.

Разделите классификацию, задачу и ответ

В почтовом процессе есть три разных решения.

Классификация отвечает на вопрос, что это за сообщение и куда его направить. Ошибка здесь меняет маршрут.

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

Отправка ответа создаёт внешнее обязательство перед адресатом. Подтверждение получения можно отделить от ответа по существу. В рассматриваемом сценарии содержательные ответы остаются черновиками для проверки человеком.

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

Что проверить перед запуском

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

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

Минимальные критерии приёмки можно сформулировать так:

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

Как подойти к внедрению

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

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

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

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