Open your courier dashboard right now. Somewhere there is a list of orders marked "Out for delivery, attempt failed." Each one had a real customer who placed a real order, paid (or said they would), and ended up not getting their package on the first try. Each one is sitting on a 24 to 72 hour timer. After that, the shipment turns into an RTO, the inventory comes back in unsellable condition, and the cost gets booked against your margin forever.
This is the NDR window. It is the single highest-leverage operational gap in Indian D2C. A brand running a tight recovery workflow saves 50 to 60% of NDRs from becoming RTOs. A brand without one watches 30 to 40% of those orders flip directly to permanent loss. [EXTERNAL: Shipway ShipNotes Report 2025] The difference between the two outcomes is rarely the courier. It is whether the brand has a workflow that fires inside 30 minutes and a customer-confirmed reattempt that the delivery agent actually sees.
For a brand doing 4,000 COD orders a month at 25% RTO, every 5 percentage points of NDR recovery is worth roughly ₹50,000 a month in direct logistics cost. Closing the gap between 35% recovery and 55% recovery is a ₹2 lakh annual saving on a single ops process. The math is unforgiving.
This playbook covers what NDR actually is, the four most common Indian NDR reason codes and which ones are recoverable, the exact 72-hour timeline, and a step-by-step workflow you can implement this week.
NDR vs RTO: the only window you have
NDR (Non-Delivery Report) is the signal a courier raises when a delivery attempt fails for any reason. RTO (Return to Origin) is the irreversible outcome after enough failed attempts. Every RTO starts as an NDR, but not every NDR has to become an RTO.
The typical Indian courier timeline runs like this. Day 0: shipment is out for delivery, first attempt fails, NDR is raised. Day 1: automatic reattempt, around 24 hours after the first failure. Day 2: second reattempt if the first one also failed. Day 3: shipment is marked RTO and starts the return journey to your warehouse.
That is your window. From the NDR webhook firing to the RTO trigger is typically 48 to 72 hours, with the first reattempt happening around the 24-hour mark. Everything you do during that window changes whether the package gets delivered or comes back. Everything you do after is too late.
In Indian D2C, 15 to 20% of all shipments hit at least one NDR. [EXTERNAL: BeePragma NDR analysis] Of those, 30 to 40% become RTO without intervention. Roughly 20 to 30% recover via automatic courier reattempts. The remaining 30 to 50% are the orders that move on whether they become deliveries or returns based entirely on what the brand does during the 72-hour window. That last bucket is what this playbook is about.
Why NDRs happen in India (and which ones you can save)
NDR reason codes are not all equal. Some are timing or contact problems that a 30-minute WhatsApp fixes. Some are root-cause problems at checkout that no amount of recovery effort will reverse. Knowing which is which lets you stop wasting effort on the unrecoverable ones.
The five reason codes that cover the vast majority of Indian NDRs:
1. Customer refused (~37% of NDRs in COD)
The customer was home and saw the package, then declined to take it. This is the largest non-recoverable bucket. Common drivers: buyer's remorse, ordered duplicate by accident, expectation mismatch (size, colour, price), or the buyer was never serious in the first place. Recovery rate on refusals is under 15%, and the fix is upstream: better product photography, COD-to-prepaid conversion at checkout, OTP verification for high-risk orders.
2. Customer not available / phone unreachable (the largest recoverable bucket)
The courier reached the address but the customer was not home, or did not answer the phone. This is your highest-leverage recovery category. A WhatsApp within 30 minutes of the NDR plus an evening reattempt window typically converts 60 to 75% of these to successful delivery. [INTERNAL LINK: why evening delivery reattempts cut RTO by 47-53%]
3. Address-related issues (~14% of NDRs)
Incomplete address, wrong pincode, landmark-only directions, or the courier could not locate the building. Recovery depends entirely on whether the customer can supply a corrected address. A WhatsApp asking "we couldn't find this address, can you confirm your flat number and a nearby landmark" recovers around 40 to 55% of these. The rest become RTOs because the corrected address is unserviceable, the customer does not respond, or the original address was fake. [INTERNAL LINK: address validation for D2C and how 18-24% of RTOs start with a bad pincode]
4. Invalid contact number (~12% of NDRs)
The phone number on the AWB was wrong, dead, or unreachable. WhatsApp is your only realistic recovery channel because you can ping the email address from the order or send a fallback SMS. Recovery rate hovers around 25 to 35% because many of these were buyer-side problems (typo, fake number) from the start.
5. External factors (weather, traffic, vehicle issues)
Strikes, monsoon flooding, courier hub closures, vehicle breakdowns. These usually clear automatically within 24 to 48 hours. Recovery rate is high (70%+) without much brand-side effort beyond keeping the customer informed so they do not initiate a cancellation.
The pattern: roughly half your NDRs are recoverable with a well-built workflow, a quarter need an upstream checkout fix to prevent recurrence, and a quarter were never going to deliver regardless. Track your NDR reason code split monthly. The shape of that split tells you where to invest next.
The 72-hour recovery window
The recovery curve is steep, and most brands lose the bulk of their addressable NDRs by missing the first six hours.
Here is the recovery probability by response speed, based on operational data from Indian logistics platforms [VERIFY]:
| Response time after NDR | Recovery probability | Why |
|---|---|---|
| Within 30 minutes | 40 to 55% | Customer still aware of the missed delivery, phone in hand, decision-making warm |
| 2 to 4 hours | 30 to 40% | Still recoverable but reschedule windows narrow |
| Same-day, after 4 hours | 20 to 30% | First reattempt already scheduled by courier; harder to redirect |
| 24+ hours | Under 10% | First reattempt already failed; customer intent decaying fast |
| 48+ hours | Under 5% | Past the window the courier uses for reattempt window adjustments |
The implication is uncomfortable: brands that handle NDRs through a daily ops review are recovering under 10% of recoverable orders, which is roughly the same as brands that do nothing. The only setup that actually moves the recovery number is one that fires automatically in under an hour.
That requires three things you cannot do manually at scale: a courier webhook that pushes NDR events to your system in near-real-time, a WhatsApp BSP integration that fires automated messages on those events, and a routing logic that handles each reason code differently. None of these are technically hard. Most brands skip them because no single ops hire is responsible for closing the loop.
The NDR recovery playbook: six steps
Here is the working setup for a brand processing 2,000 to 15,000 orders a month. Larger brands have variations, but the layers are the same.
Step 1. Connect a courier NDR webhook
If you are reading NDR status from a dashboard, you are starting hours behind. Switch to webhook-based ingestion.
Delhivery exposes NDR webhooks directly: you register an endpoint URL with their tech team, and they POST status updates as scan events happen. Shiprocket exposes NDR webhooks via their unified courier API, which means you get the same feed whether the underlying courier is Delhivery, Bluedart, Ekart, or XpressBees. ClickPost provides a multi-courier unified feed if you want to avoid stitching multiple webhook contracts.
If you cannot get direct webhook access (smaller brand, regional courier), poll your courier API every five minutes for orders in "in transit" status. It is uglier, but it keeps your latency under ten minutes, which is enough to stay in the 30-minute recovery band.
Step 2. Trigger a WhatsApp within 30 minutes
When the NDR fires, your first response should be a WhatsApp to the customer's number, not an SMS. WhatsApp open rates in urban India run 98% with 95% of messages read within three minutes, versus around 19% for SMS. [EXTERNAL: WhatsApp business statistics India]
The message should be specific:
"Hi [name], we tried to deliver your order #[number] at [address] today but couldn't reach you. We can redeliver this evening between 5pm and 8pm. Reply YES to confirm or send a different address."
Three things make this work: the order number anchors the customer to a specific purchase, the address back-quoted confirms what the courier had, and the time window plus one-tap confirmation removes friction. Generic "your order failed delivery, please contact support" messages convert at one-third the rate.
Use Interakt, WATI, AiSensy, or any WhatsApp BSP that supports template messages and webhook-triggered sends. For brands above 5,000 orders a month, also configure an SMS fallback that fires if the WhatsApp template is not delivered within 15 minutes.
Step 3. Branch by reason code
A single template does not fit all NDRs. Build five branches off the NDR webhook based on reason code:
- Customer not available / unreachable: Offer evening reattempt. Default to confirmation, not address change.
- Address not found / wrong address: Ask for full corrected address plus a nearby landmark. Disable the courier reattempt until the customer responds.
- Customer refused: Skip the WhatsApp altogether or send a single retention message offering a small discount. Recovery is rarely worth the effort.
- Invalid number: Try email if available; else accept the RTO outcome.
- External factor: Send a passive update "your delivery is delayed due to weather/traffic, we'll reattempt tomorrow." No action required.
Step 4. Hold the reattempt until customer confirmation
A reattempt without confirmation is gambling. The courier will run their default reattempt at the same time of day as the failed attempt, which is exactly the timing pattern that already failed.
Hold the AWB. Most courier APIs let you pause a shipment from automatic reattempt while you wait for customer response. Set a 12 to 18 hour hold window. If the customer responds with a confirmed time, pass that to the courier. If they do not respond, release the hold and default to the evening reattempt window.
The data is clear: customer-confirmed reattempts succeed at roughly double the rate of unconfirmed automatic reattempts. The hold-and-confirm pattern is the single biggest operational improvement available on the NDR side.
Step 5. Push the confirmed window to the courier
When the customer responds with a confirmed time, you need to make sure the delivery agent sees it. Different couriers handle this differently:
For Delhivery, use the NDR Package Action API to update the reattempt time and special instructions on the AWB. For Shiprocket, update the AWB remarks via their NDR action endpoint. For brands using ClickPost or Shipway as a unified layer, both expose a single "update reattempt instruction" call that propagates to the underlying courier.
Add the confirmed window to the special instructions field, ideally as a concrete time range and not a vague "evening." Experienced delivery agents in pincodes where your brand ships regularly will honour these on a best-effort basis. The instruction is not contractually enforced, but it shifts the probability meaningfully.
Step 6. Track recovery by reason code, weekly
Without measurement, the workflow drifts. Build a weekly view of:
- NDR volume by reason code (which categories are growing)
- Recovery rate by reason code (what is working)
- Median NDR response time (how fast you actually move)
- Recovery rate by pincode (which pincodes need different rules)
When recovery dips in a specific reason code, you know exactly where to investigate. When it dips across the board, your NDR response time has probably slipped. The workflow looks automatic but needs eyes on it weekly. [INTERNAL LINK: 7 RTO metrics every D2C brand should track daily]
Benchmarks: what good NDR recovery looks like
Targets to calibrate against, drawn from operational data across Indian D2C platforms [VERIFY]:
| Metric | Struggling | Standard | High performer |
|---|---|---|---|
| NDR-to-delivery recovery rate | Under 25% | 25–45% | Over 55% |
| Median NDR response time | Over 12 hours | 2–12 hours | Under 30 minutes |
| NDR volume as % of shipments | Over 22% | 15–22% | Under 12% |
| Customer-confirmed reattempts | 0% (none held) | 30–60% of recoverable NDRs | Over 75% |
| WhatsApp template response rate | Under 15% | 15–35% | Over 40% |
High-performer brands typically hit the "high performer" column across most metrics within six months of deploying a proper workflow. The slow ramp is usually not the technology. It is the reason-code routing and template tuning that takes a quarter or two of iteration.
[INTERNAL LINK: 10 proven ways to reduce COD returns India]
If you want this running without stitching together courier webhooks, a WhatsApp BSP, and an NDR management tool separately, OneflowAI bundles NDR automation, WhatsApp notifications, and delivery preference capture into one system. Brands plugging in see median NDR response times drop to under 15 minutes within the first week, and recovery rates climb to the 50%+ band by the end of the first month.
Frequently asked questions
What is an NDR in ecommerce?
NDR stands for Non-Delivery Report. It is the courier's notification that a delivery attempt failed, before the shipment becomes an RTO. NDR is the warning; RTO is the irreversible outcome after two to three failed attempts.
What percentage of NDRs become RTOs without intervention?
30 to 40% convert to RTO. Automatic courier reattempts on their own recover 20 to 30%. With a tight workflow (WhatsApp inside 30 minutes plus customer-confirmed reattempts), brands typically recover 50 to 60%.
How fast should I respond to an NDR?
Inside two hours. Response within one to two hours recovers 30 to 40% of failed deliveries. Waiting 24 hours or more drops recovery under 10%.
Which NDR reasons are most recoverable?
Recoverable: "customer not available", "phone not reachable", "premises closed". Mixed: "address not found / wrong address" (depends on whether customer can correct). Low recovery: "customer refused" (the largest non-recoverable bucket, around 37% of NDRs in COD).
Is WhatsApp or SMS better for NDR follow-up in India?
WhatsApp by a wide margin. 98% open rate vs around 19% for SMS, 95% read within three minutes in urban India. SMS is a useful fallback for customers without WhatsApp or in low-connectivity pincodes.
How many reattempts before RTO?
Most Indian couriers do two to three reattempts. First reattempt around 24 hours after NDR; second around 24 hours after that; RTO around 72 hours after the original failed attempt.
What does an NDR cost if it becomes an RTO?
₹180 to ₹240 per RTO in combined forward shipping, reverse logistics, and handling. NDR recovery interventions cost ₹15 to ₹20. The return on prevention is 9 to 16x.
Can I do NDR automation without a developer?
For brands under 1,000 orders a month, yes: Shiprocket and ClickPost have built-in workflows that pair with WhatsApp BSPs (Interakt, WATI, AiSensy). Above 2,000 orders a month, custom logic around reason code routing usually needs 5 to 10 hours of one-time developer work plus ongoing tuning.
What recovery rate should I target?
35 to 45% in the first 60 days. 55 to 65% after six months of tuning. Above 65% is rare and usually involves checkout-level prevention (reducing NDR volume by 30 to 40%) plus best-in-class recovery on the NDRs that still happen.
Should I disable the courier's automatic reattempt?
Yes, when you have customer confirmation pending. An automatic reattempt at the same time of day as the original failure repeats the failure. Hold the AWB for 12 to 18 hours waiting for customer response, then either use the confirmed window or default to evening reattempt (5pm to 8pm). This single change typically doubles reattempt success rate.