NDR Management: What It Is and How Indian Brands Handle It

Wednesday, 11 am. Your ops person opens the Shiprocket panel and finds 47 shipments sitting in the action-required queue. Some are from Monday.

She works through them the way anyone would: clicks reattempt on everything, adds "please deliver" in the remarks, closes the tab. It takes twenty minutes and feels like the job is done.

On Friday, 31 of those 47 come back as RTO. The courier reattempted with exactly the information it had the first time, at roughly the same hour, to the same address where nobody was home. Nothing changed between attempt one and attempt two except that you now pay freight in both directions on 31 orders.

That is what unmanaged NDR looks like, and it is closer to the norm than most founders think. Around 20 to 30% of India's daily shipments fail on the first attempt, higher in Tier 2 and Tier 3 pincodes. The first attempt failing is not the problem; every courier expects some of that. The problem is the 48 hours afterwards, where the shipment is still alive, the customer still remembers ordering, and nobody does anything useful with either fact.

NDR management is the work in that gap. This piece covers what an NDR actually is, what the reason codes mean in plain terms, and the four ways Indian brands handle it, so you can work out which one you are on and whether it is the one you want.

---

What an NDR actually is

Shiprocket describes it as a receipt showing the orders that could not be delivered and why. That is accurate but undersells what it is operationally. An NDR is a request for instructions.

The rider reached the address, something went wrong, and the courier's system now needs to know what to do with the parcel before it tries again. If you send nothing back, it tries again on the same information. If it runs out of attempts, the parcel turns around.

The confusion is not academic. Brands that treat NDR as an early warning of RTO watch it. Brands that treat it as a live task with a deadline fix it. Different numbers at the end of the quarter.

One more thing worth being clear about. An NDR is not a complaint and not a service failure on the courier's part, most of the time. The rider genuinely could not complete the delivery. Sometimes that is the courier's fault, and phantom attempts do happen, which we cover in our guide to recovering wrong RTO deductions. But the majority of NDRs are ordinary: somebody was at work, an address was missing a landmark, a customer had second thoughts about a ₹1,400 COD order. Ordinary and fixable are not opposites.

---

The lifecycle: scan to RTO

Knowing where the decision points sit is most of the job. Here is the sequence on a typical Indian COD shipment.

Three is the standard attempt count across Delhivery, Bluedart, Ekart and Xpressbees, and Shiprocket documents a maximum of three before RTO. Some couriers allow a fourth when the seller supplies updated customer details, which is worth knowing because it is a lever you can pull on a high-value order.

The action window is the only row in that table where you appear. Courier SLAs in India typically leave 24 to 48 hours between attempts, and ClickPost research cited by Amazon Shipping India puts the practical cutoff at 36 hours: past that, a failed delivery almost always ends in RTO regardless of what you do afterwards.

That is the part brands miss. Doing nothing is not neutral, and it is not a delay. It is an instruction, and the instruction is "try the identical thing again".

---

Reason codes, decoded

Every NDR carries a reason code. Wording varies by courier, but almost everything sorts into six buckets, and each one needs a different response.

The one that matters most

Customer not available is consistently the biggest bucket, reported at roughly 35 to 40% of all NDRs. It is also the easiest to fix, because nothing is actually wrong. The customer wants the order, the address is right, and the parcel arrived while they were at work.

A reattempt at the same hour the next day fails for the identical reason. A reattempt at a time they confirmed does not. That single change is the highest-yield thing in NDR management, and it is why we wrote separately about evening delivery reattempts.

The one people misread

Customer refused gets logged more often than customers actually refuse. Riders under route pressure use it as a catch-all, and a genuine refusal looks identical in the data to a rider who never reached the door.

Worth a call before you accept it, particularly on prepaid orders where a refusal makes little sense. If refusals cluster on one route or one rider ID, that is a courier conversation, not a customer problem.

---

Why NDRs go unhandled

Ask a founder who owns NDR at their brand and you usually get a pause. That pause is the answer.

NDR sits in a gap. Customer support owns tickets, and an NDR is not a ticket because the customer has not complained. Warehouse owns despatch, and the parcel already left. Finance sees it only later, as a return freight line on an invoice. It belongs to everyone and therefore to nobody.

