Answering "where is my order" without a human
Where is my order is the most answerable question in retail support and the most expensive to answer by hand. It arrives constantly, the answer is already in two systems, and a person reading tracking numbers aloud is doing work that has nothing to do with judgement.
5 min read
What the agent needs, in order
- Identify the order. From the order number if given, otherwise from the sender's address via
lookup_contactand your order system. A customer who wrote from the address they ordered with should never be asked for a number you can find. - Read the thread.
get_thread, because "still nothing" is the third message in a conversation, and answering it in isolation produces the reply that makes people angry. - Fetch current state. Your order system for what was bought and when, the carrier for where it is now. Both, not one: order data alone cannot say a parcel is stuck in a depot.
- Answer with the specific fact. A date, a location, a next step. Not "your order is on its way".
The whole job hangs on step three being live rather than remembered. A cached status from yesterday is how an agent tells someone their parcel is in transit six hours after it was delivered to a neighbour.
The five real cases
| Situation | What to say | Who owns it |
|---|---|---|
| In transit, on time | Where it is and the expected date | Agent |
| In transit, late but moving | Where it is, honestly, and when to worry | Agent |
| Stuck or no scan for days | Say so plainly, offer the remedy your policy allows | Agent, then a person if the remedy is money |
| Marked delivered, not received | Check-with-neighbours guidance once, then escalate | Person |
| Lost, damaged, or wrong item | Acknowledge, do not adjudicate | Person |
The last two are not order status questions wearing a disguise, they are refund conversations, and an agent that treats them as tracking lookups makes an unhappy customer angrier. Route them out, per the escalation triggers in the system prompt.
Write like a person who checked
The difference between a useful reply and an irritating one is specificity, and the specificity is free because you just fetched it.
reply_all {
message_id: "msg_...",
body: "Your order 4012 left the Rotterdam depot on Tuesday and is out for delivery today.\n\nIf it has not arrived by tomorrow evening, reply here and I will open a claim with the carrier."
}Three things happening: the fact, the timeframe, and the next step with a trigger the customer can act on. That last line also does something useful for you, which is that it converts a vague follow-up into a specific one that arrives at the right time.
When both parties in a dispute are your customers, the shape changes again, per support when both people emailing you are your customers.
Where the volume actually goes
Two adjacent categories come with WISMO and are worth handling in the same agent, because they use the same data.
Delivery changes. "Can you send it to my work address instead." Answerable from carrier capabilities and your own cutoff rules. Often yes before dispatch and no after, and saying which honestly is most of the value.
Returns questions. Where to send it, whether the label is included, how long the refund takes. All documentation answers, all high volume, and none of them require judgement until an amount is disputed.
Both live comfortably next to order status. What does not belong is anything with a discount, a goodwill gesture, or a promise about compensation, which is a person's decision backed by a tool that refuses, per keeping an autonomous agent from becoming a spam problem.
Peak season is the test
Retail email is seasonal in a way that breaks naive setups. Volume that quadruples for six weeks means bursts, and bursts mean the concurrency work in what happens when forty messages arrive at once stops being theoretical: per-thread serialisation, an idempotency check, and a cap on concurrent sends.
It also means the carrier APIs you depend on are having their worst month. Decide in advance what the agent says when tracking data is unavailable, because "I could not check" answered quickly is much better than a run that hangs waiting on a timeout.
What to measure
Deflection is tempting here because the volume is huge, and it is still the wrong primary metric. Watch reopen rate, which catches the confident wrong answer, and correction rate, which catches the promise the carrier never made. Both are defined in evaluating an email agent.
One retail-specific number is worth adding: the share of threads that turned into a refund or replacement after the agent answered. If that climbs, the agent is reassuring people whose parcels are actually lost, which is worse than not answering at all.
Questions
- Can an AI agent answer order status emails?
- Yes, and it is the strongest starting use case in retail: high volume, low variety, and the answer already exists in your order system and the carrier's tracking data.
- What should it never do?
- Adjudicate a lost, damaged, or wrong-item claim, promise a delivery date the carrier has not committed to, or offer compensation. Those go to a person.
- How does it find the order?
- From the order number when given, otherwise by looking up the sender's address in the contact record and your order system. Asking for a number you can already find is the most common irritation.
- What about "marked delivered but not received"?
- One message with the standard check-with-neighbours guidance, then a person. It is a refund conversation, not a tracking question.
- Does it need live carrier data?
- Yes. A cached status is how an agent tells someone their parcel is in transit hours after it was delivered. Fetch at answer time, and decide in advance what to say when the carrier API is down.
- How does it cope with peak season?
- The same way any bursty agent does: per-thread serialisation, idempotency on the message id, and a cap on concurrent sends, decided before November rather than during it.
Give your agent an address it can answer from.
Create an inbox