How long a delivery exception lasts, and what to do meanwhile

If you are a customer waiting on a parcel

Short version first, because that is probably why you are here.

The word "exception" on a tracking page is carrier jargon for "this parcel is no longer following the normal plan". It is a flag, not a verdict. The most common cause by a wide margin is unexciting: the vehicle ran out of day, the weather stopped the route, the depot missed a sort. The parcel is in a building somewhere and will be scanned again.

What to actually do, in order:

1. Wait one scan cycle. Parcels usually get scanned at fixed points: depot in, depot out, loaded, attempted. If the status has not moved in 24 hours of working days, it is worth acting. Before that, you will just be told to wait.
2. Read the exception reason rather than the word "exception". It is the only useful information on the page. "Address incomplete" and "weather delay" are completely different situations, and only one of them will fix itself.
3. Check your own address on the order. A missing flat number is the single most fixable cause, and it is the one that will sit stuck forever because nobody can resolve it without you.
4. Contact the seller, not the carrier. This is counter-intuitive and it matters. The carrier's contract is with the sender. In most cases the carrier will not open an investigation for a recipient, and the seller can.
5. On "damaged" or no scan at all for several days, ask the seller to raise a claim. Most carriers require a waiting period, commonly around seven business days, before they will declare a parcel lost.

What will not help: calling daily, or paying to expedite a parcel that has not been located. Neither causes a scan. The rest of this is for the person on the other side of that tracking page.

How long delivery exceptions last depends on the reason code

For an operator, the mistake is treating "exceptions" as one number. It is at least four different failure types with nothing in common except where they show up.

Access and availability failures. Nobody home, gate code wrong, reception closed. The parcel and the plan were fine; the destination was not available. These resolve on a retry, which costs you a whole second attempt. For residential work this is usually the biggest bucket, and the most reducible. Getting to the address is solved; getting inside is not.

Data failures. Bad address, missing unit number, wrong phone. These never self-resolve. They sit until a person phones someone.

Network failures. Missorts, depot backlogs, weather, breakdowns. Mostly outside your control with a carrier, mostly inside it if you run your own vans. They clear on the next cycle.

Condition failures. Damaged, leaking, refused by the recipient. These do not clear, they convert into a return.

If your exception report gives you one percentage, you cannot act on any of this. Split it by those four buckets for a month and the shape of the problem usually turns out to be nothing like what the team assumed.

Stopping the ones you cause

Two of those four buckets are yours. Here is where the real gain sits.

Fix the address at order time, not at the door. Validating an address when the order is created costs seconds. Discovering it is wrong when a driver is standing outside costs the whole visit plus a phone call plus a second attempt. Any order that cannot be geocoded to a building should be stopped before it reaches a route, and somebody should phone the customer that morning.

Capture access information once and keep it on the job, not in a person's head. Gate code, which door, where the key safe is, which neighbour takes parcels, what time reception closes. This is the single highest-value field in a delivery system and most teams have no formal place to put it. The driver who learned it on Tuesday is on a different round on Thursday.

Give the customer a real arrival window. Most nobody-home failures are not avoidance, they are surprise. A tracking link saying the van is forty minutes away converts a failed attempt into a successful one at almost no cost.

Make proof unambiguous. Many "exceptions" raised days later are disputes rather than operational failures: it was delivered, and now nobody can prove it. Electronic proof of delivery with a photo, a timestamp and a location turns that argument into a thirty-second lookup.

Handling the ones you get

You need a desk, not a queue. The difference is that a desk has an owner, a clock and a rule.

Exception rate = (deliveries flagged as exceptions / total deliveries) x 100
First-attempt delivery rate = (delivered on first attempt / total deliveries) x 100

Track both. Exception rate tells you how much mess you are generating. First-attempt rate tells you what it costs. We are not going to quote you an industry benchmark for either, because there is no credible published figure that holds across parcel, grocery, pharmacy and heavy goods. Your own number measured consistently over six months is worth more than somebody else's average.

Three rules that work:

• A named owner per shift. Not "the team". One person who is accountable for the exception list being empty at the end of the day.
• A contact clock on data failures. Set a limit — 60 minutes is a reasonable starting point — for how long a bad-address exception can sit before somebody has phoned the customer. These do not decay, they accumulate.
• Tell the customer before they ask. The cheapest exception is one where the recipient already knows. The expensive one is the one that arrives as an angry call to someone who then has to go and find out what happened.

And measure the second attempt. Every retry is a stop you were not paid for: the same drive, the same dwell time, the same slot taken from a paying job. Work out your own cost per stop, multiply by your monthly failed attempts, and you will have the real budget for fixing the access and address problems upstream.

OkPilot keeps access notes, proof and the customer's tracking link attached to the job rather than to whoever happened to run it last week, which is what stops the same address generating the same exception every month. The delivery management page covers how that is set up.