Ask anyone who does marketplace support what question they answer most, and you will get the same answer everywhere: where is my order? It comes in a hundred phrasings. “Any news?” “It says shipped but nothing.” “The tracking hasn’t moved in four days.” “It says delivered and I don’t have it.”

It is also the question most often answered badly, because the tempting answer is reassurance (“it’s on its way, should be with you soon!”) and the correct answer is a fact you have to go and get.

What the customer actually wants

Strip the phrasing away and the customer wants four things:

Where the parcel is now, in the carrier’s own words, not yours.
When it last moved, so they can judge for themselves whether “on its way” is true.
When to expect it, if anyone knows.
A way to check without asking you again: the tracking number and a link.

A reply that contains those four is done. A reply that contains none of them and says “don’t worry” is not a reply. It is a delay with good manners.

Every fact has a source, and it is never you

This is the part that support teams under pressure skip. Each of those four facts lives in exactly one place:

Fact	Source of truth	Not a source
Current status	The carrier, via your shipping platform (Sendcloud, Packlink…) or the carrier’s own API	The marketplace’s “shipped” flag, your memory, the last email
Last event	The carrier’s tracking history	“It usually takes 3 days”
Expected date	The carrier’s estimate, when they give one	Your promise
Tracking number and link	The shipment record	Retyping it from a label

The marketplace knows the order was dispatched, because you told it so when you printed the label. It does not know the parcel has been sitting in a sorting centre since Tuesday. Only the carrier knows that. If your reply is built from the marketplace’s status, it will say “shipped” to a customer whose parcel has been returned to sender.

So the rule we work to is simple: a delivery status, date or tracking number in a reply must come from the tracking source, or it must not be in the reply. If the tool cannot reach the source, the honest answer is “we are checking with the carrier,” not a guess dressed as a fact.

The four states, and what to say in each

Carrier statuses are a zoo (Sendcloud alone normalises dozens of them), but for the customer they collapse into four situations.

Not collected yet. The label exists, the carrier has not scanned it. Say so plainly: the order is prepared and the carrier has not picked it up yet. Do not say “shipped”. If it has been more than a working day, this is your problem, not the carrier’s; check the pickup.

In transit. Give the last event and its date, the expected date if there is one, and the tracking link. This is the reply that writes itself once the facts are in hand.

Delivered. Give the delivery date and time. If the customer says they do not have it, this is the one case where the reply needs a next step rather than a fact: ask them to check with neighbours, a building reception or the pickup point named in the tracking, and tell them that if it does not turn up you will open a claim with the carrier. Do not promise a refund or a replacement in the same message. That decision depends on the claim, and a promise made now becomes an argument later.

Incident. Failed delivery attempt, wrong address, refused, returned. Tell the customer what the carrier says happened and what you are doing about it. This is the situation where a fast, factual reply prevents a chargeback.

Why an AI must not write the status

Language models are good at the shape of a reassuring reply and hopeless at knowing where a parcel is. If you let one draft “where is my order” replies from the conversation alone, it will produce fluent, confident, invented delivery dates. Customers will screenshot them.

The right division of labour is the boring one. Code fetches the facts from the tracking source. The reply is assembled from those facts: a template with the status, the last event, the date, the number and the link. A model can rephrase that into a warmer tone or translate it into the customer’s language, on the condition that the numbers and the status survive unchanged. A model should never be the thing that decides what the status is.

In Miross this is how the “where is my order” skill works. It only runs if a tracking source is connected. It reads the parcels for the order, reads the latest carrier event for each, and writes the reply from those facts. If there is no shipment for the order, it says so instead of drafting. The agent reads the result and sends it. Nothing about a parcel ever comes from a guess.

A checklist for your own replies

Whether or not you use a tool for this, a “where is my order” reply is complete when it has:

the carrier’s current status, in words the customer understands;
the date of the last event;
the expected delivery date, if the carrier gives one;
the tracking number and a link;
for “delivered but not received”: the next step, without a promise;
for incidents: what happened and what you are doing.

And it is honest when every one of those came from the carrier, and none from you.