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

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

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

Готовым считается результат в рабочей программе. Если логист копирует ответ нейросети в карточку рейса, ручное перебивание осталось.

Наш план первой версии оставляет принятие заявки диспетчеру. Он подтверждает условия перевозки и исправляет спорные поля до записи.

Что делать, если письмо неполное? Сохранить его, заполнить понятное и показать диспетчеру, чего не хватает для принятия.

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

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

При повторной обработке принятой версии новая заявка не возникает. Этот сценарий проверяют на приёмке отдельно от качества распознавания.

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

Добавление поля меняет и проверку. Появились требования к температуре груза, значит приёмка проходит все входы заявки с этим полем.

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

Откуда взять статус груза? Из учёта или подтверждения ответственного сотрудника с отметкой времени. Модель получает это событие для ответа.

Истёкшее плановое время доставки не доказывает выгрузку. Правило для ответа клиенту: сообщать последнее подтверждение и его время.

Если подтверждения нет, запрос попадает диспетчеру. Фраза «груз доставлен» не появляется из расписания или догадки модели.

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

Размытый реквизит остаётся спорным. В документации Microsoft проверку человеком и разные форматы документов выделяют отдельно от оценки уверенности модели.

Распознавание не подтверждает содержание документа. Заполнение шаблона, отправка и подписание требуют своих правил принятия.

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

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

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

В уроке «Руль, окно и сторож» курса «Агентная разработка» эта связка собрана вместе. Правила задают работу, экран показывает результат, сторож замечает остановку.

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

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

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

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

Результат сверяют после записи в учёт. Успешное распознавание при потерянном поле не закрывает задачу; зелёный отчёт разработчика это не исправляет.

Код связки пишут ИИ-агенты под управлением инженера. Работающая функция распознавания получает письма по отдельно согласованным правилам.

Доступ к боевой почте не нужен агенту, чтобы писать код. Это разделение разобрано в статье о персональных данных и ИИ-агентах.

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

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

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

Исключения запишите в очередь работ. Шаблон такой задачи для ИИ-агента уже разобран в соседней статье.

Если непонятно, кто будет принимать работу и вести исключения, начните с теста для руководителя.

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

На 7 октября 2026 «Один проект» стоит 250 000 ₽ в месяц. Один продукт и одна задача в работе; очередь следующих задач ждёт.

Расходы работающего продукта оплачиваются отдельно по условиям /services. Распознавание документов и сторонние сервисы нужно включить в бюджет.

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

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