The second reason is that the work is unrewarding. A resolved NDR produces no visible win: the order simply delivers and nobody notices. An unresolved one produces an RTO nobody notices either, because it lands in a monthly return freight total rather than as a named failure. Both outcomes are invisible, which is a bad setup for anything you want done consistently.

Third, the deadline is invisible too. Nothing in a panel says "you have 14 hours left on this AWB". The queue looks identical whether an NDR was raised this morning or the day before yesterday, and the older one is already lost.

Which is why the fix is rarely "try harder". It is making the work owned, visible and time-stamped, and that is what separates the four models below.

---

The four ways brands handle NDR

Almost every Indian D2C brand runs one of these. Most did not choose it deliberately, which is the main thing worth changing.

Model 1: leave it to the courier

No process. NDRs raise, the courier reattempts on its own schedule, and RTOs arrive at the warehouse as a surprise. Some couriers and aggregators run automated IVR calls to the customer, so this is not literally nothing, but nothing on your side.

What it costs: the entire recoverable bucket. Customer-not-available NDRs, which are 35 to 40% of the total and the easiest to save, convert to RTO at close to the base rate because nobody ever asks the customer when they will be home.

When it is defensible: under a few hundred orders a month, or a fully prepaid catalogue where NDR volume is genuinely small. Not defensible at 4,000 orders on COD.

Model 2: work the aggregator panel

Someone opens the Shiprocket or Shipway action-required queue daily and clicks through it. This is where most brands actually are.

It is a real improvement over Model 1, because at least the reattempt is requested rather than defaulted. But it has a structural hole: the panel lets you tell the courier what to do without ever talking to the customer. Clicking reattempt on a customer-not-available NDR sends the rider back with no new information, which is exactly the Wednesday-to-Friday sequence at the top of this piece.

The panel is a queue, not a process. It tells you which shipments need a decision. It cannot make the decision well, because the input it needs, what the customer says, lives outside it.

Model 3: the manual ops sheet

A person exports the NDR list every morning, calls or WhatsApps each customer, records what they said, then updates the courier panel with a corrected address or a confirmed slot.

Done properly this works. It is the first model where the customer is actually in the loop, and the recovery difference over Model 2 is large. A disciplined person with a morning routine and a shared sheet genuinely outperforms a badly configured automation.

It has two ceilings. The first is arithmetic: one person can work maybe 40 to 60 NDRs a day at any useful quality, so somewhere past a thousand orders a month the queue outgrows them. The second is the window. A morning-only routine means an NDR raised at 2 pm waits until 10 am the next day, which has burned 20 of your 36 hours before anyone touches it.

Model 4: webhook and automated outreach

The courier's NDR webhook fires the moment the code is raised. A WhatsApp goes out within minutes, branched by reason code. The customer's reply, a slot or a corrected address, flows back and updates the courier automatically. A human handles only the exceptions.

The gain is not that it is cheaper per NDR, though it is. The gain is latency. Minutes instead of hours means you reach the customer while the failed delivery is still a live memory, and the reply rate at that moment is not comparable to a call the next morning.

The catch is that it is a build, not a switch. You need webhook access from your courier or aggregator, a WhatsApp business account, approved templates per reason code, and rules for what happens when nobody replies. Our comparison of manual versus automated NDR follow-up has the cost side, and the WhatsApp setup guide covers the templates.

Picking one honestly

Most brands reading this are on Model 2 and think they are on Model 3. The test is simple: on your last ten NDRs, did anyone speak to the customer before requesting the reattempt? If not, you are clicking a queue.

The upgrade path is also not what people expect. Going from 2 to 3 is a bigger jump in recovered orders than going from 3 to 4, and it costs nothing but a person and a routine. Fix the process manually first. Automating a process you have not run by hand tends to encode whatever was wrong with it.

What good handling looks like on one NDR

Nothing clever happened there. One question, one answer, one instruction the courier could act on, all inside an hour. That is the whole discipline, and the full sequence with reason-code branching is in our NDR recovery playbook.

---

What good looks like

