COD Pincode Serviceability: Which Lanes to Open, Cap or Close

Serviceability is the one COD control that almost every store has switched on and almost no store has tuned. A courier API returns a serviceable flag, the checkout respects it, and that is where the work stops. The problem is that the flag answers a logistics question — can a parcel physically reach this address — and you are using it to answer a commercial one: should we ship an unsecured parcel here and hope.

Those are different questions with different answers, and the gap between them is where a meaningful share of RTO cost lives.

Serviceability is three gates, not one

Gate one: will anyone deliver here. This is a hard fact about the pincode and your courier panel. If no partner you work with reaches it, nothing downstream matters. It is also the gate that changes most often, because couriers expand and contract coverage continuously.

Gate two: will anyone carry COD here. A separate flag, usually from the same courier, and frequently different from the delivery flag. A pincode can be perfectly deliverable on prepaid and closed to COD, because COD exposes the courier to cash handling and a remittance obligation in a place where it does not want either. Most courier serviceability responses also carry a COD value limit alongside the flag, which is a second constraint merchants routinely ignore until a label fails.

Gate three: what happens when you ship there. Given that a parcel can reach the pincode and that a partner will collect cash at the door, how often does that actually end in a delivery? This gate does not come from anyone. It comes from your own order history, and it is the only one of the three that bears on whether COD at this pincode is profitable.

The common failure is running gates one and two, inheriting their verdict as policy, and never building gate three. The result is a store that offers COD everywhere it is technically possible, including in lanes where its own data says a third of parcels will come back.

What Shopify gives you natively

It is worth being precise about the platform’s own postal-code machinery, because it is more capable than most merchants realise and narrower than they assume.

Shopify’s Help Center documentation on local delivery (checked 10 November 2026) states that “You can offer delivery within a set distance from your location, or for certain postal codes”, and that “You can set up local delivery for specific areas using postal codes for your location.” On the mechanics it says “You can enter a list of postal codes, up to a maximum of 3,000 characters” and “You can add up to 10 delivery zones per location.” Usefully, it documents prefix matching: enter “the starting characters followed by an asterisk” or a space, with the examples that “9732* or 9732 (with space) includes all codes from 97320 to 97329”.

Prefix matching matters more in India than it does in most markets, because the Indian PIN code is hierarchical from the left. The leading digit is a postal region, the first three digits identify a sorting district, and the remaining digits narrow to a delivery post office. That means a prefix is a geographic selector you get for free: 56* and 560* and 5600* are progressively tighter rings around the same place. Any list you build — serviceability, restriction, courier preference — should be expressible in prefixes, not only in six-digit literals, or it will be unmaintainable within a quarter.

The limit to note is scope. The documented feature governs where a delivery method is offered, and the 3,000-character and ten-zone ceilings are real. It is not a mechanism for deciding which payment method appears for a given pincode, and Shopify’s local delivery documentation does not describe payment-method gating at all. That is why per-pincode COD control in practice comes from an app or from a replacement order form rather than from shipping settings.

Courier files disagree, and that is useful

The instinct is to merge every courier’s serviceability list into one master “serviceable” set. Resist it. The disagreements between couriers are information you are throwing away.

A pincode may be deliverable and COD-eligible with partner A, prepaid-only with partner B, and deliverable-but-slow with partner C. If you flatten that into one flag, you lose the ability to say the thing that actually helps: COD is available here, and it has to go on partner A. Keep per-courier lists, keep each one’s COD flag and COD value limit, and let the allocation logic answer the question at label time — the same logic described in courier allocation for COD orders.

Two operational notes on these files.

They go stale in both directions, and only one direction is loud. A pincode that becomes unserviceable while your file still says otherwise produces failed labels and an angry customer, so it gets fixed within a day. A pincode that becomes serviceable while your file still blocks it produces nothing at all — no error, no complaint, just orders you quietly never received. That silent loss is the one nobody schedules time for. Put a refresh on the calendar.

The COD value limit is a separate field. Treat it as a hard constraint in your own cap logic rather than discovering it when a manifest rejects. If a courier’s limit at a pincode is below your average order value, that lane is effectively prepaid for most of your catalogue regardless of what the COD flag says.

