allanninal.dev/build

Part 5 of 7 · Order status responder series ~7 min read

How a stuck order gets escalated

The responder is judged less by the easy replies it sends than by the hard ones it knows to hand over. This post is about the escalation lane: which enquiries never get an automatic answer, how a person receives them with the message, the matched order, and the raw tracking attached, and the daily sweep that catches orders going quiet before the customer has to chase.

Key takeaways

  • Five things never get an automatic reply: no match, an ambiguous match, an upset customer, a carrier exception, and a no-movement parcel.
  • An escalation is a single email to your support address with the message, the matched order, and the raw tracking attached.
  • A daily EventBridge sweep re-checks in-flight orders and escalates the ones going quiet before the customer has to chase.
  • The responder can flag, attach, and explain — it never refunds, reships, or cancels. A person decides every one of those.
  • Escalations are de-duplicated, so one stuck order raises one ticket, not a new one every time it’s asked about.

What never gets an automatic reply

A responder is only as trustworthy as the things it refuses to answer. The whole point of the automatic reply is the easy 80% — “is it coming?”, “yes, Thursday” — and the whole point of escalation is to pull the other 20% out cleanly, before a thin or wrong reply makes a small problem worse. Five cases route straight to a person and never get an automatic answer:

  • No match. The matcher couldn’t tie the message to any order — no number in the text and no order under that email or phone. A person can spot in seconds that it’s a new customer, a typo, or an order placed under a different address.
  • Ambiguous match. The sender has several open orders and the message doesn’t say which. Rather than answer about the wrong parcel, the responder hands over all the candidates and lets a person ask the obvious clarifying question.
  • Upset customer. The message reads as a complaint — frustration, “ridiculous”, “cancel”, “refund”, a third chase. Even with a clean status to report, a curt tracking line is the wrong response; a human picks these up.
  • Carrier exception. The tracking came back as an exception — failed delivery, held parcel, address problem, return to sender. There’s a real status, but it’s one that needs a decision, not a quote.
  • No movement. The carrier has no scan, or no scan in days. The parcel may be lost. Telling the customer “it’s on its way” would be a lie, so it goes to a person to chase the carrier.

The first two come from the matcher (Part 2); the last two come from the tracking lookup (Part 3); the upset-customer case is a light tone check on the message text, deliberately tuned to over-escalate rather than risk answering a complaint with a status code.

What an escalation looks like

An escalation isn’t a vague alert — it’s everything a person needs to act, in one place. The escalator Lambda sends a single email to your support address (or drops a row into a shared inbox) carrying: the original message and the channel it came on, the order the system matched it to (if any), the raw and normalised carrier tracking, and a one-line reason it was escalated. The support person opens it and has the full picture without looking anything up — they can reply to the customer, call the carrier, or start a refund, all from the same screen.

What the escalator deliberately can’t do is act. It writes no refund, books no reship, cancels no order, sends no apology on its own. Those are decisions with money and goodwill attached, and the system’s job is to put them in front of a person with the context to make them — not to make them itself. This is the same guardrail as the rest of the system, drawn at the riskiest edge: the responder proposes and informs; a human decides.

The escalation lane: five triggers and a daily sweep funnel into one de-duplicated, context-rich handover to a person On the left, five small trigger boxes stacked vertically: No match, Ambiguous match, Upset customer, Carrier exception, and No movement. Each has an arrow into a central box “Escalator”. Below them, a sixth box “Daily sweep” on an EventBridge schedule re-checks in-flight orders and also feeds the Escalator with orders going quiet. The Escalator first passes through a decision “Already raised for this order?” — if yes, an arrow goes to “Attach to existing, no new ticket”; if no, an arrow goes to “Build handover: message + order + raw tracking + reason”, which sends a single email to a box on the right “Support inbox — a person decides”. A panel lists what the escalator cannot do: no refund, no reship, no cancel, no auto-apology. A dotted AWS account container surrounds the triggers, sweep, and escalator; the support inbox sits outside. A note reads: the responder flags, attaches, and explains — a person decides what happens next. AWS account No match Ambiguous match Upset customer Carrier exception No movement Daily sweep EventBridge Escalator one handover Already raised for this order? attach to existing, no new ticket yes Build handover message + order + raw tracking + reason no cannot: refund, reship, cancel, auto-apology Support inbox a person decides email The responder flags, attaches, and explains — it never refunds, reships, or cancels. A person decides what happens next.
Fig 5. Five triggers and a daily sweep funnel into the escalator. It de-duplicates by order, builds one context-rich handover, and emails it to support. It cannot refund, reship, or cancel — a person decides.

The sweep, and not crying wolf

Two details stop the escalation lane from being either too quiet or too noisy. The first is a daily sweep. Customers shouldn’t have to be the ones who notice a parcel went quiet. An EventBridge Scheduler rule fires the osr-sweep Lambda once a day; it walks the in-flight orders, re-checks the carrier on any that haven’t moved, and escalates the ones stuck past a threshold from your settings doc — say, no scan in five days. That turns a future angry “where is it?!” into a quiet “we noticed this one’s stuck” that your team can get ahead of.

The second is de-duplication. A genuinely stuck order tends to get asked about repeatedly, and the sweep will keep finding it. The escalator keeps an open-escalation record per order, so the first trigger raises one ticket and every later signal about the same order attaches to it rather than spawning a new one. Your support person sees one thread for one problem — the customer’s three chases and the sweep’s daily nudge all gathered together — not an inbox full of duplicates that trains them to ignore the lot.

Design rules that shaped escalation

  • Five clear triggers. No match, ambiguous, upset, exception, no movement — each never gets an automatic reply.
  • Hand over the whole picture. Message, matched order, and raw tracking in one place, so a person acts without looking anything up.
  • Over-escalate tone. A possible complaint goes to a human even when there’s a clean status to report.
  • Notice it first. A daily sweep catches stuck orders before the customer has to chase.
  • One problem, one ticket. De-duplicate by order so the team isn’t buried in repeats.
  • Flag, never act. No refunds, reships, or cancellations — those are always a person’s call.
All posts