Playbooks · 5 min read
Order Tracking Messages Can Only Say What You Recorded
"Where is my order" is the most-asked question in Indian retail, it arrives at every hour, and answering it is repetitive work that a machine does better than a tired human at 11pm. If there is one obviously good automation for this channel, this is it.
It is also where businesses reach past what they know, because the customer is asking a question about the future and the system only holds facts about the past.
Three kinds of fact, and only one of them is yours
Sort everything you might put in a status message into these three buckets before you write a single template.
Facts your system authored. The order was placed. Payment was captured by your gateway. It was packed. It was handed to a courier and here is the tracking number. Your database wrote these rows itself, it knows exactly when, and it can be held to them.
Facts you received from somebody else. Every courier scan. "Reached Bhiwandi hub" is an observation the courier made at a time, transmitted to you at another time, and true as of neither of those unless you say which. It is not a live location.
Facts nobody has. When the parcel will arrive. Whether the delivery agent will call. Whether the address will be found. These are predictions produced by a network of vans and people, and no system in the chain holds them as data.
Automate the first bucket freely. Report the second bucket as a quotation with its timestamp. Never let a template touch the third.
A courier scan is a photograph of where a parcel was. Sending it as if it were a live tracker is the whole mistake in one sentence.
The timestamp rule
Attach two things to every status a customer receives: what the status is, and when it was recorded.
"Dispatched" tells somebody nothing. "Dispatched on 14 August, last courier scan 15 August at 6:40pm, Bhiwandi" tells them what you actually hold, and it does something more useful than reassurance — it lets the customer judge for themselves. Somebody who can see the last scan was two days ago knows to worry without being told to, and knows to ask a human. That is a better outcome than an automated message that hides staleness behind a confident word.
What never goes in a template
A delivery date. Not "arriving Thursday", not "expected in 2-3 days", not "aaj shaam tak". If the courier's own tracking page publishes an estimate, link to the page and let the courier own its own prediction. Do not restate it in your voice, because in your voice it becomes your promise.
"Out for delivery" from a stale scan. This one is specific and it is worth guarding against. If the last event you hold is more than a day old, the correct behaviour is to stop reporting status and route the conversation to a person. An automation that keeps saying "in transit" about a parcel that has not moved since Tuesday is generating false comfort, which converts directly into anger later.
Anything about a payment that already left the customer's account. That is a different problem with a different risk profile and it deserves its own read.
An offer stapled to the end. "Your order has shipped — here is a coupon for the next one" is two messages pretending to be one. The status half is about a transaction the customer entered into; the offer half is a promotion. Adding it changes what the message is, which changes the category and the consent it needs, and it also cheapens the one message the customer actually wanted.
The design that survives contact with reality
- List the statuses you actually write. Most stores have five or six. If your system has never written "delayed" as a state, you cannot message about it.
- Write one template per status, with variables that are facts: order id, tracking number, last scan, last scan time.
- Add a staleness rule. Beyond a threshold you choose, the automation stops answering and hands over.
- Give the tracking link, not the prediction. One link, to the courier's page.
- Route anything that is not a status question to a person. "Where is my order" is automatable. "The box was open" is not.
- Log every send. When a customer says they were told something, you want the record rather than a guess.
The messages that look like tracking and are not
Three arrive constantly and none of them is a status lookup.
The photograph. Somebody sends a picture of a torn carton with no text. Nothing reads images on any channel, so there is nothing for a rule to match on and nothing for a model to answer. It needs a person.
The complaint dressed as a question. "Where is my order, 6 days ho gaye" is not asking for a scan. It is asking whether anybody cares.
The wrong-address correction. Time-critical, requires action in another system, and an automated acknowledgement that goes nowhere is worse than no reply.
Where this stands today
PostEngage answers Instagram comments and DMs. There is no WhatsApp in the product, and no order data flows into it from anywhere — no Shopify connection, no courier feed, no webhook. Nothing in it can look up a shipment on any channel.
For the fuller picture of what governs this channel in India, start here. For the support queue that all of this sits inside, the inbox post is the companion.
