ИИ-ассистент для транспортной компании

Диспетчерская транспортной компании звучит одинаково в любом городе. «Где машина?» «Когда будет разгрузка?» «Вы ТТН отправили?» «Почему статус не поменялся?» «Мне счёт нужен, пришлите повторно». Между этими звонками где-то на трассе стоит фура со сломанным компрессором, и именно этим диспетчер должен заниматься прямо сейчас — но не может, потому что линия занята.

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

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

Как на самом деле устроен поток звонков диспетчеру

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

Первые три строки — это уже больше половины потока, и все они отвечаются по данным, которые у вас уже есть. Не по «пониманию контекста», не по опыту диспетчера, а по конкретной записи в TMS, статусу в системе мониторинга и файлу в ЭДО. Диспетчер здесь работает живым API к вашим же системам: открывает окно, ищет номер заявки, читает вслух.

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

Где именно теряются деньги и время

Первое: диспетчер занят не тем. Хороший диспетчер — это человек, который умеет за пятнадцать минут найти замену сломавшейся машине, договориться с грузополучателем о переносе окна разгрузки и не дать рейсу рассыпаться. Это дефицитная компетенция. Когда 60% его смены уходит на зачитывание статусов из TMS, вы платите за экспертизу, а используете диктофон.

Второе: ночь и выходные. Груз едет круглосуточно, диспетчерская — далеко не всегда. Ночная смена стоит денег, её обычно держат в усечённом составе или не держат вообще. Клиент, который в 23:30 не может узнать, приедет ли машина к утренней приёмке, утром звонит уже не с вопросом, а с претензией.

Третье: водители. Отдельный, недооценённый поток. Водителю нужен телефон грузополучателя, номер пропуска, скан доверенности, подтверждение, что заявку на въезд подали. Каждый такой запрос — минута диспетчера, а водителей в рейсе одновременно десятки.

Четвёртое: расфокус. Звонок «где машина» посреди разбора реального ЧП — это не минута потерянного времени, а сбитый контекст. Диспетчер возвращается к проблеме и заново вспоминает, на чём остановился.

Пятое: неравномерность ответов. Новый диспетчер называет сроки по ощущениям, опытный — по регламенту. Обещание «завтра к обеду», данное без опоры на данные, потом становится предметом спора.

Что делает ассистент

Это не голосовое меню и не бот с кнопками. Это связка из пяти частей, каждая со своей ответственностью.

Идентификация обращения. Прежде чем что-то отвечать, надо понять, кто спрашивает и о какой отправке речь. Номер заявки, номер ТТН, номер машины, название компании-клиента — ассистент вытягивает идентификатор из свободного текста и проверяет право доступа. Чужому человеку статус чужого груза не сообщается.

Запрос в ваши системы. Статус нельзя «найти в документе» — его надо взять из TMS, из системы мониторинга транспорта, из WMS, если груз на складе. Ассистент ходит по API и работает только с тем, что вернули системы.

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

Работа с документами. Отправить повторно счёт, прислать скан ТТН, сказать, подписан ли акт в ЭДО, — типовые действия, которые сводятся к запросу в документооборот и отправке файла по уже зарегистрированному каналу клиента.

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

Клиент / Водитель → Ассистент
      ├─ Идентификация: номер заявки, ТТН, машина, право доступа
      ├─ TMS / трекинг ──────→ статус рейса, плановое и фактическое время
      ├─ WMS ────────────────→ приёмка, отгрузка, остатки по клиенту
      ├─ ЭДО / документы ────→ ТТН, акты, счета, статус подписания
      ├─ База знаний ────────→ регламенты, тарифы, зоны, требования
      └─ Нет данных / ЧП / претензия / деньги → Диспетчер (+ контекст)

Интеграция с TMS, WMS и трекингом

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

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

Система мониторинга транспорта. Даёт координаты и скорость. Отсюда берётся прогноз прибытия — но с осторожностью. Координаты сами по себе не отвечают на вопрос «когда разгрузят»: между «машина в 40 км от склада» и «груз принят» лежат очередь на въезд, окно приёмки и работа склада.

