Pincode serviceability and RTO in India are two different questions. Serviceability asks whether a courier will accept a parcel for a pincode; RTO risk asks how often parcels to that pincode come back. A pincode can be serviceable and still lose you money, so you need your own failure data, grouped sensibly, before you set rules by zone.
This guide shows how to read pincode failure patterns from your own orders, why single pincodes mislead and how to group them, how to judge whether a zone's rate is real or noise, how to price each zone against your break-even point, and how to turn the result into rules. All worked data is invented and labelled as such; use it as a template for your own export.
Quick answer: For pincode serviceability and RTO in India, export your orders with pincode, payment mode, courier and outcome, group pincodes into zones with enough orders, compute each zone's RTO rate with a confidence range, compare it with your break-even RTO rate and set rules (open, confirm, limit or prepaid-only) per zone. Re-run monthly and ignore zones with too few orders to judge.
Serviceability is not the same as low risk
Serviceability is a courier statement: it can pick up from your origin and deliver to a destination pincode, possibly with separate flags for prepaid and COD. If either pincode is outside coverage, Delhivery's rate calculator tells you so; its help page says that if either pin code is non-serviceable you will see the message that the pin code is not serviceable. That is useful at checkout, because it prevents you accepting an order you cannot ship. Our guide to delivering to all pincodes explains how coverage works across partners.
Risk is an outcome statement: of the parcels you shipped to a place, how many came back. A serviceable pincode with poor address quality, repeated failed attempts or strong refusal behaviour can have a high RTO rate. The two datasets answer different questions and should be kept apart in your analysis. Serviceability data comes from couriers and changes when their networks change; risk data comes from your own orders and changes when your products, prices, ads and buyers change.
What the six digits of a PIN tell you and what they do not
Before grouping pincodes it helps to know how they are built. Wikipedia's article on the Postal Index Number explains that the first digit of a PIN indicates the zone, the second the sub-zone, and the third, combined with the first two, the sorting district; the final three digits identify individual post offices within the sorting district.
The same article lists how the first digit maps to regions. As read on 14 October 2026, a leading 1 covers Delhi, Haryana, Punjab, Himachal Pradesh and Jammu and Kashmir; 3 covers Gujarat and Rajasthan; 4 covers Maharashtra, Madhya Pradesh, Chhattisgarh and Goa; 5 and 6 cover the southern states; 7 covers West Bengal, Odisha and the north-eastern states; and 9 is reserved for the Army Postal Service.
This structure gives ready-made grouping keys, but a single leading digit is far too coarse for risk: digit 7 mixes Kolkata with remote hill districts. Two digits are usually the right starting level, and three digits (a sorting district) the finest worth using. A PIN says where a post office is; it says nothing about whether an address is complete or the buyer is home.
What an RTO is and where it sits in the delivery lifecycle
Delhivery's help centre defines RTO as a sale order that was undelivered and returned to the client warehouse, for example because the client cancelled the order while it was in transit or the consignee rejected it at the door. The same page shows where to track these in its panel: orders being returned appear as returning to origin, and those that have reached your warehouse as returned.
Before a parcel becomes an RTO, a failed attempt appears as a non-delivery report, or NDR. Delhivery's help page says a seller can opt for reattempting delivery three times for a forward shipment, and that if the third attempt also fails the shipment moves to RTO. The same page lists the actions available on an NDR: reattempt, return to origin, and viewing or editing consignee details. Shiprocket's support pages describe the same concept: an order the courier could not deliver to the customer, with options to reattempt, contact the buyer or initiate a return to origin.
Not every stuck parcel is an NDR in the narrow sense. Delhivery's page on shipment exceptions separates cases where a shipment is stuck in transit and needs seller input: damaged shipments, a missing e-waybill, consignee details that are incorrect or unreachable, and payment disputes such as a prepaid order whose label says COD. For the consignee-details exception it notes that a corrected address must belong to the same pincode, which is a useful reminder that a wrong pincode at checkout cannot be fixed by editing the street. All of these appear together in the courier's Exceptions and NDR view.
The reasons behind failed deliveries
The reasons recorded against a failed attempt are the best clue to the cause. They differ by courier, but fall into a few families that call for different fixes. Treat the courier's reason codes as hints, not proof: they are entered by delivery staff and can be vague.
| Failure family | Typical reason text | What it suggests | Likely remedy |
|---|---|---|---|
| Buyer refused | Consignee refused, order cancelled at door | Weak buying intent, mismatch with expectation, COD risk | Confirmation message, prepaid nudge, clearer product information |
| Not reachable | Phone off, no response, premises closed | Wrong or unattended number, timing | Verify number at order, ask delivery window, respond fast to NDR |
| Address problem | Incomplete or wrong address, cannot locate | Poor address capture; some areas hard to locate | Mandatory landmark, validation at checkout, pin-level notes |
| Courier-side | Delivery not attempted, hub delay | Network performance in that lane | Courier choice by zone, escalation, freight refund claim where eligible |
| Payment mismatch | Prepaid order labelled COD, wrong amount to collect | Order data error between store and courier | Fix the order sync; check how your courier assigns payment mode |
The last row deserves attention because it is entirely self-inflicted. Delhivery's help page on COD versus prepaid assignment explains that its platform assigns a payment mode to orders fetched from a sales channel, and for Shopify maps a Paid status to Prepaid and Pending or Partially Paid to COD, with any other status leaving the mode blank until you assign it. The lesson is general: if your store marks partially paid orders in a way your courier reads as COD, you will see disputes at the door that look like buyer behaviour but are data errors.
Record the failure family for every RTO and NDR you can. A zone with a high RTO rate caused by courier-side failures needs a courier change, not a COD rule, and the data will show the difference.
Why single pincodes mislead
If you ship 12 parcels to one pincode and 4 return, you have a one-in-three rate and almost no information. Small counts swing wildly: one more return moves the rate by eight points. Most small stores see a few hundred pincodes with only a handful of orders each, so a pincode-by-pincode rule set mostly encodes noise and will punish buyers unfairly.
Statisticians handle this with a confidence interval around the observed rate. Wikipedia describes the idea in its article on the binomial proportion confidence interval and documents the specific method used in this guide, the Wilson score interval, which behaves sensibly at small counts and near zero. A related article on sample size determination explains why larger samples are needed to detect smaller differences. You do not need to do the arithmetic by hand: a spreadsheet or a short script will do it. What you need is the habit of asking how sure you are before you act.
The table below shows how wide the 95 per cent Wilson range is when the observed RTO rate is 20 per cent, for different numbers of orders. The figures are computed from the formula and are illustrative of the method, not of any store.
| Orders in the zone | Returns at a 20% rate | 95% range | Width of range |
|---|---|---|---|
| 25 | 5 | 8.9% to 39.1% | 30.2 points |
| 50 | 10 | 11.2% to 33.0% | 21.8 points |
| 100 | 20 | 13.3% to 28.9% | 15.6 points |
| 200 | 40 | 15.0% to 26.1% | 11.1 points |
| 400 | 80 | 16.4% to 24.2% | 7.8 points |
| 800 | 160 | 17.4% to 22.9% | 5.5 points |
Reading the table: with 25 orders, a true rate anywhere from about 9 to 39 per cent is consistent with what you saw, which is too wide to support any rule. With 200 orders the range narrows to roughly 11 points, which is enough to tell a 10 per cent zone from a 30 per cent zone. Because the width shrinks only with the square root of the order count, quadrupling your volume merely halves the uncertainty. This is why grouping is the main lever for small stores.
What to do when a zone has no returns at all
A zone with zero returns is not a zero-risk zone. Wikipedia's article on the rule of three states that if an event did not occur in a sample of n subjects, the interval from 0 to 3/n is a 95 per cent confidence interval for the rate. With 50 orders and no returns, that gives an upper bound of 3/50 = 6.0 per cent; the Wilson interval for 0 of 50 is slightly wider, 0.0 to 7.1 per cent. Either way, a clean first batch of 50 orders supports "probably low", not "none".
Build the export: the columns your analysis needs
Everything in this guide runs from one flat table with one row per order. Your store, your courier panel and your payment records each hold part of it; you will usually join them on the order number or AWB. A minimal layout is shown below.
| Column | Source | Why it is needed |
|---|---|---|
| Order ID and order date | Store | Cut-off windows and de-duplication |
| Destination pincode (six digits, text format) | Store | Grouping key; keep as text so leading digits are never dropped |
| City or district | Store or courier | Sanity check for grouping |
| Payment mode (COD, prepaid, partly prepaid) | Store and payment records | Split of the rate by payment mode |
| Order value and product category | Store | Later rules by cart value and category |
| Courier and AWB | Courier panel | Separate courier performance from buyer behaviour |
| Final outcome (delivered, RTO, customer return, cancelled before dispatch) | Courier panel | The numerator and denominator of the rate |
| Number of attempts and last failure reason | Courier panel | Failure family classification |
| New or repeat buyer | Store | Repeat buyers often behave differently from first-time buyers |
Handle data quality first
Pincode analysis fails quietly when the data is dirty. Run these cleaning steps before you trust any table.
- Pincodes are six digits; fix entries with spaces, missing digits or letters.
- One order equals one row; remove duplicates created by edits and resends.
- Outcome labels are consistent (delivered, RTO, customer return, cancelled before dispatch).
- Courier-fault returns are flagged separately from buyer-caused returns.
- COD and prepaid are recorded correctly for every order, including partial payments.
- Time windows match: only include orders old enough for a final outcome, otherwise recent orders still in transit make zones look safer than they are.
The last point matters more than it looks. If you analyse orders from the last 10 days, the failures are not yet counted. Use a cut-off older than your longest normal delivery plus the time for up to three reattempts and the return journey. As a rough rule, a cut-off of 30 to 45 days before the analysis date suits most domestic lanes; check it against your own slowest zones.
Group pincodes into zones that make sense
Group pincodes until each group has enough orders to judge. Good grouping keys are the first one to three digits of the pincode, the courier's own zone label, the city or district name, or a cluster you define by delivery behaviour (for example, hill areas or north-eastern states where delivery takes longer). Keep each zone geographically and operationally coherent: do not merge a metro and a remote area just to reach a sample size.
A sensible workflow is to start broad, with 6 to 10 zones, see where the rates differ, and split only the zones whose rates are high enough to matter and whose order counts are large enough to support a split. Our companion RTO cost model post explains how to value each return; the same break-even rate is used below as the threshold for action.
A worked example: reading a zone table
The following data is invented for illustration. It shows 2,120 orders over a quarter, grouped into six zones. The confidence range is a 95 per cent Wilson interval calculated from the counts and rounded to one decimal place.
| Zone (illustrative) | Orders | RTO | RTO rate | 95% range |
|---|---|---|---|---|
| A: core metro | 900 | 63 | 7.0% | 5.5% to 8.9% |
| B: secondary metro | 700 | 56 | 8.0% | 6.2% to 10.2% |
| C: tier-2 cluster | 300 | 57 | 19.0% | 15.0% to 23.8% |
| D: north-east | 120 | 36 | 30.0% | 22.5% to 38.7% |
| E: hill areas | 40 | 14 | 35.0% | 22.1% to 50.5% |
| F: tier-3 and rural | 60 | 9 | 15.0% | 8.1% to 26.1% |
| Total | 2,120 | 235 | 11.1% |
Check the totals: 900 + 700 + 300 + 120 + 40 + 60 = 2,120 orders; 63 + 56 + 57 + 36 + 14 + 9 = 235 returns; 235 / 2,120 = 11.1 per cent. Now read the ranges. Zones A and B have narrow ranges, so their rates are reliable. Zone C is clearly above A and B because its range (15.0 to 23.8) does not overlap theirs (up to 10.2). Zone D looks worst among the larger zones on the point estimate, but its range is wide. Zone E has only 40 orders, and its range of 22.1 to 50.5 per cent tells you almost nothing precise. Zone F looks moderate but cannot be separated from either A or C.
A blended 11.1 per cent hides all of this. Zones A and B account for 1,600 of the orders and 119 of the returns, which is 7.4 per cent; the other four zones account for 520 orders and 116 returns, which is 22.3 per cent. One quarter of the volume produces nearly half of the returns (116 of 235, or 49.4 per cent).
Reading overlap: when is one zone really worse than another
A quick screen is to see whether two zones' ranges overlap. Zone C (15.0 to 23.8) does not overlap zone A (5.5 to 8.9) or B (6.2 to 10.2), so it is genuinely worse. Zone D (22.5 to 38.7) overlaps C only slightly, so it is probably worse but not certain. Zone E (22.1 to 50.5) overlaps D almost completely, and F (8.1 to 26.1) overlaps C completely, so neither can be separated from its neighbour. This is a rough screen, not a formal test, but it errs on the side of caution, which suits a decision that restricts customers.
The practical result is that D and E could be merged into one "north-east and hills" zone of 160 orders and 50 returns, a rate of 31.3 per cent with a Wilson range of roughly 24.6 to 38.8 per cent. The merged zone is more informative than either part and is still a coherent set of long-transit lanes.
Set a threshold from your break-even rate
Pick the action threshold from your economics, not from a general figure. The method is to compare the contribution you earn on a delivered order with the loss you take on a returned one, both after the cost of acquiring the order. The figures below are ASSUMED for a single product and are not a benchmark.
| Line (ASSUMED figures) | Amount |
|---|---|
| Selling price | Rs 899 |
| Product cost | Rs 380 |
| Forward shipping | Rs 70 |
| Packaging | Rs 15 |
| Contribution on a delivered order before acquisition cost: 899 - 380 - 70 - 15 | Rs 434 |
| Acquisition cost per order (ads, discounts), spent whether or not it is delivered | Rs 250 |
| Contribution on a delivered order after acquisition cost: 434 - 250 | Rs 184 |
| Loss on a returned order: forward 70 + return 70 + packaging 15 + handling 10 + acquisition 250 | Rs 415 |
At an RTO rate r, expected contribution per order is 184 x (1 - r) - 415 x r. It is zero when 184 = r x (184 + 415) = 599r, so r = 184 / 599 = 30.7 per cent. As a check, at 30.7 per cent: 0.693 x 184 = 127.5 and 0.307 x 415 = 127.4, which agree to rounding. For the rest of this guide we round the break-even to 30 per cent. Notice that the assumed product assumes the returned item is resellable; if a share of returns arrives damaged, the break-even falls.
Use three bands relative to break-even: green below half of it (under about 15 per cent), amber between half and break-even, red above break-even. The point of using your own break-even is that a store with thin margins might have a break-even of 15 per cent and a store selling high-margin goods might tolerate 40 per cent. The same zone table leads to different rules for each.
| Zone | Rate | Is the whole range above 30%? | Band | Confidence |
|---|---|---|---|---|
| A | 7.0% | No (top 8.9%) | Green | High |
| B | 8.0% | No (top 10.2%) | Green | High |
| C | 19.0% | No (top 23.8%) | Amber | Medium to high |
| D | 30.0% | No (range 22.5 to 38.7 straddles 30) | Amber to red | Medium |
| E | 35.0% | No (range 22.1 to 50.5 straddles 30) | Undetermined | Low (40 orders) |
| F | 15.0% | No (top 26.1%) | Undetermined | Low (60 orders) |
The rule is to act hard only when you are reasonably sure. Zone D's point estimate sits at break-even and its range straddles it, so a cautious response is better than a ban. Zones E and F need more data before any rule beyond a temporary precaution.
What each zone is worth: contribution per 100 orders
Break-even is easier to feel when expressed in rupees. Using the assumed Rs 184 per delivered order and Rs 415 per returned one, the expected contribution for 100 orders in each zone is shown below, followed by the actual quarter total using the exact counts from the zone table.
| Zone | Per 100 orders at the zone's rate | Quarter total from exact counts |
|---|---|---|
| A (7%) | 93 x 184 - 7 x 415 = Rs 14,207 | 837 x 184 - 63 x 415 = Rs 127,863 |
| B (8%) | 92 x 184 - 8 x 415 = Rs 13,608 | 644 x 184 - 56 x 415 = Rs 95,256 |
| C (19%) | 81 x 184 - 19 x 415 = Rs 7,019 | 243 x 184 - 57 x 415 = Rs 21,057 |
| D (30%) | 70 x 184 - 30 x 415 = Rs 430 | 84 x 184 - 36 x 415 = Rs 516 |
| E (35%) | 65 x 184 - 35 x 415 = minus Rs 2,565 | 26 x 184 - 14 x 415 = minus Rs 1,026 |
| F (15%) | 85 x 184 - 15 x 415 = Rs 9,415 | 51 x 184 - 9 x 415 = Rs 5,649 |
Adding the last column: 127,863 + 95,256 + 21,057 + 516 - 1,026 + 5,649 = Rs 249,315. Cross-check from the totals: 1,885 delivered x 184 = Rs 346,840, less 235 returned x 415 = Rs 97,525, gives Rs 249,315. The two methods agree. The practical reading is that zones D and E together contribute almost nothing (516 - 1,026 = minus Rs 510) while consuming 50 of the 235 returns and a share of your time, whereas zone C is profitable but has a lot of room to improve. That ordering of effort, C first, then D and E once more data arrives, is what a zone table is for.
Split by payment mode before you decide
Break each zone's rate into COD and prepaid. In the invented data, zone C's 300 orders were 200 COD and 100 prepaid, with 50 COD returns and 7 prepaid returns. The COD rate is 50 / 200 = 25.0 per cent (Wilson range 19.5 to 31.4) and the prepaid rate is 7 / 100 = 7.0 per cent (range 3.4 to 13.7), which together give 57 / 300 = 19.0 per cent. The zone's problem is COD, not the zone itself. A rule that blocks the zone would lose the prepaid buyers who return only 7 per cent.
This split also protects you from a statistical trap. If one zone happens to have a higher COD share than another, its blended rate will look worse even if COD and prepaid buyers behave identically everywhere. Wikipedia's article on Simpson's paradox describes how a trend visible in grouped data can change or reverse once the data is split by a hidden variable. Payment mode is the most common such variable in Indian ecommerce, so always compare COD with COD and prepaid with prepaid before concluding that a place is riskier than another. Wikipedia's general article on cash on delivery is useful background on why the payment is collected at the door.
The split is also why pincode rules should usually change the payment option, not block the sale. Nudging COD buyers to prepay in an amber zone, or asking for confirmation, keeps the sale where it is safe and moves risk elsewhere. Our guide to converting COD buyers to prepaid UPI covers the incentive maths, and the post on COD rules by cart value, category and pincode shows how to combine these dimensions in a rule matrix.
Rules per zone: a starting set
| Band | COD setting | Supporting actions |
|---|---|---|
| Green | COD open | Standard address capture; normal NDR handling |
| Amber | COD open with a confirmation step or a small prepaid incentive | Faster NDR response; address landmark required; track weekly |
| Red (range wholly above break-even) | COD limited by order value, repeat-buyer status or removed | Offer prepaid with clear benefit; consider another courier for the zone |
| Undetermined (few orders) | COD open for repeat buyers, confirmation for first-time buyers | Collect more data; review monthly |
Tell buyers early: disclosure and dark patterns
Whatever you set, show restrictions honestly and early. The Press Information Bureau reports that the Central Consumer Protection Authority issued guidelines listing 13 specified dark patterns, including drip pricing, and the CCPA guidelines page hosts the documents. The text of the Guidelines for Prevention and Regulation of Dark Patterns, 2023 defines drip pricing as a practice where elements of the price are not revealed upfront or are revealed surreptitiously within the user experience, or where the price is revealed after confirmation of purchase and an amount higher than the amount disclosed at checkout is charged.
For zone rules the lesson is practical. If a pincode carries a COD handling fee, a COD order-value limit or no COD at all, say so at the pincode or cart stage, in plain words, rather than adding a charge on the final payment step. A message such as "Cash on delivery is not available for this pincode; pay online by UPI or card to continue" is clear and neutral.
Separate courier performance from buyer behaviour
A high RTO zone may reflect your courier, not your buyers. If you ship the same zone with two couriers, compare their delivered share and failure families side by side. Courier-side failures include delivery not attempted, hub delays and wrong status updates; buyer-side failures include refusals and unreachable numbers. Where the courier has failed, the commercial terms may help you: Shiprocket's operating procedure says a seller can choose RTO with a full freight refund where no delivery attempt is made within or after 10 days of the expected delivery date. Those cases are courier failures, and you should flag them separately in your sheet so that they do not make buyers look riskier than they are. The document is Shiprocket's own, as read on 14 October 2026.
Courier prediction and NDR automation as second opinions
Couriers also build scores from their own network history. Delhivery's help page on its RTO Predictor says the score uses consignee details such as mobile number and address, product name and category, shipment value and payment method, and that its insights are derived from deliveries across 18,500+ pin codes. The score runs from 0.0 to 1.0, with higher scores meaning a higher probability of return, and is shown as a high, medium or low risk flag. For high-risk orders the page lists actions: call the consignee, mark the order verified, cancel it, or nudge the buyer to convert COD to prepaid. As read on 14 October 2026 the page states a charge of Rs 2.49 plus GST for low and high risk COD orders, billed whether or not the parcel ships with Delhivery. The price is as read on that date.
Delhivery's help page on SmartNDR describes an automation service that uses WhatsApp responses, delivery executive call insights, geofence information and RTO risk scores to resolve non-delivery cases, with AI calls to the consignee if a case is unresolved. The page states a per-NDR charge, which as read on 14 October 2026 was Rs 5 per NDR attempt, and says clients have observed reductions in RTO percentages. These are vendor-reported outcomes; treat them as a claim to test on your own data, not as an expected result.
Both products are paid, vendor-described services whose accuracy you should test on your own orders: record the predicted band beside the actual outcome for a few hundred past COD orders and compare the RTO rate of each band. Your zone table is the benchmark against which any score should be judged.
Illustrative scenario: acting on zone C
Take zone C from the invented data: 19.0 per cent overall, 25.0 per cent on COD and 7.0 per cent on prepaid, in an amber band. A cautious plan runs in three steps. First, add a confirmation message for COD orders to zone C and require a landmark in the address. Second, offer a small, clearly disclosed prepaid benefit for the zone. Third, review after four weeks: has the COD RTO rate fallen, has checkout completion held, and has the mix of failure families changed?
Here is the arithmetic of a plausible outcome, with every figure ASSUMED. Baseline COD in zone C for the quarter: 200 orders, 50 returns, 150 delivered. Contribution: 150 x 184 - 50 x 415 = 27,600 - 20,750 = Rs 6,850. After the plan, suppose 10 COD orders are lost at checkout (5 per cent) and the COD RTO rate on the remaining 190 orders falls to 20 per cent. Returns: 38; delivered: 152. Contribution: 152 x 184 - 38 x 415 = 27,968 - 15,770 = Rs 12,198. The change is 12,198 - 6,850 = Rs 5,348 for the quarter. The plan pays even though it loses some orders, because each avoided return turns a Rs 415 loss into a Rs 184 gain.
If the failure family is mostly not reachable, the confirmation message should help. If it is mostly buyer refused, a prepaid nudge is likelier to help. If it is mostly courier-side, change the courier for the zone. Each failure family points to a different lever; the zone table alone cannot tell you which. For wider context on coverage, our all-India selling playbook covers logistics options.
Illustrative scenario: a home-textile seller with thin zones
Consider an invented home-textile seller in Surat that ships bedsheets and curtains nationwide. Over two quarters it has 1,400 orders. Gujarat, Maharashtra and Delhi NCR have hundreds of orders each; the rest of the country is a long tail of 20 to 40 orders per state. A first pass by individual pincode is useless: of about 600 distinct pincodes, 480 have a single order.
The seller regroups by the first two digits of the pincode, which maps roughly to a state or part of a state, and then merges neighbours with fewer than 100 orders into regional clusters: north, east, south and north-east. Three things happen. Two of the regional clusters have 120 to 160 orders and ranges that clearly sit above the seller's 30 per cent break-even on COD, so they receive an amber rule: a confirmation step plus a disclosed prepaid benefit. One cluster has only 45 orders with 3 returns; the seller does not act, because 3 of 45 is a rate of 6.7 per cent with a Wilson range of roughly 2.3 to 17.9 per cent, which could be low or moderate. And the north-east cluster has 28 orders, so it is marked undetermined and receives a precaution only: first-time buyers are asked to confirm by phone.
Template: a monthly zone review sheet
Use one sheet per review, with one row per zone and payment mode. The layout below is ready to copy into any spreadsheet; the example row reuses the invented zone C figures.
| Column | Meaning | Example row (zone C, COD) |
|---|---|---|
| Zone and payment mode | Group key | C, COD |
| Orders (matured) | Orders older than the cut-off | 200 |
| RTO count | Buyer-side and unknown returns | 50 |
| Courier-fault count | Returns caused by courier failure, listed apart | 0 (record any) |
| Rate | RTO count divided by orders | 25.0% |
| Low and high end of 95% range | Wilson interval | 19.5% to 31.4% |
| Break-even for this category | From your economics | 30.7% |
| Band | Green, amber, red, undetermined | Amber |
| Main failure family | Largest share of reasons | Buyer refused |
| Rule in force and start date | What is live now | Confirmation plus prepaid benefit, from 1 November |
| Next review date | Prevents silent drift | 1 December |
A confirmation message you can adapt
For orders in amber zones, a short, factual message sent by the channel you have the buyer's consent for is enough. A plain template: "Hello [first name], your order [order number] for [product] of [amount] is ready to ship to [pincode]. Please reply YES to confirm, or pay online here to receive it faster: [link]. If we do not hear from you by [time], we will hold the order for 24 hours." Keep it free of pressure or false urgency, which the dark-pattern guidelines discussed above treat as a concern, and keep the hold period honest.
Monitoring rules after launch
| Metric | How often | What to do |
|---|---|---|
| RTO rate by zone and payment mode | Monthly, rolling 90 days | Move zones between bands when ranges clearly cross a threshold |
| Failure family mix by zone | Monthly | Change the lever, not just the rule |
| Checkout completion by zone | Weekly after a rule change | Reverse a rule if completion drops beyond your tolerance |
| Courier delivered share by zone | Monthly | Switch courier where one clearly outperforms |
| Orders per zone | Quarterly | Merge or split zones as volumes change |
Do not oscillate. Move a zone to a stricter band only when its whole range is above the threshold, and relax it only when the whole range has fallen below. This asymmetry is a simple form of hysteresis, the idea that a system's state depends on its history as well as the current input, described in Wikipedia's article on hysteresis; it stops rules flipping on noise. Be careful, too, about regression to the mean. As Wikipedia's article on regression toward the mean explains, an extreme measurement tends to be followed by one closer to average. A zone that looked terrible in one thin quarter will often look better in the next, even if you did nothing, so do not credit a rule for an improvement until you have compared against zones that received no rule. Review order counts as well: a zone that grows from 40 to 200 orders deserves a fresh look.
Mistakes and how to avoid them
- Acting on single pincodes. Rules built on a handful of orders mostly punish individual buyers. Group first and use ranges.
- Treating serviceability as safety. A courier accepting a pincode says nothing about outcomes. Use your own data for risk and the courier's data for coverage.
- Analysing immature orders. Orders still in transit have not failed yet. Use a cut-off older than your longest delivery plus reattempts.
- Blaming buyers for courier failures. Flag courier-fault returns and compare couriers in the same zone before restricting customers.
- Ignoring payment mode. A blended rate can hide a COD-only problem or mislead through mix effects; always split.
- Hiding restrictions until the last click. Late COD fees or removals are the kind of price surprise that the dark-pattern guidelines describe as drip pricing. Disclose early.
Privacy: handle the data responsibly
Customer phone numbers, addresses and order histories are personal data, and a zone analysis rarely needs them in identifiable form: aggregate to pincode prefix and payment mode before sharing a sheet. India's Digital Personal Data Protection Act, 2023 governs such data, and a wire report says its rules are being phased in over about 18 months from November 2025.
Checklist: pincode risk analysis
- Export at least a quarter of orders with pincode, payment mode, courier, outcome and failure reason.
- Clean pincodes and flag courier-fault returns.
- Apply a cut-off so that every order in the sample has a final outcome.
- Group pincodes into zones with enough orders; split only large, high-rate zones.
- Compute RTO rate and a 95 per cent range for each zone and payment mode.
- Work out your own break-even RTO rate from delivered and returned contribution.
- Assign bands and rules; mark low-sample zones as undetermined.
- Tell buyers about any COD restriction before the payment step.
- Record the rule in force and the next review date for each zone.
- Review monthly and change only when ranges clearly cross thresholds.
Checklist: before you tighten a COD rule in any zone
- The whole 95 per cent range sits above the break-even for that payment mode.
- Courier-side failures have been ruled out or reported separately.
- A lighter control (confirmation, prepaid benefit) has already run for a full review period.
- The restriction is shown on the pincode or cart page in plain words.
- You have a measure for checkout completion and a date to reverse the rule.
Frequently asked questions
Is a serviceable pincode safe to ship to on cash on delivery?
Not necessarily. Serviceability means a courier will accept the parcel; it says nothing about how often parcels to that area come back. Check your own RTO rate for the zone and payment mode, and compare it with your break-even rate. A courier's risk score can be a useful second opinion but should be tested against your outcomes.
How many orders do I need before I trust a pincode's RTO rate?
There is no magic number. As the tables above show, 40 orders gave a range of 22.1 to 50.5 per cent, while 900 gave 5.5 to 8.9. At a 20 per cent rate, about 200 orders narrow the range to roughly 15 to 26 per cent. Group pincodes into zones until each has a few hundred orders where you can, and treat smaller groups as undetermined.
Should I block COD for entire states?
Rarely as a first step. States contain very different areas, and a blanket rule loses profitable buyers. Start with zone-level rules based on your data, split by payment mode, and use softer controls such as confirmation or a prepaid benefit before blocking COD. Block only where your data shows the whole range above break-even.
Why are my returns high in a zone the courier says is covered?
Coverage and performance are different. Look at the failure reasons: courier-side delays and missed attempts point to the network, refusals point to buyer intent and address problems point to data capture. Compare two couriers in the same zone if you can, and request the courier's NDR report for your account, which lists the attempts and reasons it recorded.
Can I use courier RTO prediction instead of my own analysis?
Use it alongside. Delhivery describes a predictor trained on large network data, but it is a paid service and its accuracy for your catalogue is untested until you compare its risk bands with your own outcomes. Your history captures your products and buyers; the courier's score captures network patterns. Together they are stronger than either alone.
How often should I update pincode rules?
Monthly is a reasonable rhythm, using a rolling window of about 90 days and a cut-off old enough for final outcomes. Change a zone's band only when its range clearly crosses a threshold, and re-check after any change in courier, product mix or pricing, because each can shift RTO behaviour independently of geography.
What is a good RTO rate for an Indian online store?
There is no single good figure, and published averages vary by category and source, so this guide does not quote one. The useful number is your own break-even rate, which depends on margin, shipping cost and acquisition cost. In the assumed example it was 30.7 per cent; a thinner-margin product could break even at half that. Measure yours and manage against it.
Does changing the address after an NDR fix a wrong pincode?
Not usually. Delhivery's exception help page notes that an updated address needs to belong to the same pincode, so a wrong pincode generally means the order must be cancelled or returned and reshipped. Catch it at checkout instead: validate the six-digit pincode against the city or state the buyer enters and show an error if they do not match.
Use pincode serviceability and RTO data in your ShopMate store
Pincode serviceability and RTO analysis needs shipping, payment and order data in one view. ShopMate's shipping covers 40+ partners across all India pincodes, with a pincode serviceability check, tracking, COD and returns, and its analytics can be exported to CSV for the zone table above. See the platform in a demo, read about us or review the pricing page.
Disclaimer: This article is for general information only and is not legal, tax or financial advice. ShopMate is the publisher of this guide and has a commercial interest in the platform it describes. The order, zone and cost data in the worked examples is invented for illustration and is not a benchmark. Vendor prices and features were read on 14 October 2026 and may have changed. Rules, thresholds, fees and platform terms change, and your situation may differ. Consult a qualified chartered accountant or legal professional before making decisions.