An NDR, or non-delivery report, is the courier telling you a delivery attempt failed. The parcel is still in the network. The customer still wants it. Nothing is lost yet. But every RTO starts as exactly this: an NDR that nobody worked in time. That is the whole argument for treating NDR management as its own process, with its own queue, its own clock, and its own owner.
The volume is not small. Across Indian e-commerce, 15-20% of orders generate an NDR at some point. For a brand shipping 4,000 parcels a day, that is 600-800 cases a day sitting between “attempt failed” and “sent back.” Couriers like Delhivery, Xpressbees, Ekart and Blue Dart typically make around three delivery attempts before marking a shipment for return to origin. The gap between the first failed attempt and the RTO trigger is the recovery window, and it is usually measured in hours to a few days. What happens inside that window decides whether the parcel is delivered or comes back at your cost.
NDR vs RTO: the difference is a window
Teams often talk about NDR and RTO as one problem. They are not. RTO is the outcome: the parcel travels back, and you pay forward freight, reverse freight, packing and handling, commonly ₹150-₹250 per parcel on a typical COD shipment, before counting the lost sale. NDR is the warning that the outcome is approaching. It is the only stage where the parcel can still be saved at low cost.
This distinction matters because the two stages need completely different responses. RTO reduction is a portfolio problem: courier allocation, COD confirmation, and address quality at checkout. NDR management is a case-by-case race against a short clock. A brand can have a good RTO programme and still leak margin every day because nobody works the NDR queue before the second attempt fails.
Where the recovery window actually goes
Open any NDR case and the work required is almost never complicated. It is follow-up, and it falls into three buckets.
- Customer unreachable. The rider called, nobody picked up, the attempt was logged as failed. The fix is reaching the customer on a channel they actually answer, which in India means WhatsApp, and agreeing a time when someone will be home.
- Address clarification. The pin code is right but the landmark is wrong, the flat number is missing, or the delivery location has changed. The fix is a confirmed, corrected address pushed back to the courier before the next attempt, not after it.
- Re-attempt scheduling. The customer asked for delivery after 18:00, or on Saturday, or at the office instead. The fix is getting that instruction into the courier’s system so the next attempt is planned, not another coin toss.
None of this needs judgment calls or senior people. It needs speed and completeness. And that is exactly where the window is lost. The NDR lands in a report or a courier portal at 11:00. Someone downloads it in the evening, or the next morning. The customer gets a call a day later, from a number they do not recognise, which they do not answer. Meanwhile attempt two has already failed on the same bad information. By the time a person is working the case, the case is already over.
The arithmetic of a slow queue
Run the numbers once, on your own volumes. Take the brand shipping 4,000 parcels a day with an 18% NDR rate: about 720 cases a day. Suppose half of those would recover with a same-day call or WhatsApp message and a confirmed re-attempt, which is a conservative read of reason codes like customer-unreachable and address-issue. That is 360 parcels a day whose fate is decided by follow-up speed. If slow follow-up converts even a third of them to RTO, that is 120 avoidable returns a day, at ₹150-₹250 each in freight and handling alone. That is ₹18,000-₹30,000 leaking daily, roughly ₹5-9 lakh a month, before the lost sales and the festive-season spike that doubles the queue.
The same arithmetic explains why hiring more people to call customers rarely fixes it. Volume scales, headcount scales, and the queue still waits for someone to pick each case up. The bottleneck is not effort. It is that the follow-up starts late, on incomplete information, one case at a time.
What good NDR management looks like
Teams that keep NDR-to-RTO conversion low do the same few things, and none of them are exotic.
- Reason-coded queues. Every NDR is classified by the courier’s reason code the moment it lands: customer unreachable, address incomplete, customer refused, delivery rescheduled. Each reason has its own queue, its own script and its own clock. “Customer refused” is a different problem from “door locked,” and treating them alike wastes the window.
- Same-day contact on WhatsApp. The customer gets a message within hours of the first failed attempt, on a channel with near-universal open rates in India, with simple options: confirm the address, pick a time slot, or share a landmark. This is one of the proactive shipment notifications that prevents a support ticket and a repeated failed attempt at the same time. A call from an unknown number can wait. The message cannot.
- Re-attempt with confirmed details. The corrected address or agreed slot goes back to the courier before the next attempt is planned. An attempt made on confirmed information is worth three made on stale information, because that is roughly how many attempts you have.
- Early escalation on the cases that will not recover. A refused COD parcel from a repeat-canceller is not going to convert. Flagging it early stops you spending follow-up hours on it and lets the return start before the third attempt burns more freight time.
Notice what is absent from this list: nothing here requires a new courier, a new WMS, or a new dashboard. It requires each case to be opened, classified, contacted and updated the same day, every day, at whatever volume the season brings.
Where agents and supervisor approval fit
This is the shape of work that forward-deployed agents handle well, because the hard part is not the decision. It is doing a hundred small, timed follow-ups without dropping any. The sequence mirrors how we approach any operations process at Proxima: map first, prove suggestions, then earn autonomy.
In practice it looks like this. The agent reads NDR events as they land from Delhivery, Xpressbees, Ekart or Blue Dart, classifies each case by reason code, and drafts the recovery: the WhatsApp message to the customer, the address correction, the re-attempt instruction to the courier. In Shadow mode it does all of this without sending anything, and every draft is scored against what your team actually did. Once a category proves accurate, it moves to human-in-the-loop: a supervisor sees the queue each morning, approves the day’s messages and re-attempt instructions in one pass, and anything unusual stays flagged for a person. Categories with a long clean record can run on autopilot within agreed limits: standard address confirmations and slot re-bookings go out on their own, while refusals, high-value orders and repeat failures always route to a human.
The supervisor’s role changes rather than disappears. Instead of spending the day dialling customers, they spend twenty minutes approving a prepared queue and their judgment goes into the cases that actually need it. The approval rules and limits are set with your team and can be tightened or loosened at any time.
What good looks like after a few weeks
The NDR report stops being an evening summary of things that already went wrong and becomes a morning queue of things that can still be saved. First-attempt failures get a customer message within hours. Second attempts go out on confirmed addresses and agreed slots, so they convert instead of compounding. The team reviews one number every week: NDR-to-RTO conversion by reason code, and argues about categories, not individual cases.
The RTO rate does not drop to zero, because some returns were always going to happen. But the avoidable third, the parcels that came back because nobody reached the customer in time, stops being a fixed cost of doing e-commerce in India. Festive season still doubles the NDR volume. It no longer doubles the leak, because the follow-up does not depend on how many people you could hire in October.
What this does not fix
Courier reason codes stay messy. One courier’s “customer unreachable” is another’s “consignee not available,” codes get misused, and some riders log a failed attempt that never happened. Good NDR management works around this reality; it does not clean it up, and fake-attempt patterns are a courier-performance conversation, not a follow-up problem.
It also does not fix intent. A customer who never wanted the parcel, or ordered COD with no plan to pay, will not be saved by a faster WhatsApp message. That is upstream work: COD confirmation before dispatch, address quality at checkout, courier allocation. NDR management recovers the deliveries that can be recovered. It does not make bad orders good.
Every RTO on your dashboard this month started as an NDR that sat too long. The window is short, the work is ordinary, and that is exactly why it is worth systematising: ordinary work, done the same day, at full volume, is what decides whether the parcel arrives or comes back.
If you want the size of the leak before anything else: the RTO cost calculator turns your orders, COD share and RTO rate into the monthly number in about ten seconds.