You shipped 300 COD orders last week. Forty-two came back as NDR. Your ops team sent WhatsApp messages to some of them, called a few, and recovered about eight. That is a 19% NDR recovery rate. Is that good? Is that bad? Is that what everyone else in your category is dealing with?
Most Indian D2C brands do not know the answer to that question. They track total RTOs, sometimes NDR volume, but almost never NDR recovery rate as a standalone metric broken down by reason code, category, or courier. So they have no way to tell whether their 19% is a process problem, a trigger-timing problem, or just the nature of their pincode mix.
This post gives you the actual numbers. Based on published data from Unicommerce's 2026 D2C report (410 million shipments, 6,000+ brands), Shipway's ShipNotes logistics data, and ClickPost's NDR management benchmarks, alongside operational patterns from D2C brands doing 1,000 to 20,000 orders a month. Where data is from operational estimates rather than published studies, it is marked [VERIFY].
Read this as a benchmark document, not a how-to guide. The how-to is covered separately. [INTERNAL LINK: WhatsApp NDR recovery setup for Indian D2C brands] This is about knowing where you stand.
What NDR Recovery Rate Actually Measures
NDR recovery rate is the percentage of NDR-flagged shipments that eventually get delivered, rather than returning to origin as an RTO.
The formula is straightforward:
NDR Recovery Rate = (NDRs that resulted in successful delivery ÷ Total NDRs) × 100
If you had 100 NDR events last month and 45 of those shipments were eventually delivered, your NDR recovery rate is 45%.
What it is not: delivery success rate (which counts all shipments, not just failed-attempt ones), first-attempt delivery rate (the inverse of this, tracking how many orders need no reattempt at all), or RTO rate (which includes buyer-initiated returns, not just carrier-side failures).
NDR recovery rate is specific to the window between "something went wrong on first attempt" and "we either fixed it or it became an RTO." That window is typically 48 to 72 hours with Indian couriers. Delhivery, Ekart, Bluedart, and XpressBees all allow two to three reattempts before triggering the return journey, though exact SLAs vary by service tier and contract.
One nuance: some platforms and couriers define NDR differently. Shiprocket's NDR dashboard includes any shipment with a delivery exception, including weather delays and hub-side issues. ClickPost's NDR feed normalises reason codes across couriers. When you compare your numbers against benchmarks, confirm that your definition matches. [INTERNAL LINK: RTO analytics: 7 metrics every Indian D2C brand should track daily]
Industry Benchmarks: The Numbers
Before the reason-code breakdown, here is the macro picture.
RTO and NDR rates in Indian D2C
| Metric | Number | Source |
|---|---|---|
| Average RTO rate (normal periods) | ~21% | Unicommerce India D2C Report 2026 |
| Peak RTO rate (festive season Nov 2025) | ~39% | Unicommerce India D2C Report 2026 |
| COD-specific RTO rate | 26% | Shipway ShipNotes |
| Prepaid RTO rate | <2% | Shipway ShipNotes |
| COD festive peak RTO | ~58% | Unicommerce India D2C Report 2026 |
| NDR rate (orders with any delivery exception) | 15–20% | Industry estimate [VERIFY] |
| NDR-to-RTO conversion without intervention | 30–40% | Automated NDR industry data [VERIFY] |
The prepaid-vs-COD split is the most important number in this table. A 26% RTO rate on COD versus under 2% on prepaid is not a logistics problem. It is a payment method problem. Every percentage point you shift from COD to prepaid at checkout has a larger impact on your RTO rate than almost any logistics optimisation you can do downstream.
NDR recovery rate: what the tiers look like
| Recovery rate range | What it signals |
|---|---|
| Below 25% | No real automation. Manual ops follow-up, or triggering too late (24h+). Recovery is mostly from customers who called in themselves. |
| 25–40% | Basic automation in place (same-day WhatsApp/SMS), but likely generic templates or slow triggers. Getting there. |
| 40–55% | Solid. Webhook-triggered WhatsApp within 60 minutes, specific templates, basic reason-code branching. Most well-run D2C ops teams land here. |
| 55–65% | Mature. Reason-code routing, Hinglish templates for Tier-2/3, AWB hold + confirmed slot logic, no-response fallback to SMS. Above average. |
| Above 65% | Exceptional. Requires pincode-level tuning, courier-specific timing logic, and possibly AI voice for unreachable customers. [VERIFY] |
The 40 to 55% band is realistic for a brand that has spent 2 to 4 weeks setting up proper NDR automation. Getting into the 55 to 65% range usually takes another few months of tuning, mostly on reason-code-specific templates and trigger timing.
If you are below 25%, the fix is almost always one of two things: triggers are firing too late (next-day ops review instead of webhook-based), or templates are too generic to get a response. Both are fixable without major investment.
Recovery Rate by NDR Reason Code
Aggregate NDR recovery rate is almost useless as a diagnostic tool. The reason code breakdown is where the actual signal lives.
Indian couriers use different reason code labels but they cluster into four real categories. Here is what recovery looks like by reason, with a well-run WhatsApp-based flow:
| NDR Reason | Recovery rate (no automation) | Recovery rate (good automation) | Why |
|---|---|---|---|
| Customer not available / not at home | 15–25% | 55–70% | Customer wants the delivery. They just were not there. An evening reattempt confirmation fixes most of these. |
| Address not found / incomplete address | 10–20% | 45–60% | Customer can send the correct address or landmark via WhatsApp. Recovery depends on how quickly they respond and whether the courier can reattempt within the SLA window. |
| Phone unreachable / customer not responding | 5–15% | 30–45% | If the customer is not responding to calls, WhatsApp catches a portion. Voice AI tools are showing recovery improvements here [VERIFY from ClickPost/BeePragma data]. |
| Customer refused / rejected delivery | 5–10% | 10–18% | The customer changed their mind. Retention messages catch a small percentage before they firm up on the refusal. Not a high-recovery category regardless of outreach quality. |
| Courier/hub delay (weather, operational) | 70–85% | N/A (no customer action needed) | Most hub-side delays resolve automatically. Proactive communication reduces cancellations during the delay period. |
The most important insight from this breakdown: "customer not available" is your biggest opportunity. It is typically the largest single NDR reason code (often 40 to 60% of all NDRs [VERIFY]), and it has the highest recoverable ceiling. A brand that is at 35% overall recovery and gets this right can move to 50 to 55% without touching anything else.
"Customer refused" is worth one retention message and not much more. Spending ops time chasing refused deliveries has low yield. Set a rule: one WhatsApp retention offer, then process the cancellation. Do not drag it out.
Diagnostic shortcut: If your recovery rate on "customer not available" is below 40%, your trigger timing is probably the issue. If it is above 40% but your "address not found" recovery is below 30%, your template is not collecting enough information. Each reason code points to a different part of the flow.
Recovery Rate by Product Category
Not all categories recover equally, and the reasons are worth understanding.
| Category | Typical NDR recovery rate | Notes |
|---|---|---|
| Electronics and gadgets | 55–65% | Customers ordered something specific. Motivation to receive is high. Low impulse-refusal rate. |
| Personal care and beauty | 55–65% | Similar to electronics: repeat-purchasable category, customer intent is clear. Low refused-delivery rate. |
| Health and wellness / nutraceuticals | 50–60% | Subscription-adjacent customer behaviour. Customers who need the product respond quickly. |
| Fashion and apparel | 40–55% | Higher impulse-purchase share. Customers who changed their mind show up as refused or "not available" NDRs but actually do not want the order anymore. |
| Footwear | 40–50% | Fit uncertainty drives cancellations. Customers who asked "will it fit" before ordering recover better than pure impulse purchases. |
| Home decor / furnishings | 35–50% | Bulky items require lift access, building permission, or specific timing. More coordination needed per delivery. |
| Food and grocery | 45–60% | Perishable nature means customers who want the delivery respond quickly. But refusals are often because of delay (item no longer useful). [VERIFY] |
If you are in fashion or footwear and benchmarking against overall D2C NDR recovery averages, you are comparing yourself to a pool that includes electronics brands with structurally better recovery rates. Track your category-specific number against peers in the same segment, not against a broad average.
For fashion brands specifically: the "customer not available" NDR in your category is often not what it looks like. A customer who says they were not home but then does not respond to three follow-up attempts over 24 hours probably changed their mind. Flagging this pattern early — two attempts with no response on a fashion order — and switching to a cancellation flow rather than a recovery flow saves courier reattempt costs. [INTERNAL LINK: RTO by product category India]
Tier-1 vs Tier-2 vs Tier-3 Recovery Rates
Unicommerce's 2026 D2C report confirmed that Tier-2 and Tier-3 cities now drive 66% of incremental D2C order volume. The NDR picture in these markets is different from metro India in several ways.
What tier differences look like in practice
| Factor | Tier-1 (Mumbai, Delhi, Bengaluru, Hyderabad) | Tier-2 (Nashik, Kanpur, Rajkot, Indore) | Tier-3 (smaller cities, semi-urban) |
|---|---|---|---|
| Address accuracy at checkout | Moderate to good | Lower, more incomplete | Often missing flat/door number |
| WhatsApp response rate | Higher, faster | Moderate — Hinglish templates outperform English | Lower, voice calls supplement |
| Courier consistency | Delhivery, Bluedart, Ekart with stable SLAs | More variation; some pincodes underserved | Significant courier gaps; surface delivery common |
| Typical NDR recovery rate (good automation) | 50–65% | 40–55% | 30–45% |
| Primary NDR reason | Customer not available (urban work hours) | Address not found + customer not available | Phone unreachable + address issues |
For Tier-2 and Tier-3, two tactical changes move the needle more than anything else.
Hinglish templates. A WhatsApp message in Hinglish ("Aapka order deliver nahi ho saka. Kya aap aaj shaam 5-8 baje ghar par honge?") consistently outperforms formal English in Tier-2 pincodes like Kanpur, Nashik, Rajkot, and Coimbatore. The improvement is significant enough that it is worth building and approving separate templates for English and Hinglish from the start, not as an afterthought. [VERIFY: BSP data on Hinglish vs English response rate differential]
Evening default for Tier-2. Couriers in Tier-2 markets often attempt delivery between 10am and 2pm when a large share of working adults are out. Defaulting reattempts to the 5pm to 8pm window — without requiring customer confirmation — raises reattempt success rates in these markets noticeably, because you are shifting away from the most likely unavailability window. [INTERNAL LINK: evening delivery reattempts for Indian D2C]
The couriers themselves also matter by tier. Delhivery and Bluedart have deeper Tier-1 and Tier-2 coverage with more consistent SLAs. In Tier-3 and semi-urban pincodes, you may be relying on Ekart, regional partners, or surface courier networks that have fewer reattempt cycles before triggering RTO. Knowing your courier's SLA for each pincode tier is basic ops hygiene at this point.
How to Move Your NDR Recovery Rate
Once you know where you are benchmarking, here are the specific levers to move the number — in rough order of impact.
Lever 1: Fix the trigger timing first
This is responsible for the largest single improvement in recovery rate for most brands. If your NDR follow-up fires from a morning dashboard review, you are already 8 to 18 hours late. The recovery window on most NDR events is 48 to 72 hours, but the probability of recovery drops sharply after the first 2 hours.
Webhook-based triggers from Delhivery, Shiprocket's unified API, ClickPost, or Shipway push NDR events within 5 to 15 minutes of the courier raising them. That gets you into the 30 to 60 minute band where recovery probability is 40 to 55%. Waiting until next morning means under 10%.
If you do nothing else from this article, get onto webhook-based NDR triggers. The rest of the optimisation matters only if the timing is right.
Lever 2: Separate templates by reason code
One template for all NDR types is one of the most common mistakes in D2C NDR management. The customer who was not home at 11am needs a different message from the customer whose address the courier could not find. Sending the same message gets you the worst of both worlds: too generic to be useful, and customers who feel like they are talking to a bot.
Build separate approved templates for at minimum: customer not available, address not found, and phone unreachable. Approvals through WhatsApp BSPs (Interakt, WATI, AiSensy, Gupshup) take 24 to 72 hours. Build them before you need them.
Lever 3: Add an AWB hold + confirmed reattempt slot
Sending a WhatsApp asking the customer to confirm a new time, while the courier simultaneously runs its default automatic reattempt at the same time of day as the original failed attempt, is a broken flow. You are asking the customer for input that the courier will ignore anyway.
The correct setup: pause the automatic reattempt for 12 to 18 hours via the courier's NDR action API, wait for customer confirmation, then push the confirmed slot to the AWB. Delhivery's NDR Package Action API supports this directly. Shiprocket and ClickPost both expose NDR action endpoints that do the same.
Customer-confirmed reattempts succeed at roughly double the rate of unconfirmed automatic reattempts. [VERIFY: ClickPost operational data] The extra step is worth it.
Lever 4: Build no-response fallback rules
A WhatsApp flow with no no-response logic is not really a flow. It just sends a message and waits. You need:
- 6-hour SMS fallback: If no WhatsApp response after 6 hours, send an SMS with the same core message and a callback number.
- 12-hour default-to-evening: If no response on any channel after 12 hours, release the AWB hold and default the reattempt to the 5pm to 8pm window. This at least shifts the timing from the original failed attempt, which improves reattempt success even without customer confirmation.
- 18-hour ops escalation: Flag for manual review if the NDR is still unresolved. Some of these need a human decision (repeated NDR customer, address change to different pincode, high-value COD above ₹2,000).
Lever 5: Track and iterate by reason code weekly
Recovery rate by reason code should be a weekly number, not a monthly one. NDR patterns shift fast: a courier change in one pincode, a seasonal buying pattern, or a product category launch can move your recovery distribution meaningfully.
| Track weekly | What a drop signals |
|---|---|
| Recovery rate on "not available" NDRs | Trigger timing issue or template template problem |
| Recovery rate on "address not found" NDRs | Address collection at checkout getting worse, or a specific courier struggling in a pincode cluster |
| Time-to-first-WhatsApp after NDR | Webhook reliability issue, or ops team has been manually triggering instead of relying on automation |
| WhatsApp response rate within 2 hours | Template quality or Tier-2/3 language mismatch |
| Confirmed-reattempt-to-delivery rate | Courier not honoring confirmed slots, or slot window too narrow |
Order value and COD: where to set thresholds
Shipway's data puts the worst COD RTO rates in the ₹500 to ₹1,000 band (around 28% RTO) — the impulse purchase zone. Below ₹500 runs at ~25%, above ₹1,000 at ~24%, because the customer made a more considered purchase at higher values.
For NDR recovery, the practical threshold is around ₹2,000 COD. Below that, automated follow-up is enough. Above ₹2,000 COD, a real ops call often converts better than another WhatsApp. The math holds up: the value of recovering a ₹3,000 COD delivery is high enough to justify 5 minutes of ops time; the same is not true for a ₹499 impulse order.
Set a rule in your escalation logic: COD orders above ₹2,000 with no WhatsApp response after 6 hours go to ops for a manual call. Everything below stays automated. [INTERNAL LINK: reduce COD returns India]
Where Checkout Fits Into This Picture
The NDR recovery work covered in this post starts after the shipment has left your warehouse. That is important but it is the second half of the problem.
The first half is what happens at checkout. A significant portion of NDRs — the refused deliveries, the changed-mind cancellations — started as low-intent COD orders placed because there was no friction to placing them. Shifting more orders to prepaid at the time of purchase removes those shipments from the NDR funnel entirely. They never become NDRs because the customer has already committed money.
Platforms like OneflowAI work on this upstream layer: smarter checkout flows that nudge high-risk COD buyers toward prepaid with the right incentive at the right moment, and address validation that catches bad addresses before dispatch rather than after a courier has already tried to deliver. The downstream NDR work is still necessary, but reducing the volume of bad orders entering the system makes every other part of the ops stack easier.
FAQ: NDR Recovery Rate Benchmarks
What is a good NDR recovery rate for Indian D2C brands?
40 to 55% is solid for a brand with working automation (webhook trigger, specific templates, basic reason-code branching). 55 to 65% is mature and above average. Below 30% usually means the trigger is too slow, the template is too generic, or both. Above 65% requires pincode-level and courier-level tuning, not just standard automation.
What is the average RTO rate in India for D2C brands?
About 21% during normal periods, based on Unicommerce's 2026 report across 410 million shipments. It spikes to roughly 39% during the festive quarter. COD-specific RTO runs at 26% (Shipway ShipNotes). Prepaid is under 2%.
Which NDR reason code has the highest recovery rate?
"Customer not available" recovers at 55 to 70% with a good WhatsApp flow firing within 60 minutes and an evening slot option. "Customer refused" recovers at under 15% regardless of outreach quality. These two extremes define where your effort should and should not go.
Do NDR recovery rates differ between Tier-1 and Tier-2 cities?
Yes. Tier-1 brands typically hit 50 to 65% recovery with mature automation. Tier-2 lands at 40 to 55%, and Tier-3 at 30 to 45%. The gap is driven by address quality, WhatsApp response speed, and courier SLA consistency. Hinglish templates and evening delivery defaults close a meaningful portion of the Tier-2 gap.
How does order value affect NDR recovery for COD orders?
The ₹500 to ₹1,000 range has the highest RTO rate (~28%) because it is the impulse-purchase zone. Recovery for COD orders above ₹2,000 benefits from real ops calls rather than automated-only follow-up.
How quickly should I trigger NDR recovery outreach?
Within 30 to 60 minutes of the NDR webhook. Recovery probability at under 30 minutes: 40 to 55%. At 24 hours (next-day ops review): under 10%. The timing difference is the single biggest variable in NDR recovery performance.
What is the best way to benchmark my own NDR recovery rate?
Track it by reason code (not as a single aggregate), by pincode tier, and by courier. Your "customer not available" recovery in Mumbai and your "address not found" recovery in Kanpur are telling you very different things. Mixing them into one number loses the signal.
Can I improve NDR recovery without a developer?
For brands under 1,000 orders a month: yes, Shiprocket's built-in NDR management plus Interakt or WATI handles the basics. For brands above 2,000 orders a month, webhook-based triggers and reason-code routing typically need 5 to 10 hours of developer work. The webhook-to-WhatsApp pipeline is where most of the recovery uplift lives, and it is worth the setup cost.
How does ClickPost's automated NDR compare to manual management?
ClickPost published data showing 40% reduction in failed deliveries with their AI-powered NDR suite. Manual ops follow-up (next-morning calls) typically produces recovery rates under 20%. The gap is almost entirely explained by timing. Automation fires in minutes; the ops team gets there the next morning.
What is the NDR recovery rate I should target in 6 months?
Starting from under 25%: target 40 to 45% in the first 60 days with basic automation (webhook trigger, specific templates, no-response fallback). Target 50 to 55% by month 6 with reason-code routing and AWB hold logic. If you start above 40%, the focus should be on "customer not available" specifically and on Tier-2/3 Hinglish templates.
NDR recovery rate is one of the most undertracked numbers in Indian D2C operations. Most brands know their overall RTO rate. Very few know their recovery rate by reason code. And fewer still know how their numbers compare against brands in the same category and pincode tier.
The benchmarks in this post give you a starting point. The diagnostic is straightforward: pull your last 90 days of NDR data, split it by reason code, check your trigger timing, and compare the recovery rate per reason against the ranges above. That exercise will tell you within 20 minutes where the gap is and what to work on first.

