Разбираем задержку доставки по шагам с ИИ

Автор: MashaGPT • 3 Сентября, 2026 • НейросетиРазбор задержки доставки нейросетью

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

Зафиксируйте исходное обещание

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

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

Соберите путь заказа по времени

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

ЭтапНужное событиеЧто проверяем
Заказподтверждён состав и срокреалистичность обещания и остаток
Складначаты и завершены сборка и упаковкаочередь, недостача, пересорт
Передачагруз принят перевозчикомфактическое время и число мест
Маршрутназначен рейс и курьерёмкость, адрес и интервал
Вручениепопытка, результат, подтверждениеконтакт, доступ, повреждение

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

Хронология движения заказа

Найдите первый момент отклонения

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

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

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

Проверьте не только срок доставки

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

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

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

Сначала разделите срывы на группы

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

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

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

Гипотезы проверяют фактами

Методы пяти «почему» и диаграммы причин помогают не останавливаться на фразе «курьер не успел». Возможные ветви удобно разложить по людям, процессу, данным, оборудованию, поставкам и внешним условиям. Но это карта вопросов, а не доказательство.

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

Карта причин задержки

Отделите разовый случай от системной проблемы

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

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

Клиенту сообщают факты и следующий шаг

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

Нейросеть быстро подготовит несколько вариантов сообщения. В запрос передавайте только подтверждённые факты и чётко запретите придумывать причину, компенсацию и дату. Для клиента полезнее честное «уточним до 16:00», чем уверенное обещание, которое снова будет сорвано.

Уточнение задержанной доставки

Закрепите вывод конкретным изменением

Фраза «усилить контроль» ничего не меняет. Решение должно называть действие, владельца, срок и признак результата. Например: запретить обещание доставки до резервирования остатка; проверять адрес до маршрутизации; фиксировать время окончания сборки автоматически; отделить повреждение от опоздания в кодах результата.

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

  1. Опишите проблему на конкретной выборке заказов.
  2. Восстановите события и первый момент отклонения.
  3. Разделите случаи по этапам и рабочим сегментам.
  4. Сформируйте несколько причин и проверяющие тесты.
  5. Назначьте действие и владельца процесса.
  6. Проверьте эффект без изменения методики задним числом.

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

Сколько доставок нужно для анализа?

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

Можно ли анализировать только комментарии курьеров?

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

Что делать, если статусы заполняют неточно?

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

Кого считать виновным в сорванной доставке?

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

Нужно ли загружать адреса и телефоны клиентов?

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