"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.
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:
- Shipped. "Your order shipped on [date]. Tracking: [number]. The latest scan is [event], in [city]." Nothing invented, everything quoted.
- 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.
- 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.
[!TIP]
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
| Query | Automate or escalate | Why |
|---|---|---|
| Order shipped, tracking, latest scan | Automate | Pure lookup; the data exists |
| Processing time before dispatch | Automate | One line in the facts file |
| Carrier delay, recent scan | Automate, status only | Quote the carrier verbatim; never predict |
| Scan older than the threshold | Automate the report, then escalate | Delayed parcels need a human decision |
| Marked delivered but not received | Escalate after the first scripted reply | Lost-package decisions cost money |
| Damaged on arrival, wrong or missing item | Escalate | Photos, replacement-vs-refund is judgement |
| Address change after dispatch | Escalate | Usually impossible; occasionally fraud |
| Refund, chargeback, or dispute | Escalate, always | Commercial decision the agent has no authority to make |
| Angry customer, second contact on same issue | Escalate | Emotion 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
- 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.
- Letting the agent estimate delivery dates. An invented ETA converts a status query into an apology, twice. Quote the scan; defer the prediction.
- 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).
- 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
- 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.
- 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.
- Add the identity rule — order number plus email — before the agent sees a single real customer.
- Set the scan-age threshold and write it into [RULES] as a number, not a vibe.
- 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.
This guide lives at AgentFast, where you'll also find a free audit tool that checks your own agent's instructions against these failure modes. Posted here with a canonical URL pointing at the original.
