Delivery exception handler
A small system that watches outbound deliveries, works out which ones have genuinely gone wrong, decides which of those need somebody to act today, and tells the customer only what is actually known. The most useful signal in the whole system is a shipment that has not been scanned for four days, and no status code says that. Seven posts on the same system, one diagram at a time, with a cost breakdown and an engineering reference at the end.
- 01
A delivery exception handler on AWS for a few dollars a month
The whole system on one page — detect, triage, tell — and why the absence of a tracking event beats every exception code the carrier provides.
- 02
How an exception is detected
How carrier statuses are normalised, why the gap between scans is measured per service, how the silence threshold is derived, and the shipment that never got a first scan.
- 03
What each exception actually needs
How exceptions are sorted by what they need, which categories self-resolve, the ones that need action within the hour, and why the queue must stay short.
- 04
How the customer gets told
Why contacting first changes the interaction, the wording that works, why an invented delivery date is the worst possible move, and when not to contact at all.
- 05
What the exceptions reveal
How exceptions aggregate by cause, why address quality is the largest fixable category, the depot finding, and separating internal failures from carrier ones.
- 06
What the delivery exception handler costs
About $7 a month. One Bedrock read per shipment is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the delivery exception handler architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.
Frequently asked questions
- What is a delivery exception handler?
- A small serverless system that monitors outbound shipments, detects the ones that have gone wrong, triages them by what they actually need, and contacts the customer with what is known rather than what is hoped.
- Why not just watch the carrier’s exception statuses?
- Because they are unreliable in specific directions. An attempted delivery status is sometimes a driver who ran out of time, and a shipment genuinely lost in a depot usually carries no exception status at all.
- What is the strongest signal that something is wrong?
- Silence. A shipment with no scan for several days is the most reliable indicator of a real problem, and it is the one no carrier reports.
- Should you contact customers proactively?
- Yes, for the exceptions that will not resolve themselves, and with a specific caveat: never give a new delivery date you do not have. The post on this covers why.
- What does it cost to run?
- A couple of dollars a month. See part six.