Two of those are outcomes and two are process. Watch the process ones, because they move first and they are the only ones you directly control. Time to first contact in particular predicts the rest: brands that pull it under four hours see the NDR rate follow within a quarter.

For context on the wider trend, Unicommerce and Shipway tracked RTO rates falling from around 39% at the November 2025 festive peak to roughly 21% by February 2026, across 410 million shipments and 6,000 brands. COD orders returned at 58% during that festive quarter against under 15% for prepaid. NDR handling is one of the levers inside that gap, and prepaid conversion is the other.

On recovery rate specifically, meaning the share of NDRs you turn into deliveries, benchmarks vary too much by category and payment mix to quote a single number safely. Track your own by reason code for a quarter and use that as the baseline. Our NDR recovery rate benchmarks post breaks down the ranges by code and city tier.

---

Frequently asked questions

What is the full form of NDR?

Non-Delivery Report. It is the record a courier raises when a delivery attempt fails, naming the shipment and why it could not be delivered. It sits on a live shipment, which is what separates it from an RTO.

What is NDR management?

Responding to failed delivery attempts before the shipment runs out of attempts. In practice: read the reason code, contact the customer, get a corrected address or a confirmed slot, and push that back to the courier inside the action window.

What is the difference between NDR and RTO?

An NDR is a failed attempt on a shipment still out for delivery and still recoverable. An RTO is what happens once attempts are exhausted: the parcel comes back and you pay freight both ways. Every RTO started as an NDR nobody resolved.

How long do I have to respond to an NDR?

Courier SLAs in India typically leave 24 to 48 hours between attempts. ClickPost research cited by Amazon Shipping India puts the practical cutoff at 36 hours from the NDR being raised. Aggregator panels also default to another attempt, or to RTO, if you do not action it.

How many delivery attempts before RTO?

Three is standard across Delhivery, Bluedart, Ekart and Xpressbees, and Shiprocket documents a maximum of three. Some allow a fourth when you supply updated customer details. Check your signed rate card, because negotiated terms differ from published policy.

What are the most common NDR reason codes in India?

Six buckets cover almost everything: customer not available, customer refused, address incorrect or incomplete, customer unreachable, COD payment not ready, and pincode not serviceable. Customer not available is the largest at roughly 35 to 40%.

What is a good NDR rate for an Indian D2C brand?

Under 10% overall is strong. COD-heavy brands commonly sit at 20 to 30%, and a disciplined workflow pulls that to 12 to 15%. If prepaid is not materially lower than COD in the same catalogue, your problem is address quality rather than payment intent.

Does my courier or aggregator already handle NDR for me?

Partly. Shiprocket and others surface NDRs in an action-required queue and some run automated calling. What they cannot do is know your customer, judge whether a refusal is genuine, or decide an order is worth a fourth attempt. The panel gives you the queue; the judgement stays yours.

Is WhatsApp better than a phone call for NDR follow-up?

WhatsApp scales and a call converts. Lead with WhatsApp because it reaches everyone in minutes and leaves a written record of what the customer agreed to, then call the high-value or unresponsive cases. Email is not a channel for this in India.

At what volume does NDR management need automation?

When your daily NDR count exceeds what one person can action inside the window, which for most brands is somewhere past a thousand orders a month. Below that, a disciplined person with a morning routine beats a badly configured tool.

---

The short version

An NDR is a request for instructions with a deadline attached. Send nothing and the courier reattempts on the information that already failed.

Start by finding out which model you are actually on. Pull your last ten NDRs and check whether anyone spoke to the customer before the reattempt was requested. If not, you are on Model 2 and the cheapest available improvement is a person, a morning routine and a rule that every NDR gets a customer contact before it gets a courier click.

Then work on latency rather than effort. Time from NDR raised to first customer contact moves everything downstream, and getting it under four hours matters more than what the message says.

Past a few thousand orders a month the window closes faster than a human queue can clear it, and that is where OneflowAI takes the routing and the follow-up off the ops desk. The four-hour rule works the same either way, and any brand can start on it with a shared sheet this week.

Open your NDR queue and sort by timestamp, oldest first. Anything raised more than 36 hours ago is already gone. Everything above that line is still yours.