“Where is my order?” is the largest single ticket category for most Indian D2C brands. In many support inboxes it beats refund status queries, address changes and product questions put together. And it is a strange category, because a WISMO ticket is not really a request for help. It is a request for information the company already has. The parcel’s last scan is sitting in the courier portal. The customer cannot see it in a form they understand, so they ask. They ask on WhatsApp, on email, on Instagram comments and on the phone, sometimes on all four for the same order.
Consider a mid-size brand shipping 4,000 parcels a day across Delhivery, Xpressbees and Ekart. If a third of its 300 daily tickets are WISMO, that is a hundred tickets a day asking the same question. At 6-10 minutes per ticket (find the order, open the courier portal, read the scan history, translate it into plain language, reply), that is 10-16 agent hours a day spent reading tracking pages out loud. During the festive season, when parcel volume doubles and courier delays stretch, the same question arrives twice as often and takes longer to answer because the scan history is messier.
Why the customer asks at all
Nobody raises a “where is my order” ticket when tracking is clear and the parcel is on time. The ticket arrives when the tracking page has said “in transit” for four days, when the promised date has passed, or when the last scan is a hub the customer has never heard of. The tracking link sent at dispatch is technically an answer. In practice it is a question with extra steps, because courier status codes are written for operations teams, not for someone waiting for a birthday gift in Coimbatore.
There is an anxiety layer on top of the logistics. A large share of Indian e-commerce is still cash on delivery. The customer has committed to paying ₹1,500 or more at the door, and the parcel appears to have vanished. Silence from the brand reads as indifference. By the time the ticket is raised, the customer is not only asking for information. They are checking whether the brand is trustworthy. How the next thirty minutes go helps decide whether that parcel is accepted or refused at the door, and a refused COD parcel is an RTO at ₹150-₹250 before the lost sale itself.
What one WISMO ticket actually costs
Break a single ticket open and the cost has four layers. The first is agent time: the 6-10 minutes of portal-hopping described above, multiplied by a hundred tickets a day. The second is repeat contact. A vague first reply (“your order is in transit, please wait”) does not close the ticket; it schedules the next one for two days later, and the follow-up ticket takes as long as the first.
The third layer is escalation. An unanswered WISMO thread hardens into a complaint, a public comment, or a demand for a refund on an order that is actually two days from delivery. The fourth layer is delivery failure risk. A customer who has heard nothing is a customer who is not home, or not willing to pay, when the rider arrives. Every one of those becomes an NDR, and every unrecovered NDR is on its way to RTO. The WISMO ticket looked like a support cost. It was also a logistics cost forming quietly upstream.
Why the default fixes fail
Most brands respond to a growing WISMO queue in one of three ways. None of them removes the pipeline between the data and the customer.
- More agents. The queue clears faster for a few weeks, then festive-season volume arrives and the model breaks, because costs now scale linearly with parcels. Each added agent is also one more person reading the same courier portal someone else already read.
- More tracking links. Sending the link again answers the ticket on paper. It does not answer the customer, because the link still shows “in transit” with no date and no explanation. Expect a repeat contact.
- A basic chatbot. A bot that echoes the courier status code is a tracking page with a greeting. It tells the customer “shipment received at origin facility” when what they asked is “will it reach Guwahati before Friday, and should I cancel if not.”
The pattern underneath all three: the answer already exists in courier scan events. What is missing is a reliable way to read those events, turn them into a plain-language answer with a date, and deliver it before or immediately when the customer asks. That is an automation problem with a narrow, testable scope.
Proactive beats reactive
The cheapest WISMO ticket is the one that is never raised. Most “where is my order” anxiety has a trigger: a missed scan, a parcel sitting at one hub for 24 hours, a delivery date that just passed. All three triggers are visible in the courier data before the customer feels them. A brand watching those events can send the right proactive shipment notification first, on WhatsApp, where it will actually be read.
Here is what that looks like on a real afternoon. 14:22, an Ekart scan feed shows a Mumbai-to-Guwahati parcel has had no new event in 30 hours at the Jaipur hub; the promised date is tomorrow. 14:24, the system drafts a WhatsApp update: the parcel is delayed at a transit hub, the new expected date is in two days, and here is what happens if it does not move by then. 14:26, the update goes out within agreed limits. The customer is annoyed about the delay but informed about it. No ticket is created. The alternative version of this timeline is familiar: silence on day one, an anxious ticket on day two, a refused COD parcel on day four.
Automating the answer, safely
Order tracking automation on WhatsApp works when it is built in steps, and when each step earns the next one. A practical sequence looks like this.
- Count the categories. Pull a month of tickets and tag them: on-track queries, delayed queries, passed-date queries, NDR follow-ups, address problems. Attach the agent minutes each category carries. Two or three categories usually hold most of the volume, and they are the boring, answerable ones.
- Answer from scan events, not from templates. The system reads the same courier scans your agents read, across Delhivery, Xpressbees, Ekart, Blue Dart, and composes the answer from them: last event, current location, realistic new date. An answer without a date is a repeat ticket waiting to happen.
- Test without acting. The system drafts answers but sends nothing (Shadow mode). Every draft is scored against what the agent actually sent and how the ticket turned out. Nothing goes to a customer until the drafts clear the quality bar agreed before testing.
- Approve first, then automate what proves safe. A person reviews and approves each reply (HITL, human-in-the-loop). Categories that stay accurate week after week graduate to running automatically within agreed limits (Autopilot), such as on-track answers and standard delay updates with a date. The limits are set with your support leads and can be tightened at any time.
- Escalate the genuinely stuck. A parcel with no scan for 48 hours, a third NDR attempt, or an address dispute does not get an automated apology. It gets flagged to a person with the full scan history attached, because it needs an operational action (a courier escalation, a re-attempt, a replacement decision), not a message.
Which tickets stay with people
The line is simpler than it looks. Automation handles information: where the parcel is, when it will arrive, why it is late. People handle judgment and emotion. An angry customer gets a person, because an angry customer is no longer asking about a parcel. High-value orders, repeat NDR cases, refund-versus-wait decisions and anything involving a damaged parcel stay with the team. So does every case where the scan data and the customer’s story disagree, because that disagreement is usually a real operational problem wearing a support costume.
Done this way, the support team does not shrink so much as it changes shape. The hours that went into reading tracking pages out loud go into the cases that decide whether a customer buys again.
What this does not fix
Courier data stays messy. Scans get missed, status codes differ across couriers, and a parcel can be genuinely untraceable for days. Automation can work around that reality; it cannot clean it up. A proactive update also raises the bar: once you tell a customer a date, the brand owns that date, and a second missed date with an automated message attached is worse than silence.
Most importantly, messaging is not recovery. For the genuinely stuck parcel, the update to the customer is the easy part. Someone still has to chase the courier, decide on the re-attempt or the replacement, and close the loop. WhatsApp messaging to customers also carries real obligations: utility templates and consent under the DPDP Act 2023 are not optional extras. WISMO automation removes the human pipeline between data and customer for the routine majority. It does not, and should not, remove the human from the cases where the answer is bad news.