Open your courier dashboard on any Tuesday and there it is: "Undelivered. Customer not available." You call the customer. She was home all day, phone in hand, and nobody rang the bell. Meanwhile your parcel sits in a delivery hub 4 km from her house with a timer running, and if nobody does anything in the next two or three days, it quietly starts the trip back to your warehouse, at your cost.
That alert is an NDR, a non-delivery report, and the 24 to 72 hours after it lands decide whether the order is saved or lost. Most founders never work this window because nobody told them the machinery exists. Ravikant Tyagi ran distribution at Eureka Forbes and supply chain and operations at Atomberg, where the NDR queue was cleared every morning before anything else, because an NDR is not a status update. It is a question the courier is asking you, and silence is also an answer: send it back.
This guide covers the layer between two problems we have written about separately. Stopping weak orders before dispatch is the RTO reduction playbook. Handling orders that were delivered and then come back is the returns and reverse logistics guide. This one is about the order in between: shipped, attempted, undelivered, still saveable.
An NDR is the courier's alert that a delivery attempt failed and your parcel is waiting in their hub for instructions. Most Indian couriers make 3 attempts, then trigger RTO, and unmanaged NDRs convert to RTO within 24 to 72 hours. The remarks decode roughly as: customer refused 37 percent, customer not available 28 percent, address issues 14 percent, and a slice of the "not available" entries are fake attempts where no rider ever came. Speed decides the outcome: act inside 24 hours and 30 to 50 percent of at-risk orders are saveable; wait past 48 and you are collecting scraps. The playbook: auto-WhatsApp on the flag, call within 4 working hours, fix the address inside the courier panel, convert wobbly COD to prepaid, dispute fake attempts with timestamps. For a 500-order brand, a 30 percent save rate is worth roughly ₹10,000 a month.
What an NDR actually is, and the clock behind it
An NDR (non-delivery report) is the courier's formal record that a delivery attempt failed, tagged with a reason code, while the parcel stays at the local delivery hub. It is not an RTO. RTO (return to origin) is what happens if the NDR goes unanswered. Every RTO in your monthly report was an NDR first, sitting in a panel, waiting for someone to act.
The machinery runs on a fixed cycle. Most Indian couriers make up to three delivery attempts before marking a shipment RTO, and unmanaged NDRs convert to RTO within 24 to 72 hours per ClickPost. Here is the timeline from the parcel's side.
| Stage | Clock | What actually happens |
|---|---|---|
| Attempt 1 fails | Day 0 | Rider marks a reason code; the NDR lands in your panel, often within minutes |
| Your action window | Day 0 to 1 | The courier waits for instructions; no input means attempt 2 fires with the same information |
| Attempt 2 | Day 1 to 2 | Same address, same phone number, usually the same result |
| Attempt 3 | Day 2 to 4 | The final try on most networks |
| RTO trigger | Day 3 to 5 | The parcel starts the return journey; you now pay the reverse shipping leg too |
Read the second row again, because it is the whole point of this guide. The courier's default reattempt changes nothing. If the address was incomplete on Monday, it is still incomplete on Tuesday. Attempt 2 with the same bad information is not a second chance, it is the same failure rehearsed. Saves come from injecting new information into the cycle: a corrected address, a confirmed time slot, a customer who now knows the rider accepts UPI.
Decoding NDR remarks: what the courier panel actually means
The remark you see was typed by a rider clearing 60 stops under time pressure. Treat it as a hint, not a fact. Industry data from GoSwift breaks NDR reasons down roughly like this, and the right first move is different for each one.
| Panel remark | Share of NDRs | What it usually means | Your first move |
|---|---|---|---|
| Customer refused delivery | ~37% | Changed mind, COD amount surprise, or a family member turned the rider away | Call before any reattempt; a genuine refusal burns two more attempts for nothing |
| Customer not available | ~28% | Sometimes true. Often a fake attempt wearing a polite name | Check the attempt timestamp, then ask the customer if anyone actually came |
| Address incomplete or incorrect | ~14% | A real, fixable problem: missing house number, wrong pin, no landmark | Collect the full address on WhatsApp and update the courier panel before attempt 2 |
| Customer rescheduled | ~9% | The buyer wants the parcel, just not today | Lock a date, reconfirm the COD amount the evening before |
| Out of delivery area | ~2% | The courier's serviceability map lied at booking | Cancel and re-ship through a courier that actually serves that pin code |
One rule across all five rows: never take the remark to the customer as an accusation. Open with the parcel, not the blame.
The fake attempt: when the rider never came
A fake attempt is exactly what it sounds like: the shipment gets marked "customer not available" or "premises closed" and nobody ever reached the address. It is not rare and it is not random. A rider with 70 stops and a delivery-per-hour target hits 4 pm knowing 15 stops will not happen, and the fastest way to close them is a status code. COD parcels get faked more often because cash handling takes longer at the door.
You detect it with timing, not arguments. Edgistify's detection guidance flags any status change within about 5 minutes of "out for delivery" as suspect, against a typical 30 to 45 minute gap for a genuine attempt. So read the timestamps: a parcel that left the hub at 10:02 and failed at 10:09 did not meet a missing customer. Second check: ask the customer whether they received a call, because most genuine attempts include one and courier apps log it. Third: your customer's own words on WhatsApp, "nobody came, I was home all day", timestamped, is evidence you will use later.
Track suspected fakes per courier per pin code in your NDR sheet. A one-off fake is noise. The same courier faking the same pin codes every week is a pattern you can act on, and the escalation section below shows exactly how.
Why speed decides your save rate
Two clocks run against you the moment an NDR lands. The courier's clock: the parcel converts to RTO within 24 to 72 hours if nobody intervenes, and each auto-reattempt burns one of your three tries on stale information. The customer's clock: bePragma's NDR research puts the practical patience window around 36 hours after a failed delivery before the buyer mentally abandons the order. A COD buyer's intent decays like fruit, not like steel.
| First action on the NDR | Realistic save band on at-risk orders | Why |
|---|---|---|
| Inside 4 to 24 hours | 30 to 50% | Corrected info reaches the hub before attempt 2; buyer intent still warm |
| 24 to 48 hours | 15 to 30% | One attempt already wasted on old information; intent cooling |
| Past 48 hours | Under 15% | Auto-RTO timers firing; anything saved here is luck, not process |
Vendor numbers point the same direction: bePragma claims disciplined NDR management can cut RTO by as much as half, and every serious tool in this market sells one core promise, shrinking response time from hours to minutes. Take vendor ceilings with salt. The direction is still true: your save rate is a function of response speed more than of any other variable you control.
The NDR resolution playbook
Step 1: auto-message the customer the moment the flag lands
Within the hour, an automated WhatsApp goes out: "The courier could not deliver your order today. Tap one: Reattempt tomorrow · Update address · Cancel order." WhatsApp because open rates in India sit far above email, and buttons because they remove typing friction. If you already run WhatsApp for marketing, this is the highest-ROI flow you will ever add to it. Orders answered here often need nothing else.
Step 2: call inside 4 working hours if there is no reply
The call is where saves actually happen, because half the NDR pool will not tap a button but will answer a phone. Call from your brand's number, not the courier's. The structure matters more than the exact words.
Open with the parcel, never the failure: "Your [product] is with the courier in [city] and came back undelivered yesterday. I want it reaching you tomorrow." Then three checks, in order: read the address back line by line and correct it live · confirm who will be at that address and in which time window · state the exact COD amount and that the rider accepts UPI. Never ask "why did the delivery fail"; the customer usually does not know, and the panel remark is unreliable anyway. Close by locking it: "Tomorrow, 11 to 2, ₹799, cash or UPI. Scheduling it now." Whole call, under 3 minutes.
Step 3: fix the address where it counts
A corrected address sitting in your WhatsApp chat saves nothing. The rider's app pulls from the courier's system, so the correction must go into the courier or aggregator panel as an address update on the NDR, before you request the reattempt. Same for an alternate phone number. This 60-second habit is why address NDRs should almost never become RTO: of all five reason buckets, this one is fully inside your control.
Step 4: choose the right resolution, not the default one
Reattempt is not always the answer. According to the Founder Decision Loop™, you resolve in order of what keeps the sale alive at the lowest cost, and sometimes the cheapest move is ending it early.
If the customer confirms and the address checks out → reattempt next day. If the customer is travelling → reschedule to a locked date and reconfirm the COD amount the evening before. If the customer wobbles on cash or timing → send a payment link and convert the order to prepaid; once it is paid, anyone at home can accept it. If the customer says no, or stays silent through day 3 → mark it RTO yourself, today. Two honest noes cost less than three hopeful reattempts, and your stock starts the trip home a week earlier.
The prepaid conversion deserves its own line. "I don't have cash right now" ends more COD deliveries than founders realise. A payment link sent during the NDR call removes the doorstep friction entirely, and the delivery then succeeds with whoever opens the door.
Courier escalation: disputing a fake attempt and winning
When the timestamps say fake, dispute it, but understand what moves a courier and what does not. A complaint is an opinion. An evidence pack is a case. Yours has four parts: the tracking screenshot showing out-for-delivery at 10:02 and failure at 10:09 · the customer's timestamped WhatsApp saying nobody came · a request for the rider's call log against your customer's number · a request for GPS or proof-of-attempt data, which most courier apps record.
File it as an NDR dispute in your aggregator panel the same day and push for a same-day or next-morning reattempt, since a disputed attempt should not consume one of your three tries. Then the honest part: you will not win every dispute, and one screenshot rarely changes anything. What changes courier behaviour is a weekly pattern file. When your Monday review shows one courier faking attempts at three times the rate of the others in the same pin codes, you move those pin codes to a different courier and tell your account manager why, with the file attached. That conversation, backed by shiftable volume, is the only dispute you reliably win. Our courier aggregator comparison covers setting up multi-courier operations so the volume threat is real.
Running distribution teams taught me to read the attempt timestamp before the remark. A parcel marked "customer not available" nine minutes after leaving the hub is not a customer problem, it is a route problem, and no amount of customer calling fixes it. So we graded every courier weekly on one number nobody else was watching: the median gap between out-for-delivery and first failure. Courier behaviour cleaned up within weeks of that number appearing in our review meetings, because they knew exactly what it measured. You get what you inspect, not what you expect.
NDR automation: what to buy, what to DIY
Every tool here sells the same core promise: cut your first response from hours to minutes. The differences are in depth and price.
| Option | What you get | Best fit | The catch |
|---|---|---|---|
| Shiprocket NDR + Engage 360 | NDR in your panel minutes after failure; buyer outreach via SMS, email, IVR and WhatsApp; claims up to 10% RTO reduction from real-time action | Brands already shipping through the aggregator | IVR sits on higher plans, and you still assign actions; it speeds you up, it does not replace you |
| ClickPost NDR | Automated sequences: WhatsApp, SMS and AI voice calls firing at set intervals after the failed attempt | 3,000+ orders a month across multiple couriers | Enterprise product and pricing; overkill below roughly 1,000 orders a month |
| GoKwik RTO suite | COD risk scoring at checkout plus NDR workflows downstream | High-COD, checkout-led brands wanting prevention and rescue in one stack | The value skews toward prevention; do not buy it for the NDR module alone |
| DIY: courier panel + WhatsApp Business + one named person | Morning NDR export, template messages, personal calls, a tracking sheet | Under ~300 orders a month, which usually means 10 to 20 NDRs a week | Runs on discipline, not software; skip one day and the window closes anyway |
The uncomfortable truth about all four rows: automation sends the first message fast, and that matters, but the highest-value saves still come from a human phone call. A flow can offer buttons. It cannot hear that the customer's real issue is that her husband handles the cash and travels on weekdays, then quietly convert the order to prepaid. Buy speed. Keep the judgement in-house.
The math: what a 30 percent save rate is worth
Numbers for a typical COD-heavy brand doing 500 orders a month at ₹799 average order value. Assume NDR flags on 20 percent of shipments, 100 a month, normal for a COD-heavy book. Left alone, courier auto-reattempts deliver some anyway; assume 30 make it on their own and 70 are genuinely at risk. Each RTO burns about ₹360 in cash across both shipping legs, dead packaging, repack labour and the ad spend that bought the order, consistent with the ₹300 to 400 per failed delivery that bePragma pegs. Each rescued order also earns its roughly ₹150 contribution.
| Monthly picture | No NDR process | With a 30% save rate |
|---|---|---|
| NDRs flagged | 100 | 100 |
| Orders saved beyond courier default | 0 | 21 |
| Orders becoming RTO | 70 | 49 |
| Cash burned on RTO (₹360 each) | ₹25,200 | ₹17,640 |
| Contribution earned by rescues (₹150 each) | ₹0 | ₹3,150 |
| Monthly swing | · | +₹10,710 |
₹10,710 a month is about ₹1.28 lakh a year, the P&L effect of 71 extra delivered orders a month at this brand's contribution, for roughly 90 minutes of structured work a day. According to the Margin Waterfall™ framework, RTO loss is its own deduction layer between gross margin and profit, and NDR management is the only lever that shrinks that layer after the parcel has already shipped; everything else, verification, pin-code rules, honest ads, works before dispatch. If ₹10,000 a month decides survival for you right now, put your real numbers through the unit economics guide first, then come back to this table.
A founder shipping 500 orders a month reviews the NDR panel on Saturdays, because weekdays belong to marketing. By Saturday, the week's 25 flagged orders have sat an average of 3 to 4 days each. The windows are closed, the third attempts have fired, and 18 of the 25 are already travelling home at about ₹360 apiece. That is roughly ₹6,500 burned in one lazy week, ₹26,000 a month, more than it costs to have someone clear the panel for an hour every single morning. The NDR queue is not a weekly report. It is a live counter, and it only counts down.
The five NDR numbers to read every Monday
Ten minutes, one sheet, every week.
- NDR rate: NDRs ÷ shipped orders. It tracks your COD share, so watch the trend, not the absolute. A sudden spike means a courier, a pin code or a new campaign started misbehaving.
- Save rate: rescued orders ÷ NDRs flagged. Target 30 percent or better overall. Address and reschedule NDRs should save far above that; refusals will drag the average down, which is normal.
- First-response time: NDR flag to first customer contact. Under 4 working hours, measured from the sheet, not assumed.
- Fake-attempt rate, by courier by pin code: suspicious first attempts ÷ total first attempts. One courier running at multiples of the others in the same pin codes gets its volume moved.
- NDR-to-RTO conversion, by reason: address NDRs that still became RTO mean your correction flow is broken, not your customers.
- Turn on instant NDR alerts in your courier or aggregator panel today.
- Build the auto-WhatsApp with three buttons: reattempt, update address, cancel.
- Write the call script, and put a named person on NDR calls with a 4-working-hour SLA.
- Fix addresses inside the courier panel before requesting any reattempt.
- Keep payment links ready to convert hesitant COD orders to prepaid during the call.
- Log every NDR: courier, pin code, remark, out-for-delivery and failure timestamps, action taken, outcome.
- Flag any first attempt marked within minutes of out-for-delivery and dispute it with the evidence pack.
- Mark confirmed refusals as RTO the same day; stop spending attempts and messages on dead orders.
- Review the five NDR metrics every Monday and shift pin-code volume away from repeat offenders.
Your next action today
Open your courier panel right now and count the NDRs older than 24 hours. That number is money in a closing window. Call the five newest ones yourself, today, using the script above. You will probably save one or two orders before dinner, and you will hear, in your customers' own words, why your deliveries fail, which no dashboard will ever tell you. Then decide what to systematise and who owns it every morning. If you are still assembling the wider machine, the roadmap to ₹1 lakh a month shows where delivery operations sit in the growth sequence.
If you'd like the complete execution system, calculators, SOPs, templates and operating frameworks behind this process, continue inside D2C Acquisition.Lab.
