Транспортные заявки приходили письмом, из формы на сайте и из мессенджеров — в свободном тексте, с вложениями и уточнениями «по ходу». Диспетчер вручную вытаскивал адреса, груз, сроки и ограничения, потом считал маршрут, заводил заказ и собирал документы. Мы разработали систему, которая делает этот контур сама: извлекает данные заявки, рассчитывает маршрут и стоимость, создаёт заказ в TMS или 1С, формирует документы и отправляет клиенту уведомления о статусе груза. Диспетчер остаётся в процессе — но только там, где ситуация нестандартная.
Заявка пришла — и сразу в работу
Клиент пишет на почту, заполняет форму или кидает детали в мессенджер. Для системы это один входной поток, а не три очереди с тремя привычками разбора. Заявка не ждёт, пока диспетчер «доберётся до ящика»: контур забирает обращение и начинает извлекать смысл.
Так закрывается первая дыра логистики — потерянное время между «клиент уже описал перевозку» и «заказ появился в TMS».
Что система достаёт из текста
ИИ разбирает заявку и вытаскивает то, без чего нельзя ни маршрут, ни заказ:
- адреса (откуда / куда и связанные точки, если они названы);
- груз (что везём, в каком виде это сформулировано клиентом);
- сроки;
- требования к перевозке (ограничения, условия, особые пожелания, которые влияют на исполнение).
Свободный текст и разные каналы перестают быть проблемой формата: на выходе — структурированные данные под расчёт и создание заказа, а не переписка, которую ещё предстоит «перевести на язык TMS».
Маршрут, стоимость, заказ
Когда параметры собраны, система рассчитывает маршрут и стоимость перевозки. Это не отдельный Excel «на потом», а следующий шаг того же контура: из заявки — в цифры маршрута и ставки.
Дальше создаётся заказ в TMS или 1С. Перевозка становится объектом учёта и управления, а не договорённостью в чате. На типовой заявке диспетчеру не нужно руками перебивать поля и заводить заказ с нуля — карточка появляется из уже извлечённых данных и расчёта.
Документы и статусы для клиента
После заведения заказа система формирует документы по процессу перевозки и отправляет клиенту уведомления о статусе груза. Клиент не должен писать «ну как там?» после каждого этапа, а диспетчер — не обязан быть ручным каналом статусов.
Информационный контур замыкается: заявка → расчёт → заказ в TMS/1С → документы → статусы. Человек не является обязательным звеном на каждом шаге.
Где подключается диспетчер
Правило простое: типовое идёт автоматически, нестандартное — к человеку.
Нестандарт — это спорные или неполные данные, требования вне обычных правил перевозки, конфликт сроков и маршрута, случаи, где расчёт или заведение заказа нельзя закрыть уверенно без решения специалиста. Тогда диспетчер входит в процесс уже с извлечённым контекстом заявки, а не с пустым «разбери письмо».
Так сохраняется контроль на рисках и скорость на потоке. Цель не «убрать диспетчера», а убрать его из бесконечного ручного парсинга однотипных заявок.
Почему это собрали именно так
Пока адреса, груз и сроки живут только в переписке, TMS всегда отстаёт. Пока маршрут и стоимость считаются отдельно от заведения заказа, появляется второй разрыв. Пока статусы шлёт человек, поддержка клиентов по «где груз» снова садится на диспетчерскую смену.
Поэтому разработали сквозную систему, а не бота, который только вежливо принимает заявку и всё равно отдаёт всё на ручной ввод.
В контуре:
- Эскалация диспетчеру на нестандартные ситуации.
- Приём заявок из почты, форм и мессенджеров.
- Извлечение адресов, груза, сроков и требований к перевозке.
- Расчёт маршрута и стоимости.
- Создание заказа в TMS или 1С.
- Формирование документов.
- Уведомления клиенту о статусе груза.
Заявки приходили письмом, из форм и мессенджеров — диспетчер вручную вытаскивал адреса, груз и сроки, потом заводил заказ в TMS. Мы собрали сквозной контур: извлечение данных, расчёт маршрута и стоимости, заказ в TMS или 1С, документы и уведомления клиенту. Диспетчер подключается только на нестандартных ситуациях — уже с извлечённым контекстом, а не с пустым «разбери письмо».
„
Максим, Руководитель проектов NeuroB2B
| Было | Стало |
| Заявки из почты, форм и мессенджеров разбирали вручную | Система забирает все три канала в один контур |
| Адреса, груз, сроки и требования вытаскивали глазами | ИИ извлекает данные из заявки |
| Маршрут, стоимость и заказ в TMS/1С собирали отдельно | Расчёт и создание заказа идут автоматически |
| Документы и статусы закрывали руками | Документы формируются, клиент получает уведомления о статусе |
| Диспетчер сидел на всём потоке | Диспетчер — только на нестандартных ситуациях |
Что вышло в результате
Логистика получила ИИ-контур вокруг транспортных заявок и TMS. Система принимает обращения из почты, форм и мессенджеров, достаёт параметры перевозки, считает маршрут и стоимость, создаёт заказ в TMS или 1С, готовит документы и держит клиента в курсе статуса груза.
Типовые заявки больше не стоят в очереди на ручной ввод. Диспетчерская смена тратит внимание на исключения — там, где автоматике нужен человек, а не на перебивку одних и тех же полей из письма в TMS.
