Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Delivery exception handler series ~5 min read

How an exception is detected

Detection has two halves. Reading the exception codes is the easy half and catches the obvious cases. Noticing that nothing has happened is the half that catches the expensive ones.

Key takeaways

  • Normalise carrier statuses into a small set of meanings; the raw codes differ wildly.
  • Measure the typical gap between scans per carrier and service, from your own shipments.
  • Flag at roughly three times the typical gap, in working days.
  • The never-scanned shipment is a separate and common case.
  • Keep the raw status alongside the normalised one, always.

Two detectors

How a delivery exception is detected from events or from silenceA vertical chain of five steps entered by a box labelled A tracking update, or the lack of one. Step one asks whether an event arrived at all; if not it exits to Check the gap against this service's normal. Step two normalises the status, mapping thirty or more codes to eight meanings. Step three asks whether it is an exception meaning such as refused, address problem or damaged; if not it exits to Normal progress, recorded and moved on. Step four raises an exception with the raw code kept. Step five passes it to triage to decide what it needs. A note says the first exit is the important one and runs on a schedule rather than on an event.AWS ACCOUNTA tracking updateor the lack of oneAn event arrived?any scan at allCheck the gapagainst this service's normalnoNormalise the status30+ codes to 8 meaningsAn exception meaning?refused, address, damagedNormal progressrecord and move onnoRaise an exceptionwith the raw code keptTo triagewhat does it need?The first exit is the important one and it runs on a schedule, not on an event.
Fig 1. The two detection paths. One reacts to events; the other reacts to their absence and is where the value is.
  • App integration
  • Machine learning
  • Management
  • Analytics

Normalising statuses

Carriers use dozens of status codes and no two use the same vocabulary. Mapping them to a small set — collected, in transit, out for delivery, delivered, attempted, address problem, refused, held — is unglamorous configuration work that makes everything downstream possible.

Keep the raw code and text next to the normalised meaning, always. The mapping will be wrong sometimes, new codes appear, and a normalised value with no original is a fact you cannot check.

What normal looks like

Typical gaps between tracking scans for three delivery servicesA stacked bar chart with three bars measured in hours. Two series: the typical gap between scans in green, and the additional hours before flagging in orange. A next-day parcel has a typical gap of eight hours and flags after a further sixteen. An economy parcel has a typical gap of twenty hours and flags after a further forty. Pallet freight has a typical gap of thirty hours and flags after a further sixty-six. A note says one threshold across all services either floods you or catches nothing.050100150200~24Next-day parcel~60Economy parcel~96Pallet freightTypical gap between scans, hoursAdditional hours before flaggingOne threshold across all services either floods you or catches nothing.
Fig 2. Three services with very different normal behaviour. A single silence threshold cannot serve all three, which is why it is derived per service from your own shipment history.

The numbers come from your own delivered shipments: take the gaps between consecutive scans on everything that arrived fine, and the flag threshold is roughly three times the typical one. That is a crude rule and it works considerably better than a number somebody chose.

It also self-corrects. When a carrier changes their scanning practice — fewer intermediate scans is a common cost saving — the observed gaps widen and the threshold follows, instead of producing a wave of false exceptions that trains everybody to ignore them.

Working days, again

A gap over a weekend is not a gap. Every threshold here is in working hours against the carrier’s own operating pattern, including the Saturday services that do scan and the ones that do not.

The shipment that never started

A shipment that was marked despatched but never collectedA horizontal row of five boxes. Label printed: Monday. Marked despatched in our system. Never scanned: no collection event. Still on a shelf, or in the wrong cage. Flagged at twenty-four hours: a tighter rule. A note says it is entirely an internal failure and is invisible without this check.THE MOST COMMON EXCEPTIONLabel printedMondayMarked despatchedin our systemNever scannedno collection eventStill on a shelfor in the wrong cageFlagged at 24ha tighter ruleIt is entirely an internal failure and it is invisible without this check.
Fig 3. The never-collected shipment. It is the single most common real exception in most businesses and it has no carrier status at all, because the carrier has never seen it.
  • Compute
  • Machine learning
  • Management
  • Front-end & mobile

This case deserves its own tighter threshold, because a parcel with no first scan after a day is almost always sitting somewhere in your own building. It is also the cheapest exception to fix, since the goods are within reach.

It is worth counting separately for the same reason. A steady rate of never-collected shipments is a warehouse process problem wearing a carrier problem’s clothes, and attributing it correctly is the first step to fixing it.

Next: what each exception actually needs.

All posts