WMS. Нужна, если у вас есть складской контур: ответы про приёмку, комплектацию, отгрузку, остатки по клиенту.

ЭДО и документооборот. Отсюда — статусы документов и сами файлы.

Ключевой технический вопрос — актуальность данных. У каждого источника своя частота обновления: трекинг может обновляться раз в минуту, статус в TMS — только когда его руками поменял диспетчер или водитель отметился в мобильном приложении. Ассистент должен знать возраст данных и учитывать его в ответе.

Отдельный контур для водителей

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

Что закрывается в водительском контуре:

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

Канал обычно один — мессенджер, потому что он уже стоит у водителя в телефоне. Требования к формату жёсткие: короткие ответы, минимум текста, файлы сразу вложением. Водитель читает это одной рукой на стоянке.

Отдельно — что в водительском контуре запрещено. Ассистент не согласовывает отклонения от маршрута, не разрешает простой, не подтверждает доплату, не даёт указаний при ЧП. Всё это — диспетчер, и переключение должно происходить мгновенно, по одному сообщению и по ключевым словам («авария», «ДТП», «сломался», «задержали», «не принимают груз»).

Что автоматизируется, а что нет

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

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

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

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

Претензии. Порча, утрата, недостача, срыв срока — это про деньги и про ответственность по договору. Ассистент принимает обращение, фиксирует его, объясняет порядок подачи претензии и передаёт человеку. Он не оценивает обоснованность, не признаёт вину и не отказывает.

Обязательства. Даже в простом случае ассистент не говорит «гарантирую, что будет завтра». Он говорит «по плану доставка завтра, статус актуален на такое-то время». Разница юридическая и очень существенная.

Предварительный расчёт стоимости: как не навредить

Расчёт по маршруту — соблазнительная функция. Клиент спрашивает «сколько будет фура Москва — Казань», и ответ есть в тарифной сетке. Но именно здесь легче всего создать проблему.

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

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

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

Как посчитать экономику до внедрения

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

Возьмём условную транспортную компанию: 2 500 обращений в диспетчерскую в месяц (звонки, почта, мессенджеры), 3 диспетчера на линии, среднее время обработки одного обращения 4 минуты с учётом поиска в системах, фонд оплаты одного диспетчера с налогами 90 000 ₽ в месяц.

Шаг 1. Объём в часах. 2 500 × 4 мин = 10 000 минут = около 167 часов в месяц чистого времени на обработку обращений.

Шаг 2. Автоматизируемая доля. По таблице структуры — 50–65%. Берём осторожную нижнюю границу: 50%, то есть примерно 83 часа.

Шаг 3. Реальное высвобождение. Часть обращений ассистент закроет частично, часть эскалирует, часть клиентов всё равно захочет человека. Закладываем, что реально снимается 70% от автоматизируемого объёма — около 58 часов в месяц.

Шаг 4. В деньгах. 58 часов при ставке ~560 ₽/час (90 000 ₽ / 160 ч) — примерно 32 500 ₽ в месяц по прямому ФОТ. Само по себе это не выглядит революцией — и это честно. Основная ценность в другом: эти 58 часов возвращаются в работу с реальными проблемами на маршруте, а ночной контур перестаёт требовать отдельной смены.

Шаг 5. Ночной контур. Здесь эффект считается отдельно и обычно оказывается крупнее. Если у вас есть ночная смена диспетчеров хотя бы в один человек, это порядка 90 000 ₽ в месяц ФОТ плюс доплаты за ночные часы. Если ночной смены нет, эффект другой: ночные обращения перестают копиться и падать лавиной на утреннюю смену.

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

Этапы внедрения

1. 1
   3–5 дней

   Аудит потока и данных

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

2. 2
   1–2 недели

   MVP на самой массовой теме

   Собираем ассистента на статусах грузов — это всегда крупнейшая категория. Подключаем TMS и трекинг, настраиваем идентификацию по номеру заявки и проверку прав доступа. Запускаем на части клиентов или на внутреннем тестировании диспетчерами.

