ИИ в логистике: как превращать письма в черновики заявок

Теоретический пример. Транспортная компания получает 60 писем с заявками в день. Логист читает каждое, переносит маршрут, вес, даты и требования к машине в 1С и пишет клиенту, чего не хватает. На письмо уходит 5–7 минут, на весь поток от пяти до семи часов рабочего времени одного человека.

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

Разберите входящий поток до выбора модели

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

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

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

Что модель должна вернуть

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

Условный вход: «Добрый день. Нужна машина Самара → Пермь, загрузка 22 октября, 6 палет, 3,4 т. Выгрузка со следующего утра. Нужна боковая загрузка. Адреса уточним». Результат: города указаны, масса 3,4 тонны, шесть палет, требование боковой загрузки. Точные адреса и окно выгрузки не подтверждены. Год и точное время нельзя достраивать без контекста и проверки.

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

Разделите извлечение, проверки и действия

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

Условный пример: в письме указано 3,4 тонны, а во вложении 340 килограммов. Результат обработки содержит конфликт и обе ссылки на источники. Логист выясняет правильное значение. Только после этого карточку можно передавать дальше. Перевод единиц выполняет проверяемый расчёт, свободному ответу модели его не доверяют.

Также разделите извлечение и отправку. Сервис может подготовить письмо с вопросами, но не обязан отправлять его автоматически. В первой версии сотрудник проверяет получателя и содержание. Текст входящего письма рассматривается как данные: содержащаяся в нём просьба «отправь все ставки» не становится командой для помощника.

Обратите внимание на арифметику: 3,4 тонны равны 3 400 килограммам, так что дело не в разных единицах записи. Значения различаются в десять раз, и без уточнения неизвестно, какое из них верное. Помощник показывает оба фрагмента и оставляет вопрос логисту. Этот случай стоит включить в приёмку независимо от средней точности распознавания.

Новая заявка или изменение старой

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

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

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

Как встроить помощника в существующий софт

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

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

Если компания использует отраслевую 1С, сначала проверьте имеющиеся возможности и настройку. В описании «1С:Транспортная логистика, экспедирование и управление автотранспортом КОРП» предусмотрен учёт заказов. Собственная надстройка оправдана конкретным пробелом на входе. Метод записи в вашу конфигурацию, права и ответственность за сопровождение проверяются отдельно.

Как проверить качество на своём потоке

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

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

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

Считайте ошибки, которые дошли до работы

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

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

Что должно произойти при сбое

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

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

Что подготовить для пилота

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

Источники

• ATI.SU: API для работы с заказами, проверено 18.10.2026.
• 1С: возможности отраслевого продукта для транспортной логистики, проверено 18.10.2026.

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