AAgentFast
Ecommerce

Order status is the first query to automate, and the safest

"Where is my order" is the highest-volume, lowest-risk question a small shop gets. Here is what a WISMO agent needs, the three answers that cover most of it, and when to escalate.

2026-10-138 min readAgentFast

A nine-person store selling kitchenware pulled its support inbox for me last month: 640 tickets over four weeks, and by my count 390 of them were some version of "where is my order." Two people spent most of every working day answering them by opening the order system, opening the carrier's site, and copying the same three facts back to the customer.

That ratio is not unusual. In the small shops I've worked with, WISMO — where is my order — plus its cousins "where is my refund" and "has it shipped" routinely makes up half or more of inbound tickets. It is also the safest high-volume query to automate, for one structural reason: the answer already exists in a system. There is no judgement in "shipped Tuesday, tracking link here, latest scan is Memphis." An agent that reads that data back accurately is indistinguishable from a person who does, except faster and at 3am.

But the same structural property cuts the other way: an agent that guesses at order data produces confident nonsense, and a customer holding a tracking number will find out. So the whole design hangs on what the agent can see, what it may say, and where it stops.

What the agent needs access to

Keep the read scope deliberately small. For each order, the agent needs:

  • Order number, status (received, processing, shipped, delivered), and the date of each state change
  • Ship date, carrier, and tracking number
  • The latest carrier scan event, verbatim
  • The promised dispatch window and the backorder date if flagged

And it needs one lookup rule: an order is only revealed when both the order number and the email on the order match. Order numbers get forwarded, screenshotted and half-remembered; matching on the number alone hands a stranger's order details to whoever types it in.

What it must never see or touch:

  • Full card data. A properly run store doesn't hold it anyway — payments are tokenized. If your agent's data feed includes card numbers, the integration is wrong, not the prompt. Last four digits at most, and only if your flows require confirming a card.
  • Other customers' orders. The identity rule above is what prevents this, but the access list should enforce it too.
  • Internal notes and margin data. Warehouse notes contain things you'd never say to a customer, and cost data is a leak waiting for a prompt-injection test.

The three answers that cover most of it

Nearly all WISMO volume collapses into three responses:

  1. Shipped. "Your order shipped on [date]. Tracking: [number]. The latest scan is [event], in [city]." Nothing invented, everything quoted.
  2. Not shipped yet. "We received your order on [date]. Orders leave our warehouse within [X] business days, so yours is due to ship by [date]." One facts-file line covers every instance.
  3. Delivered, allegedly. "The carrier marked this delivered on [date] at [location]. If it hasn't reached you, I'll hand this to the team to sort out." This is the one that ends in escalation, and the agent should escalate immediately rather than argue with the customer about whether their doorstep exists.

Everything else — changed address, damaged box, refund — is a different query, and the table below keeps it that way.

Carrier delays without inventing dates

The most damaging sentence a WISMO agent can produce is a new estimated delivery date. The carrier's own system doesn't promise one after a delay; your agent must not either. The rule is simple: quote the carrier's latest scan in the carrier's words, and if the scan is stale or shows an exception, say exactly that and hand over.

Set a scan-age threshold — for domestic parcels, more than five business days since the last scan is where I draw the line. Before the threshold, the agent reports status. Past it, the agent says "this looks delayed" and offers the human queue, no matter how confident the carrier's own ETA widget looks.

This keeps the agent honest on the one question where a made-up answer costs twice: once when the invented date passes, and again when you have to explain why it was invented.

Automate or escalate: the line

QueryAutomate or escalateWhy
Order shipped, tracking, latest scanAutomatePure lookup; the data exists
Processing time before dispatchAutomateOne line in the facts file
Carrier delay, recent scanAutomate, status onlyQuote the carrier verbatim; never predict
Scan older than the thresholdAutomate the report, then escalateDelayed parcels need a human decision
Marked delivered but not receivedEscalate after the first scripted replyLost-package decisions cost money
Damaged on arrival, wrong or missing itemEscalatePhotos, replacement-vs-refund is judgement
Address change after dispatchEscalateUsually impossible; occasionally fraud
Refund, chargeback, or disputeEscalate, alwaysCommercial decision the agent has no authority to make
Angry customer, second contact on same issueEscalateEmotion plus history needs a person

Notice that "automate" here never means "decide." It means read the system and report accurately. The decisions stay on the human side of the table.

A facts file for order status

[FACTS]
Dispatch window: orders leave the warehouse within 2 business days.
Carriers: national postal service and one express courier.
Tracking: every shipped order gets a tracking link by email.
Typical transit after dispatch: 3-5 business days domestic.
Backorders: the promised date is shown on the order; quote it exactly.

[RULES]
Give order details only when BOTH the order number and the order
email match. If either is missing, ask for both before anything else.
Quote the latest carrier scan exactly as shown. Never estimate a
new delivery date and never restate the carrier's ETA as a promise.
If the last scan is more than 5 business days old, say the parcel
looks delayed and offer the human queue.
Never read out or accept full card numbers.

[ESCALATE IF]
Parcel marked delivered but reported missing.
Customer reports damage, a wrong item, or a missing item.
Customer asks for a refund, mentions a chargeback, or wants an
address change after dispatch.
Customer is angry or says this is not the first contact.

The [RULES] block is where the two classic WISMO failures die: data leaks (the identity rule) and invented ETAs (the quote-the-scan rule). Neither needs a smarter model. Both need sentences.

The four mistakes I see most

  1. No identity check on order lookup. Order numbers are not secrets. Match number plus email from the first message, and ask for both cheerfully — "so I can pull that up securely" is all the explanation customers need.
  2. Letting the agent estimate delivery dates. An invented ETA converts a status query into an apology, twice. Quote the scan; defer the prediction.
  3. Automating the exception paths first. Damaged-goods handling is loud and emotionally urgent, which is exactly why teams reach for it first. It's also judgement work. Automate the volume (status), staff the exceptions (judgement).
  4. Measuring tickets closed. Deflection looks great while repeat contacts climb, because the agent answered the words without resolving the problem. Track repeat contacts on the same order for thirty days after launch; that number is the honest one.

What to do today

  1. Count your last four weeks of tickets and work out the WISMO share. It sets your expectations for what this is worth — and it's usually bigger than anyone guesses.
  2. Write the three answers in your store's words and check every claim in them traces to a real field in your order or carrier system.
  3. Add the identity rule — order number plus email — before the agent sees a single real customer.
  4. Set the scan-age threshold and write it into [RULES] as a number, not a vibe.
  5. Run five test orders through the agent, including one marked delivered-but-missing, and confirm the escalation fires.

Order status is the rare automation that is high-volume, low-risk and boring in the best way: the answer exists, the customer just needs it read back accurately. Scope the data tightly, forbid the invented date, keep the judgement with a human — and the biggest queue in your inbox stops being a queue.

Automate the one query every customer asks.

The order-status facts file with the identity rule and escalation list is in our store as a fill-in pack. The guide above is complete without it.

See the 20-Ticket Support Playbook →

Keep reading