Delivery exception: what it means and how to act on it

What a delivery exception means

A delivery exception is a carrier status indicating that a shipment has hit an event preventing it from being delivered as scheduled. Common causes are a failed delivery attempt, an incorrect or incomplete address, customs holds, weather, damage, or a parcel that has simply stopped scanning in the network.

The word makes it sound rare. On any meaningful order volume it is routine, and the practical question is not what the status means but who finds out about it first: you, or your customer.

Every order is a promise. Keeyu keeps the promise. A delivery exception is the moment a promise is quietly at risk.

The problem with exceptions is silence, not frequency

Carriers do raise exceptions. The trouble is that the signal lands in a carrier portal or a tracking feed that nobody is watching order by order, and the brand only learns about it when the customer writes in.

By then you are three days late, the customer is annoyed, and your agent has to open the carrier portal, the store and the warehouse to work out what happened. That is the reactive cycle: the customer becomes your monitoring system.

Worse are the shipments that never raise an exception at all. A parcel that stops scanning is not always flagged. It just stops. If your first signal is a customer asking where their order is, a lost parcel and a slow parcel look identical for a week.

How to tell lost from late

The useful rule is time in state rather than status text. If a shipment has not scanned in a defined window given its service level, it is functionally lost whatever the carrier status says. If an item is still in transit well past its expected delivery date, treat it as lost and act, rather than waiting for confirmation that may never come.

That rule can be automated. We run fully automated lost-in-transit workflows in Australia with Australia Post covering the whole chain: detect the stalled shipment, raise a new express shipment, notify the customer, and file the carrier claim.

We can identify 45 lost-in-transit orders in real time, select them all, and resolve them in parallel against a predefined workflow. The alternative is an agent working through them one at a time, days later, after 45 customers have already complained.

What good exception handling looks like

• Detection based on time in state, not just carrier exception codes
• A decision rule per exception type: reship, refund, redirect, or file a claim
• The customer told before they ask, with what you are doing about it
• The replacement raised and the claim filed as part of the same workflow

One of our customers had a consumer place a roughly $500 express order. We spotted the delay early, notified the fulfilment team, and the customer received the order on time. They never knew there had been a problem, which is the actual goal.

Why this sits in operations, not support

A helpdesk can only process the complaint that follows the exception. It cannot see the parcel stop moving. This is proactive e-commerce operations: watching the order across the store, the warehouse and the carrier, and acting on the break before the customer feels it. Detect. Decide. Act.

The customer gets what they want, on time, as promised, and where that is genuinely impossible, they hear it from you first with a replacement already moving.

See how the workflows run or book a demo.

Related reading

For order-status tickets, read WISMO. For the fulfilment layer, see fulfillment. For the operational picture, read post-purchase operations.