Serviceability Is a Growth Constraint. Treat It Like One

Every brand has two maps and usually only looks at one. The first map is where you can sell, which for most Indian brands is close to universal, because a marketplace or a courier aggregator will happily deliver to nearly twenty thousand pin codes. The second map is where you can serve, which is far smaller, often a few hundred cities at best, and thinner than that once you look at what a technician can actually reach in two days.

The distance between those two maps is where brands quietly manufacture their own churn. It is a growth constraint, and it should be treated as an explicit expansion decision rather than something discovered later through ratings.

Selling reach and service reach are different maps

The gap is easy to miss because nothing blocks you. There is no gate that stops a listing appearing in a pin code you cannot service. The order flows, the delivery completes, and the problem only surfaces weeks or months later when something fails and there is no route to fix it.

By then the cost is already booked. A replacement instead of a repair, freight both ways on a heavy item, a support thread that runs for weeks, a rating that sits on the listing for years, and a customer who will tell their local market that the brand does not stand behind its product. In smaller markets that word of mouth effect is not a soft factor, it is the primary acquisition channel working in reverse.

The failure is not that a brand sold into an unserviced pin code once. It is that nobody owned the map. Sales owns reach, operations owns fulfilment, and service coverage sits in a spreadsheet nobody updates.

Mapping service reach against demand

Do this concretely, at pin code cluster level, not at state level. State level views hide everything that matters.

Start with demand. Pull twelve months of orders by pin code, add marketplace search and glance data if you have it, and add any regional distributor sell out you can get. You are looking for where demand already exists and where it is growing, not where you wish it was.

Then map service capability against the same clusters, and be honest about what capability means. It is not whether a partner has a logo on a map. It is whether a trained technician can reach the customer within your promised window, whether the parts that fail most often are physically available within that window, and whether that location has actually closed tickets in the last quarter. A partner with no closed tickets in three months is not coverage. It is an entry in a contract.

Overlay the two and you get four zones. Served and high demand, which is your core and where retention work pays best. Served and low demand, which is a marketing question, because you are already paying for capability you are not using. Unserved and high demand, which is your expansion queue and should be ranked by demand density. Unserved and low demand, which is where the honest answer is often to stop selling.

Refresh the overlay quarterly. Demand moves faster than networks do, particularly as quick commerce and marketplace logistics pull volume into smaller towns.

Pin codes you can sell into but cannot service

This is the practical middle of the problem, because the answer is rarely a clean stop. Rank the options by cost and pick per cluster rather than applying one policy everywhere.

Ship to serve. For low weight, low value products, replacement by courier is cheaper than any service presence. Say so openly, promise a replacement rather than a repair, and set the customer’s expectation before purchase. This is a perfectly good answer for a large share of SKUs and it costs nothing to implement.

Third party authorised repair. Many categories have competent independent workshops in tier two and tier three towns already. Authorising them, supplying parts and training, and paying per closed job is far cheaper than building presence, and it converts an existing informal repair economy into your network. The control conditions are the same as any partner arrangement. Approved parts only, turnaround measured from the customer’s clock, and claim data back at serial level.

Hub and spoke collection. The customer drops at a collection point or a courier picks up, the unit travels to a regional workshop, and comes back. Slower, but honest and workable for mid value durables. It only works if you publish the real timeline instead of a hopeful one.

Restrict the sale. The option nobody likes and the correct one in some clusters. If the product cannot be serviced, cannot be economically shipped back, and fails often enough to matter, then selling there is a decision to buy bad reviews. Restrict by pin code, or restrict the heavy SKUs and keep the light ones live, which is usually the better trade.

Whatever you choose, tell the customer before the sale, not after the failure. A clear line on the listing saying that service in this location is by courier replacement rather than on site repair costs you a small number of orders and saves you the entire escalation.

The commercial case for saying no to a market

Saying no is hard because the revenue is visible and the cost is not. Make the cost visible and the argument becomes easy.

Build a simple contribution view per cluster over a realistic ownership period, not per order. Take the gross margin on expected orders from that cluster. Subtract expected service cost, which is the failure rate multiplied by the cost of the route you would actually use, and in an unserviced cluster that route is usually full replacement plus two way freight, which is the most expensive option available. Subtract the support time. Then apply a rating effect, because ratings in a category with few reviews move conversion across your entire listing and not just in that cluster.

For a heavy or high failure product in an unserviced cluster, that number turns negative more often than teams expect, and it turns negative in a way that spreads, because the rating damage is not local. That is the argument. You are not declining revenue, you are declining a loss that also taxes the markets you serve well.

The reverse case is equally useful. When the number is strongly positive and the cluster is unserved, you have just built the business case for opening service there, with a demand figure attached to it.

Sequence service ahead of demand, not behind it

The discipline is simple to state. Service capability should lead demand into a market by a quarter, not follow it by a year.

In practice that means treating a service node the way you treat a warehouse. It has a lead time to stand up, a fixed cost, and a demand threshold that justifies it. Set the threshold, watch clusters approach it, and open capability just before you push marketing spend there. Brands that do this in reverse spend acquisition money creating demand they cannot support, then spend service money repairing the reputation they damaged while getting there.

Put one owner on the map. Publish it internally every quarter alongside the sales plan. Make expansion into any new cluster an explicit joint decision between growth and service, with the service answer written down before the first campaign runs. That single change removes most of the problem, because the failure was never a lack of capability. It was a lack of a decision.