Building gate three without fooling yourself

Gate three is an aggregation over your own shipped orders. The columns are straightforward: orders shipped, delivered on first attempt, delivered after an NDR cycle, refused at the door, returned undelivered, average attempts, average transit days.

The hard part is not the aggregation. It is that most of your pincodes will have almost no data.

A store doing solid volume still ships to thousands of distinct pincodes, and the distribution is brutally long-tailed. A pincode with two shipped orders and one return does not have a fifty per cent return rate; it has no measurable return rate at all. Act on that number and you will restrict healthy lanes at random, which costs you revenue you will never see and teaches you nothing.

The fix is the PIN hierarchy. Score at the level where you have enough orders to mean something, and inherit from the parent level where you do not:

Set a minimum volume threshold — the order count below which you will not judge a lane on its own data. Pick it from your own volume rather than copying a number; the test is simply whether you would change policy on the strength of that many observations.

Score six-digit pincodes above the threshold on their own history. These are your dense lanes, and they are also where most of your volume and therefore most of your absolute loss sits.

Roll everything thinner up to the three-digit sorting district. This is the natural unit, because it corresponds to shared courier infrastructure — the same hub, often the same delivery staff and the same local conditions. A sorting district aggregates enough orders to be measurable for most stores and it is operationally meaningful rather than statistically convenient.

Fall back to state or region only for genuinely sparse geography. At this level you are making a very coarse judgement, so the only treatment it should justify is a cap, not a block.

One more split is worth building in from the start: separate nobody took delivery from the customer refused it. The first is a lane and courier problem — wrong attempt windows, a weak last mile, an address the rider cannot find. The second is an intent problem belonging to the order, not the pincode. They look identical in an RTO count and they want completely different treatments, which is why NDR handling and order-level risk scoring are separate instruments from this one.

Four treatments, not two

Here is the part that makes the difference. Most stores have exactly two settings for a pincode: COD on, COD off. That binary forces a choice between absorbing a bad lane’s full cost and surrendering its revenue entirely, and both options are usually wrong.

Open. COD as normal, no friction. This should be the clear majority of your lanes by volume. If it is not, your thresholds are miscalibrated, not your customers.

Cap. COD permitted below a value ceiling. This is the single most underused instrument in COD management. The cost of a failure at a weak lane scales with order value — freight both ways is roughly fixed, but locked capital and handling are not — while the convenience that makes COD convert is strongest at low values. A cap keeps the bulk of the orders and removes the tail where one refused parcel undoes several good ones. Derive the ceiling from what you can afford to lose at that lane’s measured failure rate, and then take the lower of your figure and the courier’s own COD limit.

Advance. COD permitted, but a partial payment is required before dispatch. The right treatment for a lane whose problem is intent rather than logistics — the parcels arrive, people decline them. Sizing the advance is its own calculation, covered in how much COD advance to collect.

Prepaid only. The COD option is not shown. Reserve this for lanes that fail on gate one or gate two, and for the small number of lanes where your own data is unambiguous and the cap would have to be set so low it is pointless.

Almost all of the value in this exercise lives in the two middle treatments. A store that moves from open-or-closed to open-cap-advance-closed usually finds it can re-open lanes it had written off, because the thing that was unprofitable was not the lane — it was shipping high-value unsecured parcels into it.

Set thresholds by cost, not by rank

The tempting method is to rank pincodes by return rate and restrict the worst slice. It is the wrong method, because a rank tells you nothing about whether a lane is losing money.

Compute it directly instead. For each lane, the expected cash cost of shipping an unsecured COD parcel is its failure rate multiplied by what a failure costs you: forward freight, return freight, handling at both ends, and the COD collection fee. Compare that against the contribution margin of a typical order to that lane. Where expected loss exceeds contribution, the terms need to change. Where it does not, leave the lane alone no matter how bad its rate looks relative to your average.

This produces a result that surprises people the first time: thresholds differ by product, and they should. A high-margin item tolerates a lane that a thin-margin item cannot. If your catalogue has a wide margin spread, the honest implementation is a policy matrix of lane band against product band, not a single restriction list.

