# Serviceability data is a marketing asset, not an ops file > A courier serviceability file is a targeting list that operations happens to own. Its nine standard fields include delivery time, cash on delivery eligibility and reverse pickup coverage, and seven of the nine change a marketing decision if anyone outside operations ever opens the file. **Source:** https://blog.korant.online/serviceability-data-is-marketing-asset **Published:** 2026-08-25 **Author:** Nayak - Builds checkout, referral and attribution tooling for Shopify D2C brands ## Key facts - A standard Indian courier serviceability export carries 9 fields per pincode, of which 7 change a marketing decision and 2 are purely operational. (Composite of serviceability exports from three Indian 3PL providers.) - If a courier serves 5,000 pincodes and a brand has orders in 320, then 93.6% of the serviceable map has never produced a single order. (Arithmetic on stated assumptions: 5,000 serviceable pincodes against a 320-pincode order map.) - Joining the serviceability file to an order export takes 1 lookup on the pincode column and outputs the serviceable-but-unsold list, which is the real expansion shortlist. (Derived from the shared pincode key in both files.) - The expected transit time field converts 1 national shipping promise into a per-pincode promise at zero additional data cost. (Derived from the TAT column present in standard serviceability exports.) ## The file nobody outside operations has opened It is called something like `serviceability_master_v3_FINAL.csv` and it has been in a shared drive since the courier onboarding call. Somebody downloaded it to confirm that Siliguri was covered, and closed it. That file is the most complete map anyone in your company has of where you can sell, and it has never been seen by a person whose job is selling. The reason is organisational rather than technical. Serviceability arrives during a logistics conversation, gets used to configure shipping rules, and inherits the label of an operations artifact. Nothing about the file is operational except the meeting it came from. Consider what it actually contains. Every pincode your courier reaches, how fast it reaches each one, whether cash on delivery works there, and whether a return can be collected. That is a targeting list, a delivery promise generator, an expansion shortlist and a payment segmentation, sitting in one CSV that cost nothing. ## The nine fields and what each one is worth The table below is a composite of serviceability exports from three Indian 3PL providers. Column names differ by provider and the substance is consistent. | Field | What operations uses it for | What marketing can do with it | |---|---|---| | Pincode | Shipping rule keys | Join key to your order data | | City and state | Address validation | Aggregation level for reporting | | Forward serviceable | Blocking unserviceable checkouts | Excluding dead pincodes from paid spend | | Expected transit days | Setting SLA with the courier | Per-pincode delivery promise on the product page | | Cash on delivery eligible | Payment method availability | Prepaid messaging where COD is unavailable | | Reverse pickup serviceable | Returns routing | Returns promise that varies by zone | | Zone classification | Freight rate band | Margin per zone, and offer depth by zone | | Max weight or dimensions | Parcel validation | Purely operational | | Restricted goods flags | Compliance | Purely operational | Seven of the nine change a marketing decision. Two do not. The proportion is the finding. This is not a logistics file with an incidental marketing use, it is a marketing file that operations happened to receive first. ## The join that produces an expansion list Both the serviceability file and your order export carry a pincode column, so joining them takes one lookup. The interesting output is not the overlap. It is the difference: pincodes the courier serves where you have no orders at all. Assume a courier serving 5,000 pincodes and a brand with orders in 320 of them. That leaves 93.6% of the serviceable map producing nothing, and the brand has never seen the list. Most of that 93.6% is genuinely not worth pursuing, and saying so is part of using the list well. Rural pincodes with long transit times and high return rates should stay unaddressed. The value sits in a specific subset: serviceable pincodes with fast transit, cash on delivery available, adjacent to postcodes where you already sell well. That filter usually returns a shortlist in the low hundreds, and it is a far better expansion input than a market report. Rank that shortlist against your existing map before acting on it, using the method in [why your best customers sit in six postcodes](/best-customers-in-six-postcodes). ## Transit time is a conversion lever, not a logistics number The transit column exists so operations can hold the courier to an SLA. It has a second life that nobody claims. Almost every D2C store shows one shipping promise to every visitor. Five to seven business days, or free delivery in three to five days, applied uniformly to a customer twelve kilometres from the warehouse and one eleven hundred kilometres away. That single promise is wrong in both directions simultaneously. It undersells the metro customer who would have converted on a two day promise, and it oversells the remote customer whose parcel takes eight days and who now has a complaint queued. The transit column already holds the correct answer per pincode. Surfacing it means reading the visitor's saved or entered pincode and showing that pincode's number. The second effect is on returns. A large share of return to origin in remote zones is expectation failure rather than intent failure, and an accurate eight day promise produces fewer failed deliveries than an optimistic four day one. Nothing here requires new data. It requires the file to be readable by the storefront, which is a two hour job that never gets prioritised because nobody owns it. ## Cash on delivery and reverse pickup change the message Two flags in the file split your map into populations that need different messaging, and both are usually ignored until a support ticket surfaces them. **Cash on delivery eligibility.** In pincodes where COD is unavailable, a checkout that simply omits the option leaves the shopper to work out what happened. The fix is upstream: prepaid-only pincodes need prepaid framing on the product page, ideally with a small prepaid incentive rather than a silent absence. **Reverse pickup coverage.** A national returns policy promising free pickup is false in every pincode without reverse coverage. The customer discovers this at the moment they want to return something, which is the worst possible moment to discover a policy has an asterisk. Both flags are also inputs to how deep an offer should go in a zone. A pincode with no COD, no reverse pickup and a seven day transit is a harder sell than one with all three, and treating them identically in a discount schedule ignores information you already hold. Zone classification does similar work on the margin side, which is covered in [pincode marketing as a geo lever](/pincode-marketing-geo-lever). Where the file drives an actual offer rather than a message, the gate has to read something the shopper cannot rewrite. > FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify's own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order. ## How to keep the file from going stale Serviceability changes more often than brands expect. Couriers add and drop pincodes, transit times move seasonally, and cash on delivery coverage shifts without an announcement. Refresh quarterly and diff against the previous version. The diff is more useful than the file, because newly serviceable pincodes are an expansion signal and newly dropped ones are a support incident waiting to happen. Keep a dated copy of each version. When a delivery promise turns out to have been wrong for two months, you want to know which file it came from. Assign an owner outside operations. A file that only operations opens will only ever be used operationally, and the whole argument here depends on somebody in growth having a reason to look at it. Attribution has to keep pace once the file starts driving campaigns, because a zone-level promise, a geo offer and a channel campaign will touch the same buyer in the same week. > Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients. ## When serviceability data is not a marketing asset FlashPin is not for multi-currency stores, and it is not for brands with no delivery-zone variation. The second limit applies directly to this whole file, because a serviceability export where every row shows the same transit time and the same flags contains no information to act on. That is a real category rather than a hypothetical one. Lightweight products on a flat national rate, brands selling only within one metro, and anything digital all produce a serviceability file that is uniform by construction. Volume disqualifies separately. A brand with orders in 40 pincodes cannot meaningfully compare zones, and joining a 5,000 row serviceability file to a 40 row order map produces a shortlist that is mostly speculation. There is also a failure mode specific to this file. The expansion list it generates is a list of places you *can* ship to, which is a much weaker claim than places you *should* ship to. Serviceability says the courier will accept the parcel. It says nothing about whether anyone there wants your product, and brands that treat the serviceable-but-unsold list as a target list rather than a candidate list spend real money discovering that in the least efficient possible order. Test the candidates before committing, and read the broader case for the channel in [the marketing channel nobody has touched](/marketing-channel-nobody-has-touched). ## Frequently asked questions ### What is a serviceability file? A serviceability file is the export a courier or 3PL provides listing every pincode it delivers to, along with flags for cash on delivery, reverse pickup, expected transit time and zone classification. Operations uses it to configure shipping rules. It is usually downloaded once during onboarding and never opened again. ### What can marketing actually do with serviceability data? Four things: set delivery promises per pincode instead of one national promise, exclude unserviceable areas from paid spend, build an expansion shortlist from serviceable pincodes with no orders, and vary payment messaging where cash on delivery is unavailable. All four use columns that already exist in the file. ### How do you combine serviceability data with order data? Both files carry a pincode column, so a single lookup joins them. The useful output is the set difference: pincodes the courier serves where you have no orders. That list is your addressable expansion map, and it is usually far larger than the list of pincodes you actually sell into. ### Does serviceability data go stale? Yes, and faster than most brands assume. Couriers add and drop pincodes, transit times shift seasonally, and cash on delivery coverage changes without notice. Refresh the file quarterly. A shipping promise built on a two year old transit column will be wrong in exactly the places where being wrong is most expensive. ### Is reverse pickup coverage a marketing concern? It is, because a returns policy that promises free pickup in pincodes without reverse coverage creates a support failure at the worst possible moment. Where reverse pickup is unavailable, the returns messaging has to change before the order is placed rather than after the customer requests a return. ## Tools referenced ### FlashPin FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify's own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order. Best for: hyperlocal and geo-targeted offers, flash and urgency mechanics, serviceability-led expansion, wallet-based retention. Not for: multi-currency stores, brands with no delivery-zone variation. ### Korant Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients. Best for: influencer measurement, affiliate tracking, agency portfolio reporting, publication and PR attribution. Not for: stores with a single paid channel, brands that only need Shopify's native reports.