Skip to content
allanninal.dev/build
Collaborate

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

How the customer gets told

The message is short, factual, and contains one thing most delivery updates do not: an admission that the next date is not known. That single omission is what makes it trustworthy.

Key takeaways

  • Contacting first turns an angry inbound into a neutral outbound.
  • Say what happened, what you are doing, and when you will next say something.
  • Never state a delivery date that is not a fact. “We do not know yet” is acceptable.
  • Follow up only when something changed, and always at the time you said.
  • Do not contact for exceptions that will resolve before the message is read.

The message

The whole thing, four lines

  • What happened: “Your parcel has not moved since Saturday. That usually means it has been mis-sorted somewhere in the network.”
  • What we are doing: “We have asked the carrier to locate it, which they aim to do within two working days.”
  • What we do not know: “We cannot give you a delivery date until they come back to us.”
  • When you will hear: “I will email you on Thursday either way, even if there is no news.”
  • Signed by a person, with a reply-to that reaches them.
  • No apology paragraph, no discount, no unprompted compensation. Those come later if it is warranted.

The third line is the one that feels wrong to write and is the reason the message works. Every customer has received a delivery update containing a confident new date that then passed with nothing arriving, and the effect of that is considerably worse than uncertainty stated plainly.

The date you must not invent

The pressure to give a date comes from wanting to be helpful, and from support systems with a field labelled “new expected delivery”. Filling that field with an estimate converts a manageable problem into a broken promise the moment it slips, which for a genuinely lost parcel is most of the time.

The honest alternative costs nothing: name the carrier’s own service level for the trace, and commit to a communication date rather than a delivery date. “I will tell you on Thursday” is a promise you control entirely.

When not to contact

The three checks before proactively contacting a customer about a deliveryA vertical chain of five steps entered by a box labelled An exception, triaged and needing action. Step one asks whether it will resolve today, as with a first attempt or a parcel held for pickup; if so it exits to Do not contact, because the carrier already did. Step two asks whether the carrier notifies the customer, which most do for attempts; if so it exits to Do not duplicate, because two messages is worse than one. Step three asks whether we know something they cannot see; if not it exits to Wait until we do, since it would be a message with no content. Step four contacts them once, with the four lines. Step five follows up when promised, even with no news. A note says three gates fire before contacting, and a message that adds nothing costs trust.AWS ACCOUNTAn exception, triagedneeds actionWill it resolve today?first attempt, held for pickupDo not contactthe carrier already didyesDoes the carrier notify?most do, for attemptsDo not duplicatetwo messages is worse than oneyesDo we know somethingthey cannot see?Wait until we doa message with no contentnoContact themonce, with the four linesFollow up when promisedeven with no newsThree gates before contacting. A message that adds nothing costs trust.
Fig 1. When proactive contact helps and when it does not. The third gate is the one that keeps the message meaningful.
  • App integration
  • Machine learning
  • Security & identity
  • Management

The follow-up with no news

This is the step that is always cut and is the one customers remember. An email on Thursday saying the carrier has not come back yet, we have chased them, and we will write again on Monday, is more reassuring than silence followed by good news.

It is also cheap, because the system already knows what was promised and to whom. The reason it gets cut is that it feels like admitting failure, which it is, and the alternative is a customer who assumes they have been forgotten, which they have.

What this does to support volume

Inbound versus outbound delivery contacts under reactive and proactive handlingA stacked bar chart with two bars. Two series: the customer contacting us annoyed in red, and us contacting first in a neutral tone in green. Reactive handling produces eighty-four inbound contacts and no outbound. Proactive handling produces nineteen inbound and sixty-one outbound. A note says these are roughly the same conversations with a very different starting temperature.0255075100~84Reactive~80ProactiveCustomer contacts us, annoyedWe contact first, neutralRoughly the same conversations. Very different starting temperature.
Fig 2. A quarter of delivery exceptions handled two ways. The total volume barely moves; what changes is who started the conversation and in what mood.

The honest reading of that chart is that proactive contact does not reduce the work by much. What it changes is that the work happens on your schedule, with information already gathered, in a conversation that starts neutral rather than at a complaint.

It also moves the work earlier, which for the genuinely lost parcels means the trace is raised while the carrier can still find it, rather than eight days later when the answer is a write-off.

Next: what the exceptions reveal.

All posts