It also changes what you look at first. Sort your lanes by absolute loss rather than by rate, and the top of the list will be dense urban districts with mediocre rates and high volume, not the remote pincodes with terrible rates and four orders a year. Fixing the first list is worth money. Fixing the second is housekeeping.

What the customer sees

Three rules, and the first one is non-negotiable.

Never remove COD without offering something in the same view. “Cash on Delivery is not available for this pincode” as a bare statement is an abandonment message. The same moment should carry the prepaid alternative and whatever incentive you run on it, in one step, without the customer re-entering anything.

Ask for the pincode before the customer is invested. In most checkout flows the pincode arrives late, which means COD disappears after the customer has mentally committed to the purchase and filled in their details. That sequencing converts worse than the same restriction applied earlier, and it is one of the stronger practical arguments in the native checkout versus COD order form decision for stores with substantial restriction lists.

Drop the word “blacklist” everywhere, including internally. It is wrong on the facts — most restricted lanes are a last-mile problem, not a people problem — and the vocabulary drags the team toward punitive handling of what is usually a logistics measurement. “Prepaid-only lane” describes the same list without the editorialising.

Review it monthly, in both directions

Restriction lists have a well-documented failure mode: they only ever grow. Every addition looks locally justified, nobody is accountable for removals, and two years later a store is prepaid-only across a third of the country for reasons no one can reconstruct.

The cure is a monthly review with an explicit mandate to look both ways. Lanes degrade, which is what everyone checks. Lanes also recover — a courier adds a hub, a new partner joins your panel, a franchise that was losing parcels gets replaced — and a lane you restricted eight months ago may now perform like any other. Put a review date on every restriction when you create it, and treat an expired date as a prompt to re-test with a small volume rather than to renew by default.

Two timing cautions. Do not set permanent lane policy from festive-season data; peak-period performance is not representative of anything, in either direction. And give a re-opened lane enough orders to clear your volume threshold before you judge it, or you will be making the thin-data mistake again with extra steps.

Where this goes wrong

Restricting on one bad order. The most common error by a wide margin, usually triggered by a memorable incident rather than by a number. The volume threshold exists to make this impossible.

Blocking a whole state because the aggregate looks bad. State-level return rates are almost always driven by a handful of sorting districts. Blocking the state to address them is a large revenue decision made with a small amount of thought.

Restricting by locality rather than by measured outcome. In India some geographic descriptors correlate closely with community, and a rule that penalises an area’s reputation rather than its measured delivery performance is both unfair and a worse predictor. Lane performance from your own courier data is a legitimate operational input; “that kind of area” is not.

Forgetting the prepaid experience on restricted lanes. A prepaid-only pincode still receives traffic, and often a lot of it. If your restriction logic degrades that page — a confusing message, a broken step, no incentive offered — you have converted a COD problem into a conversion problem across the whole lane.

Leaving courier limits out of the cap. Your cap and the courier’s COD limit are two separate ceilings. The effective one is the lower, and if your system only knows about yours you will find out at manifest time.

Where to start

Export six months of shipped COD orders with their final delivery outcome and the destination pincode. Group by the three-digit prefix first, not by the full pincode — it is a faster read and it is the level most of your decisions will end up being made at anyway. Add two columns: failure rate, and total cash lost to failures. Sort by the second.

Look at the top twenty rows. For most stores this is a short list of dense districts carrying ordinary-looking rates and a lot of volume, and it is where a value cap earns real money immediately. Set a cap on five of them, leave the rest untouched as a control, and compare after a month on three numbers: orders to those districts, COD share within them, and failure rate.

Then, separately, pull your courier serviceability files and check how many pincodes you are currently blocking that at least one partner now covers for COD. That number is usually larger than expected, and re-opening those lanes is the rare change that costs nothing and adds revenue.

COD King applies the treatment side of this: per-pincode and prefix rules that decide whether COD is shown, capped at a value, or requires an advance, before the order is placed. The lane measurements and the thresholds come from your own shipping data, and that is the part worth doing carefully.