Как выстроить обработку исключений при отслеживании отправлений: от статуса посылки до закрытия тикета

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

В обсуждении заказов из нескольких посылок на r/ecommerce описывалось, как разделение одного заказа на несколько трек-номеров порождало автоматические письма из разных систем, и клиенты, получив лишь часть доставки, решали, что товары потерялись. Это сценарий одного продавца, и он не доказывает эффективность конкретного логистического ПО на рынке, но точно показывает первую ловушку модели данных: заказ, отправление, посылка и трек-номер — разные объекты.

Сначала отделите заказы от физических посылок

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

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

Связи посылок требуют явного версионирования. После того как перевозчик объединяет или передаёт отправления, старые трек-номера могут оставаться активными; система должна записывать replaced_by, last_mile_tracking или связи «родитель — потомок», а не считать новые номера отдельными заказами.

Стандартизируйте семантику, сохраняя исходные события перевозчиков

Документация FedEx Basic Integrated Visibility описывает события сканирования, окна доставки, статусы задержки и поля причин и отмечает, что информация о предполагаемом сроке доставки возвращается не для каждого трек-номера. Продукт для нескольких перевозчиков не должен предполагать одинаковую точность во всех источниках.

Внутренние статусы можно свести к небольшому набору этапов: label_created, accepted, in_transit, out_for_delivery, delivered, exception, returning и unknown. Однако каждое событие сохраняет исходный код перевозчика, описание, местоположение, время события, время получения и ссылку на исходный payload. Стандартизированные статусы обслуживают рабочие процессы, а исходные события — аудит.

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

Временные измерения тоже нужно разделять. Время события — когда происходит физическое событие, время получения — когда его получает система, время записи — когда данные попадают в хранилище. Когда они расходятся, система не должна переупорядочивать события, имитируя отслеживание в реальном времени. GS1 EPCIS v2.0.1 явно разграничивает семантику eventTime и recordTime; эту границу стоит перенять даже без полной реализации EPCIS.

Исключение — это не просто красная метка

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

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

Карточка исключения, с которой можно работать, содержит:

• Заказ и все связанные посылки, а также число доставленных посылок и посылок, ожидающих доставки.
• Текущие события, исходные описания перевозчика, время события и получения, актуальность данных.
• Исходная и новая расчётные даты доставки с причинами изменения; если источник не даёт окна доставки, поле явно остаётся пустым.
• Рекомендуемые действия, ответственные команды, статус уведомления клиента и время следующей проверки.
• Полномочия, необходимые для возврата средств, замены, изменения адреса или подачи претензии, чтобы сотрудники поддержки случайно не запустили финансовые операции.

Данные, полученные через push-механизмы и опрос, нужно сверять между собой

DHL Shipment Tracking Unified Push присылает обновления по подписке на трек-номер или аккаунт, но доступность зависит от перевозчика, аккаунта, региона и продукта. Вебхуки сокращают опрос, но всё равно могут приходить не по порядку, дублироваться или временно не доставляться.

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

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

Уведомления клиентам должны строиться вокруг действий, а не каждого сканирования

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

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

Сотрудники внутренней поддержки могут видеть больше деталей при соблюдении требований к защите персональных данных. В инструкциях для пользователей Unified Tracking DHL установлены условия законного использования отслеживания, авторизации, хранения и отображения данных; перед интеграцией нужно проверить действующие соглашения, чтобы логистические данные не агрегировались бессрочно и не использовались для рекламы лишь потому, что существует трек-номер.

Начните MVP с очереди исключений, а не с анимации на карте

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

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

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

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