Учёт заявок на перевозку: почта, сообщения и таблицы в одном месте

Теоретический пример. Клиент в понедельник пишет на почту: 8 палет из Тулы в Казань, 4,2 тонны, забрать в среду. Во вторник по телефону меняет адрес выгрузки, в среду утром в мессенджере просит добавить ещё 4 палеты. Логист назначил машину по первому письму. Пятитонник приезжает под 8 палет, а грузить нужно 12 палет и больше шести тонн. Все изменения были, но в трёх разных каналах, и в карточке заявки их нет.

Реестр заявок на перевозку отвечает на три вопроса: что клиент запросил, что компания подтвердила и что происходит сейчас.

Входящий запрос ещё не готовая перевозка

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

В модели заказов ATI.SU предусмотрены отдельные этапы согласования и выполнения. Так устроен конкретный сервис, у вас порядок может быть другим. Для собственного реестра сначала опишите, кто имеет право подтвердить заказ и какие условия к этому моменту должны быть проверены.

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

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

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

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

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

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

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

Условный пример: клиент заказал отправку десяти палет. Шесть уехали сегодня, четыре должны отправиться завтра. Если одна строка содержит единственную машину и статус «в пути», реестр не объяснит, какая часть уже движется и что осталось организовать.

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

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

Изменения должны иметь версии

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

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

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

Как обрабатывать дубли и отмены

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

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

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

Как связать реестр с тем, что уже используется

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

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

Что должен видеть логист утром

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

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

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

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

ИИ как помощник при создании карточки

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

Условный вход: «Нужно забрать 8 палет из Тулы, 4,2 т, доставить в Казань. Адрес и дату пришлю отдельно». Предлагаемый результат: восемь палет, масса 4,2 тонны, города Тула и Казань, точные адреса и даты отсутствуют. Карточка получает состояние «уточнить данные», а сотрудник видит список вопросов. Сервис не превращает город в выдуманный склад и не считает обращение подтверждённой перевозкой.

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

Передача смены без пересказа всех заказов

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

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

Первая версия и проверка пользы

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

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

Следующий шаг

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

Источники

• ATI.SU: API для работы с заказами, структура состояний и работа с заказом; проверено 18.10.2026.
• CARGO.RUN: инструкция по работе платформы, сборные заявки; проверено 18.10.2026.

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