How do you answer "where is my order?" automatically?

Where is my order. Has it shipped. When will it arrive. Why does the tracking page say nothing. If you sell anything that gets delivered, these fill your support inbox, and every one of them has the same shape: the answer exists, it's sitting in your order system or the carrier's, and a person has to go and fetch it. The customer isn't asking for judgment. They're asking for a lookup, and they're annoyed that they had to.

That is what makes this the exception to the rule we apply everywhere else in support. Most replies should be drafted by the system and checked by a person. A status answer can go straight to the customer, provided the system is reading it from the record and knows when to stop.

Why this one can run without a person

Three things make a status question safe to answer automatically. The answer is a fact in a system, not an opinion. There's no judgment to apply if the order is on track. And the volume is high enough that the agents' time matters. A question with those three properties is a lookup, and a lookup is a job for a system.

The system finds the order from the customer's email address or an order number in the message. It reads the current status from your order system and, if the order has shipped, the latest update from the carrier. It writes a reply with that detail and sends it. The whole thing happens in the time it takes the customer to close the email they just sent.

What the reply has to contain

An automatic reply earns its place only if it answers better than a person would have in a hurry. That means the detail the customer asked for, not a generic status.

• The order, named. The order number and what's in it, so the customer knows you found the right one.
• The status in plain words. Being picked, left the warehouse on Tuesday, with the carrier, out for delivery today.
• The date. The expected delivery date if there is one, and the date of the last carrier update if there isn't.
• The tracking link, if the order has shipped.
• What to do if that's wrong. One line, one step, to reach a person. The reply should say it came from your system and that a person will read any reply to it.

Keep it short and in your own voice. The customer should finish reading it knowing where their order is, and nothing else. If your team has a phrase they always use for a parcel that's with the carrier, use that phrase, so the automatic reply reads like the ones your agents send.

A worked example

A customer writes at half past eight on a Monday: ordered this last week, any news? No order number, written from their usual address. The system finds one open order on that address, sees it left the warehouse on Friday and that the carrier scanned it at a depot on Sunday night. The reply goes back within the minute: the order number and what's in it, that it's with the carrier, the depot scan and when it happened, the expected delivery day, the tracking link, and one line saying a person will read any reply. The customer closes the email and gets on with their morning.

The same customer writes again on Thursday because the parcel hasn't come. Now the expected day has passed and the carrier's last scan is three days old. The system does not answer. It puts the message, the order and the carrier history in front of an agent, who picks it up with everything already open and writes to the customer about what happens next. Two messages from the same customer, two different handlings, and both were right.

What goes to an agent

The system's most important job is knowing when not to answer. These go to a person, with the order and the customer's message attached, and no automatic reply:

• No match. The email address isn't on an order and there's no order number in the message.
• More than one match. The customer has several open orders and didn't say which.
• A late or stuck order. Past the expected date, no carrier update for days, a failed delivery, a return in progress. The customer needs a person and probably an apology.
• Anything beyond status. A change of address, a cancellation, a complaint, a question about a refund. These are requests, not lookups.
• A tone that says the customer is already upset. The message should reach a person first, even if the status is fine.

The agent sees the order, the carrier history and the message in one place, and starts from there. This is the same handoff we describe in how to triage support requests automatically: the system sorts and attaches, and a person decides.

Before they ask

Once the system is reading order status, it can tell the customer about a change before they notice it. When an order's expected date moves, or a carrier reports a problem, the customer gets a message saying so and what happens next. Each of those messages is a status question that never gets asked, and it's the difference between a customer who feels looked after and one who feels they had to chase.

Keep these to changes that matter: shipped, delayed, failed delivery, delivered. A message for every scan is noise, and the customer stops reading. Anything that needs an apology or a decision, such as a lost parcel, goes through an agent rather than out as a notification.

Connecting the systems

This needs three things to be readable: the inbox or form where questions arrive, the order system that holds the status, and the carrier's tracking. Most order systems and carriers have a way to be read; we check before proposing anything. If orders live in a spreadsheet, that's the thing to fix first, and it's usually a small fix compared with the questions it will stop.

What to measure

Take the readings from a normal week before anything changes. Time to resolve a customer request and requests handled without escalation are two of the four on Customer Experience, and this is the fastest way to move both. Add the share of status questions answered without an agent, and watch the repeat questions: if customers write back after the automatic reply, the reply is missing something.

What to do this week

1. Count the status questions in last week's inbox, and what share of all requests they were.
2. Read twenty of them and write down what each customer wanted to know. That's the reply template.
3. List the cases that should go to a person, starting with late orders and no match.
4. Check how your order system and carrier can be read.
5. Take the readings: time to resolve and requests handled without escalation.

If you bring last week's count to a call, we'll tell you what the first version would answer, what it would hand to an agent, and what you'd see in the inbox a month later. How this fits with the rest of the support work is covered in how to use AI in support without annoying customers.