3. 3
   1–1,5 недели

   Документы и водительский контур

   Подключаем ЭДО: отправка счетов, актов, ТТН, статусы подписания. Разворачиваем отдельный контур для водителей в мессенджере с укороченными ответами и жёсткими правилами эскалации при ЧП.

4. 4
   1 неделя

   Заявки и предварительный расчёт

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

5. 5
   5–7 дней

   Калибровка и передача

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

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

Риски и как они снимаются

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

«У нас данные в TMS обновляются как придётся». Частая и честная проблема: статус меняется, когда до него дошли руки. Аудит на первом этапе это вскрывает, и дальше есть два пути — либо подтягивать дисциплину заполнения, либо строить ответы на трекинге и явно ограничивать точность. Второй путь работает, но требует честных формулировок в ответах.

«Клиенты будут злиться на бота». Злятся не на бота, а на тупик. Поэтому переход на диспетчера доступен в один шаг и в любой момент, а при ЧП и претензиях он происходит автоматически, без просьбы. Клиент, который за пять секунд получил статус ночью, к боту относится хорошо.

«Водители не будут пользоваться». Будут, если ответ быстрее, чем дозвониться. Условие — короткий формат, работа в привычном мессенджере и отсутствие обязательных форм. Если водителю нужно заполнить анкету, чтобы узнать телефон грузополучателя, контур мёртв.

«Попадём в зависимость от подрядчика». Код, документация, доступы и права передаются вам. Обновлять тарифную сетку, регламенты и правила эскалации команда должна уметь сама — этому учим на этапе передачи.

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

Как измерять качество

Без метрик вы не отличите «работает» от «клиенты перестали спрашивать и просто ушли». Смотреть надо на связку показателей.

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

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

Вторая — доля корректно распознанных ЧП. Здесь недопустима статистика вида «в 97% случаев отработали правильно». Пропущенная авария, на которую система ответила бытовым текстом вместо мгновенной эскалации, — это отдельный инцидент с разбором. Поэтому распознавание ЧП строится максимально широко: лучше десять ложных эскалаций, чем одна пропущенная.

И контринтуитивное про эскалации. Кажется, что чем их меньше, тем лучше система. На деле слишком низкая доля эскалаций в логистике — плохой признак: значит ассистент отвечает там, где должен был передать человеку. Здоровый коридор обычно 15–25%, выше, чем в рознице, — сказывается доля нестандартных ситуаций.

Частые вопросы

Заменит ли ассистент диспетчеров? Нет. Он снимает поток однотипных запросов и ночную нагрузку, чтобы диспетчер занимался тем, ради чего его держат: решал проблемы на маршруте, искал замену транспорту, договаривался с площадками. Обычно это перераспределение нагрузки, а не сокращение штата — особенно на рынке, где хорошего диспетчера трудно найти.

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

Насколько точным будет прогноз времени прибытия? Ассистент отдаёт то, что есть в системах: плановое время из TMS и, если есть трекинг, фактическое положение с отметкой времени. Строить собственную ML-модель прогноза прибытия можно, но это отдельный проект со своими требованиями к историческим данным, и ввязываться в него на старте не стоит. На первом этапе честный ответ «план такой, отметка такая» закрывает подавляющее большинство вопросов.

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

Как быть с несколькими клиентами на одной отправке? Разграничение доступа настраивается на этапе интеграции: ассистент отдаёт данные только тому, кто имеет право их видеть по этой заявке. Идентификация обязательна, «скажите номер машины» вместо проверки — не вариант.

Можно ли начать с малого? Нужно. Рабочий заход — только статусы грузов, только для действующих клиентов, только в одном канале. За две-три недели видно и качество ответов, и реальную долю автоматизации, и реакцию клиентов. Решение о полном внедрении принимается на ваших данных, а не на презентации.

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

Что понадобится от вас

Чтобы аудит был расчётом, а не гаданием:

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

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