Customer Unavailable NDR: An Indian Seller Data Study
A courier export from a WhatsApp-and-call-led seller shows why the buyer's account matters when a delivery attempt is disputed.
October 24, 2026 · Measured case study
Quick answer
“Customer unavailable” is a courier-reported reason for a failed delivery, not an independently checked finding about the buyer. This data study describes an anonymous Indian seller's courier export. It separates shipment outcomes from repeated failed-delivery reports and shows where the supplied figures need caution.
What the shipment summary reports
The measured export covers 2,996 shipped orders from Aug 2025-Aug 2026, described in the source as a 12-month courier export. Its summary reports that 2,672 reached a final status. Outcome figures supplied are 1,848 delivered, 785 returned to origin (RTO), 39 RTO in transit and 24 lost. The reported RTO rate is 30.8%.
These are source-reported figures, not a newly reconciled partition of all shipments. The supplied outcome and final-status totals do not fully align. RTO in transit also differs from a return physically received. We retain the values as supplied and do not force them into a pie chart or silently redefine the reported final-status count.
Returns differed by payment mode
The COD row reports 838 of 2,573 returned, or 32.6%. The prepaid row reports 5 of 136 returned, or 3.7%. The prepaid sample is small. The payment-mode rows use supplied group denominators that do not reconcile to the shipped-order summary, so they should not be used to reconstruct the whole export.
- COD: 838 of 2,573 returned32.6%
- Prepaid: 5 of 136 returned; small sample3.7%
The difference is descriptive. It does not prove that changing payment mode would produce the same return reduction for this seller or anyone else. Buyers choosing prepaid may differ from COD buyers, and the export summary does not control for product, destination, order value or service. Use it as a reason to investigate your own process, not as a promised result.
Failed-delivery reports were dominated by one remark
The export records 4,192 failed-delivery reports, also called NDR events. Of these, 98.8% carried the reason “customer unavailable”. The supplied follow-up figure is 24 later delivered, reported as 0.6%. This is an event-based observation; multiple reports can belong to the same parcel.
The dominant remark says what the courier system recorded. It does not establish that buyers were absent or that delivery agents made false reports. The follow-up figure likewise does not measure a unique-shipment recovery rate or an improvement caused by automation. A useful review would match each event to the buyer's account, submitted request and subsequent tracking history.
Aggregator risk labels and observed RTO
Observed RTO was 27.3% for low-risk orders, 43.4% for high-risk orders and 77% for very-high-risk orders. The very-high group contained only 26 orders over the year. These are the aggregator's risk labels; the study does not recreate, calibrate or independently validate its scoring method.
- Low-risk27.3%
- High-risk43.4%
- Very-high risk; only 26 orders/year77%
A low-risk label still calls for ordinary confirmation and delivery follow-up. The small very-high group should not become a blanket rule for rejecting buyers. Compare risk labels with your own outcomes and costs, keeping the sample size and any missing labels visible.
Highest reported RTO pincode-prefix zones
Among zones with at least 80 orders, the highest reported rates were 84xxxx at 39.8%, 41xxxx at 39.6%, 39xxxx at 39.1% and 85xxxx at 38.4%. These are masked pincode prefixes. No state names or finer location claims are inferred from them.
- 84xxxx39.8%
- 41xxxx39.6%
- 39xxxx39.1%
- 85xxxx38.4%
The ranking describes this seller's shipment mix and the reporting period. It does not establish that a whole region is unsuitable for delivery. Courier availability, the buyer mix and order handling can affect outcomes. A seller reviewing routes should keep the underlying order counts and eligibility rules beside any percentage.
A manual way to investigate your own export
- Keep the original export and document its period, status definitions and filters.
- Build a shipment list by AWB, then attach repeated failed-delivery events without counting them as new parcels.
- Separate delivered outcomes, return journeys, checked return receipts and lost cases.
- Compare payment groups using stated denominators and retain unknown or unmatched rows.
- Review disputed remarks against timestamped buyer replies, courier requests and final tracking events.
Key takeaway
A reason label should begin an investigation. The operational handoff is the buyer's account, a supported request and a checked outcome. Read the customer-unavailable dispute checklist for evidence to retain, or the NDR reason guide for the questions to ask.
Questions about the study
Does customer unavailable prove the buyer was absent?
No. It is the courier-reported reason in the export. The study does not independently verify visits, calls or buyer availability and cannot classify these events as proven fake attempts.
Is this an Indian ecommerce benchmark?
No. It describes an anonymous operation in a single category. Its order mix, payment mix, routes and courier reporting may differ from another seller's. The prepaid group is small.
Are NDR events the same as undelivered parcels?
No. A parcel can generate repeated failed-delivery reports. Event totals must not be treated as a count of unique shipments or used with an unrelated shipment denominator.
Does the study measure an RxFlow recovery improvement?
No. These observations describe the supplied courier export. There is no controlled before-and-after comparison or audited attribution to software, staff or a particular follow-up method.
For the connected workflow, see NDR automation for Instagram and WhatsApp sellers.