The WISMO post on this blog is about answering well: read the courier scans, compose the plain-language reply with a date, send it in seconds. This piece is about the cheaper half of the problem — the tickets that never need answering because the customer was informed before the question formed. Prevention and triage are not the same discipline, and teams that confuse them buy answering automation when what they needed was two well-timed messages.
The economics are lopsided in your favour. A proactive utility message costs roughly a rupee or two at WhatsApp API rates. A WISMO ticket costs ₹60-₹75 fully loaded once you count agent time, tools, management and churn — the math is in our support cost breakdown. If a message prevents even one ticket in fifty, it has paid for the other forty-nine.
The milestone baseline
Start with the boring skeleton: a message at every state change that a customer would otherwise discover by refreshing a tracking page. Ordered with a date. Packed. Shipped, with the courier named and the EDD restated. Out for delivery, today. Delivered, with a quiet ask for a rating or a return-promise reminder. Five messages, all triggered by events you already receive.
The EDD is the load-bearing wall of the whole system. “Arriving Thursday, October 29” set at checkout and repeated at every milestone does two jobs: it satisfies the curious majority, and it defines the moment a delay message becomes mandatory instead of optional. A brand that promises dates it cannot keep should not build notification flows — it should fix its serviceability data first, or every message just schedules a sharper disappointment.
Delay detection: the message that matters
The milestone skeleton prevents curiosity tickets. The delay message prevents the angry ones. Every WISMO wave has a trigger, and the triggers are computable from courier scan data: a parcel with no new scan event for 24-30 hours at any hub; a promised date that is tomorrow and the parcel is two states away; an NDR first attempt that the customer may not even know happened. Each of these is visible in the data hours to days before the customer’s patience runs out.
The message that works has three parts: what happened (“your parcel is held at the Jaipur hub”), what it means (“it will arrive Saturday the 31st instead of Thursday”), and what happens next (“if it has not moved by Friday evening, we will reship or refund — your choice”). The third part is the one most brands omit and the one that deletes the anxiety. An informed delay with a next step costs one message. A silent delay costs a ticket, a repeat ticket, and a share of refused COD parcels — because the customer who has heard nothing is the customer who is not home, or will not pay, when the rider finally arrives.
NDR alerts to the customer, not just to ops
The standard NDR workflow alerts the brand: attempt failed, reason code, next attempt scheduled. The customer often learns about it from a missed-call notification or not at all. Flipping the alert outward — “the rider came at 2pm and could not reach you; reply with a time, or share a landmark” — converts a chunk of NDR loops into successful second attempts, because now the two parties who need to coordinate are both in the conversation. The shipment exception playbook covers the ops side; this is the same data, aimed at the other phone.
Consent, templates and quiet hours
None of this works outside the rules, and the rules are the same as every WhatsApp flow on this blog. Consent captured at checkout, proof stored, opt-out honoured — the DPDP burden sits with you. Utility templates approved in advance, copy kept transactional: a delay notice with a new date is utility; a delay notice with “check out our new collection” is marketing wearing a costume, and costume violations eventually cost the number. Quiet hours matter commercially as much as legally: night orders and 7am pings perform worse and annoy more than a 9am send. Cadence caps belong in policy — one delay update per trigger, not a liveblog of every hub scan.
During festive weeks, when volume doubles and delays multiply, the caps are what keep the flow from becoming a spam cannon aimed at your own buyers. The message count should scale with events that matter, not with events that exist.
What the numbers do
Teams that run the full skeleton plus delay detection commonly see WISMO volume fall 30-40% within a month, with the second-order effect showing up in the logistics ledger: fewer refused COD parcels on delayed lanes, better first-attempt rates on NDR-recovered orders. The refund sibling of this flow — proactive refund status messages — does the same for the “where is my refund” queue.
Where automation fits, and where people stay
Detection, composition and dispatch are automation work: watch the scan feed, compute the triggers, draft the message from the state, send inside the caps. The judgment layer stays human at every step that matters: the delay-copy tone, the cadence policy, the decision to reship-or-refund after the second stuck scan, and every reply that comes back asking something the templates do not cover. Run it in shadow mode first — drafts scored against what your agents would have sent — then behind approval, then automatic within limits. The phased trust model is the sequence; nothing about notifications earns an exception to it.
The whole discipline in one line: a date in the customer’s hands beats a tracking page they never open. Everything else is scheduling.