Skip to main content

Evoriqa is live. Start free

E-commerce

How stores cut ‘where is my order?’ tickets

Evoriqa Team · June 20, 2026 · 5 min read

How stores cut ‘where is my order?’ tickets

Open any store's support queue and the same request repeats: where is my order. It arrives at every hour, it reads the same way each time, and the count grows with every order you ship. A person can answer it, but answering it is mechanical work: find the order, read the current status, reply. That is the kind of task an AI agent can take off the queue, as long as it has the right inputs and a clear rule for when to stop and hand the conversation to a human.

This is a narrow guide. It covers order-status requests and nothing else. Returns, sizing, pre-sale questions, and catalog help are a wider job. For those, see what an ecommerce support agent covers end to end. Here the work is one question, answered well, over and over, which is also the ticket type that most rewards taking repetitive requests off the queue.

What the agent needs to answer one request

To resolve a single "where is my order" request, the agent needs three things.

First, something to look the order up by. That is usually the order number, or the email address used at checkout. Either one is enough to find the record. Without one of them, there is nothing to search against, and the agent has to ask for it before it can do anything useful.

Second, a lookup against your systems. The agent does not infer a status from the conversation or guess from the order date. It runs an agentic action (a call to your order or commerce platform) and reads back the current state of that order: paid, packed, shipped, out for delivery, or delivered. If you run on Shopify, the Shopify order lookup reads that status straight from the store, so the reply reflects what the store shows right now rather than a stale copy.

Third, a record of the run. Every lookup the agent performs is logged: which order was queried, what the action returned, and what the customer was told. When a shopper later disputes what they were promised, the log is the answer instead of a memory, and you can audit any conversation after the fact.

Setting up the lookup

The setup is a mapping job. You connect the store, then teach the agent that a "where is my order" question maps to one action: take the order number or email, call the platform, and read the status field back. The agent fills the reply from what the action returns: the order state, the carrier, the tracking number, and the tracking link if the platform has one.

Two rules keep the answers safe. The agent only states what the lookup returned, so it does not round "shipped" up to "arriving today." And when the lookup finds nothing, it says so plainly rather than inventing a status. A grounded "I couldn't find an order under that number — can you check the confirmation email?" is a better reply than a confident wrong one.

When the customer can't find their order number

A good share of these requests start without a number, because the shopper is writing from their phone and the confirmation email is buried. Plan for it.

The first fallback is the email address used at checkout. Ask for it directly: "What's the email you used when you ordered?" Most order platforms can find a recent order by email, which gets you back on the main path. If the store allows guest checkout, the email is often the only handle you have, so it is worth asking for early.

If the email returns more than one order, have the agent confirm which one the customer means before it reads a status. The date or the item name is usually enough to disambiguate. If neither the number nor the email finds anything, do not keep guessing. That is the point to stop and involve a person, who can search by name, last four digits of the card, or shipping address in a way the agent should not.

When tracking has not updated yet

The most common follow-up is "it says shipped but the tracking hasn't moved." Usually nothing is wrong. Carriers scan a parcel into their network on a delay, and a label can exist for a day or two before the first scan appears. The agent's job here is to set the expectation without promising a date it cannot know.

Say what is true: the order has shipped, here is the tracking number and link, and the carrier's first scan can take a little time to show up. If your fulfillment has a normal window — for example, a scan usually appears within a day or two of dispatch — the agent can share that window as a guide, because it describes your process rather than predicting the carrier's. What it should not do is name a delivery day. Only the carrier owns that, and a promised date the parcel misses turns one ticket into two.

If the tracking still shows no movement well past your normal window, that is no longer a reassurance reply. It is a possible lost or stuck parcel, and it should go to a person.

When to escalate

Automating the common case only works if the uncommon case has a clean exit. Give the agent a short, explicit list of situations where it stops answering and hands off with the full order and conversation attached, so the person picks up in context instead of asking the customer to repeat everything. Escalate when:

  • The order can't be found by number or email after the customer has supplied both.
  • Tracking has stalled well beyond your normal window, or the carrier marks it lost or

delayed.

  • The customer reports the package as delivered but missing, or arrived damaged.
  • Someone asks to change the shipping address, cancel, or reroute an order that has already

been dispatched.

  • The message carries a refund demand, a chargeback threat, or clear frustration. A human

should own the reply.

Handing off cleanly is its own capability. The agent passes the thread, the order it looked up, and what it already told the customer, so the handoff to a person starts from the full picture rather than a cold transcript.

Keep the answers grounded

The whole approach rests on the agent reading real data and admitting when it has none. It answers from the status your platform returns, it says it doesn't know instead of guessing, and it logs every lookup so you keep an audit trail of what was asked and answered. That is what makes it safe to let it handle the volume: the boring, repeatable part runs on its own, and the cases that need judgment reach a person early, with everything they need to act.

If you want order-status lookups running against your own store and your own order data, create a free workspace and connect it today.

Build this on your own content, free

Point Evoriqa at your website and help docs, and your agent starts answering questions, capturing leads and booking appointments across every channel. Free to start, no credit card.