How to Build Shipment Tracking Exception Management: From Package Status to Ticket Resolution

Displaying carrier status on an order page only solves the visibility problem. Merchants actually need specific judgments: how many packages an order is split into, which one is delayed, whether an address update is required, when to proactively contact customers, who handles customs or lost packages, and how to write the resolution back to the order and support systems.

A multi-package order discussion on r/ecommerce described how splitting a single order into multiple tracking numbers caused automated emails from different systems, leading customers to assume items were missing when they only received a partial delivery. While this reflects a single merchant's scenario rather than proving the market efficacy of specific logistics software, it accurately exposes the data model's first trap: orders, shipments, packages, and tracking numbers are not the same object.

Separate Orders from Physical Packages First

An order can have multiple shipments, and a shipment can contain multiple packages; packages may also change tracking numbers, transfer to last-mile carriers, return, or redeliver. If the database only stores a single tracking_number in the order table, all subsequent statuses will be forced to overwrite each other.

We recommend establishing a four-tier relationship: orders store commercial commitments, shipments represent fulfillment arrangements, packages represent physical items, and tracking identities store carriers and tracking numbers. Events belong to a tracking identity while rolling up to packages and orders. During order splitting, customers see an order-level progress view instead of five unrelated emails: delivered 1/2, while another item is expected to arrive tomorrow.

Package relationships require explicit versioning. After carriers combine or transfer shipments, old tracking numbers may remain active; the system must record replaced_by, last_mile_tracking, or parent-child relationships rather than treating new numbers as separate orders.

Standardize Semantics While Retaining Raw Carrier Events

The FedEx Basic Integrated Visibility documentation outlines scan events, delivery windows, delay statuses, and reason fields, noting that estimated delivery information is not returned for every tracking number. A multi-carrier product should not assume identical precision across sources.

Internal statuses can converge into a small set of stages including label_created, accepted, in_transit, out_for_delivery, delivered, exception, returning, and unknown. However, every event retains the original carrier code, description, location, event time, received time, and raw payload reference. Standardized statuses serve workflows, while raw events support auditing.

Normalization rules must not rely solely on English descriptions, as carriers frequently modify display text, languages, and time formats. DHL Unified Tracking update notes document changes such as explicit timezone offsets in timestamps and adjusted event text. If logic depends on exact copywriting, standard upgrades can cause missed exception alerts. Systems should prioritize mapping stable codes and establish a pending queue for unknown codes.

Time dimensions must also be separated. Event time is when the physical event occurs, received time is when the system receives it, and record time is when data enters storage. When these diverge, systems must not reorder events to fake real-time tracking. GS1 EPCIS v2.0.1 explicitly distinguishes eventTime and recordTime semantics; this boundary remains worth adopting even without a full EPCIS implementation.

An Exception Is Not Just a Red Label

Events labeled as exceptions require distinct actions: address issues require contacting recipients, customs clearance delays require commercial invoices, weather delays usually update expectations, delivery failures may allow rescheduling, and prolonged scan gaps require carrier investigations. Products should map source events to reason categories, suggested owners, and deadlines rather than simply sending delay emails.

Exception rules must also incorporate order context: high-value items, cold chain goods, promotional products, or packages with strict delivery dates have different waiting thresholds. Models can help categorize free text, but they should not promise refunds, replacements, or delivery dates without authorization. Actions must derive from merchant policies and available carrier capabilities.

An actionable exception card includes:

• The order and all associated packages, along with completed and pending counts.
• Current events, raw carrier descriptions, occurrence and receipt times, and data freshness.
• Original and new estimated delivery dates with reasons for changes; left explicitly blank when sources provide no window.
• Recommended actions, responsible teams, customer notification status, and next review times.
• Authorizations required for refunds, replacements, address changes, or claims to prevent support staff from accidentally triggering financial transactions.

Push and Poll Mechanisms Require Cross-Validation

DHL Shipment Tracking Unified Push provides proactive updates subscribed by tracking ID or account, though availability varies across carriers, accounts, regions, and products. While webhooks reduce polling, they can still arrive out of order, be duplicated, or fail temporarily.

Every event should feature an idempotency key; if sources lack stable event IDs, systems can combine carriers, tracking numbers, event codes, event times, and locations to generate auditable fingerprints. Receiving endpoints should store raw events before asynchronous processing, meaning a success response does not equal business action completion. Polling tasks compensate for missed updates while applying different frequencies to active items, stagnant items, and delivered items.

FedEx documentation recommends querying only at necessary business frequencies and removing delivered packages from batch tracking. Product costs depend on API unit prices alongside active package lifecycles, polling volume, webhook coverage, and historical retention. Treating refresh rates like polling all orders every 30 seconds as a real-time capability wastes quota and risks violating source terms.

Customer Notifications Should Focus on Actions, Not Every Scan

Sending notifications for every facility scan generates noise. Customers care more about carrier intake, significant delivery date shifts, required actions, out-for-delivery status, partial delivery, and complete delivery. Notification rules aggregate at the order level to prevent duplicate messages when two packages update within the same minute.

Exception notifications should state known facts, unknowns, and next steps. For example, stating one item is on hold due to an address issue and asking customers to verify via the official carrier portal is more actionable than a generic notice that an anomaly occurred. Address change links and payment requests must use verifiable domains to mitigate phishing risks.

Internal support agents can view additional details while maintaining personal data protections. DHL Unified Tracking user instructions establish conditions for lawful tracking usage, authorizations, data retention, and display; products must verify actual agreements prior to integration, preventing logistics data from being permanently aggregated or used for advertising simply because a tracking number exists.

Start with an Exception Queue MVP Rather Than Map Animations

Initial versions can cover a single store, two carriers, and recent in-transit orders. Validate order-to-package associations, event deduplication, status mapping, delivery date shifts, and three high-frequency exception types before connecting support ticketing. Map trajectories, prediction models, and full carrier coverage can be deferred.

Acceptance metrics include source event latency, unknown status ratios, exception discovery lead times, duplicate notification rates, manual first-response times, customer contacts per order, and approval workflows for replacements or refunds. Audits should also verify whether delivered statuses correspond to all packages rather than arbitrary tracking numbers.

Internal inventory replenishment product methods handle pre-shipping supply and procurement, while API self-healing guides address source failures; logistics exception products begin post-shipment events to close the loop on customer communication and resolution tickets.

This article does not imply that EveryInfra has released a logistics tracking product. The commercial value of trajectory data lies not in coloring eight carrier transit statuses in the same shade of blue, but in systems distinguishing which physical package encountered an issue and routing the next step to the appropriate handler.