Address Quality Is a Cost Centre, Not a Form Field

Most brands treat the address as a form field. It is a data pipeline, and a leaky one. Roughly 45 percent of RTOs in Indian ecommerce are attributed to an address that was incorrect, vague or incomplete. That is a larger lever than courier selection, and it sits entirely on your side of the fence.

Why Indian addresses break geocoding

An Indian delivery address is usually written as a set of directions, not as a record. That is fine for a human who knows the neighbourhood and useless for software.

• Landmark locators carry the meaning. Near the water tank, opposite the temple, behind the old bus stand. These are the only positional information in the string and no geocoder can resolve them.
• Street and colony names repeat endlessly within one city. A single large city can hold dozens of streets sharing a name across different wards.
• Transliteration varies. Nagar and Nager, Bagh and Baug, Chowk and Chauk. The same place arrives as four different strings across four orders.
• Building names exist in local memory but not in any map database, and unofficial house numbering is common in older and unplanned areas.
• A pincode covers a wide and irregular area, and its boundary does not match the courier’s delivery beat.

When the geocoder cannot resolve the string, it falls back to the pincode centroid. The rider gets a pin that can be two or three kilometres from the actual door, discovers this at the end of a 90 stop beat, and marks the attempt failed. Nothing in that sequence was the courier’s fault.

The fields that actually predict a failed delivery

You do not need a model to start. Score orders on a handful of signals that any order table already contains.

• No house, flat or door number token anywhere in the address. This is the strongest single predictor.
• Total address length under roughly 25 characters. Short addresses fail more often, and the relationship is close to linear at the low end.
• Pincode that does not match the stated city or state. This is trivially checkable against a pincode master and it catches both typos and autofill accidents.
• Phone number that is invalid, a landline, a repeated digit pattern, or unverified. For COD orders this is close to a coin flip on delivery success.
• Everything typed into one free text box, with no line structure, which usually means the shopper pasted or rushed it.
• An address string reused across many different customer accounts. This is a returns abuse and RTO signal, not just a quality one.

Combine two or more signals and you have a risk tier. Route the top tier to an OTP confirmation or a verification call before dispatch, and consider withdrawing COD as a payment option for it at checkout rather than after the order exists.

Validation at checkout without killing conversion

The goal is a complete address, not a fought one. Sequence and field design do most of the work.

• Ask for pincode first, then autofill city and state from your pincode master. This removes the most common mismatch entirely and shortens the form.
• Split the fields. Flat or house number, building or society name, street or area, landmark, city, state, pincode. A single textarea guarantees missing components.
• Enforce a character minimum only on the house field, and phrase the prompt specifically. Asking for a flat or house number works. A generic invalid address message does not.
• Offer address autocomplete restricted to India, and a map pin drop for metro pincodes where the underlying map data is good enough to help.
• Verify the mobile number by OTP for COD orders. Prepaid orders already carry a payment signal, COD orders carry none.
• Use soft stops, not hard blocks. One specific prompt, then let the shopper proceed.

Instrument the form while you do this. Field level abandonment is the guardrail. A rule that lifts first attempt success by two points while costing three points of checkout conversion is a net loss, and you will only know which happened if you were measuring both before you shipped the change.

Pincode to serviceability mapping

India has roughly 19,000 active delivery pincodes and the serviceable set moves constantly. Around 15 percent see coverage changes, as branches open, close, get reassigned, or quietly stop accepting COD. A serviceability table you loaded once and never refreshed is a slow leak.

Maintain your own master and refresh it weekly from each courier’s API. Hold four flags per pincode per courier: prepaid serviceable, COD serviceable, reverse pickup serviceable, and expected transit days. Layer your own history on top of the courier’s answer, because a pincode can be technically serviceable and still run an RTO rate double your average.

Then use it earlier than most brands do. Show serviceability and the expected date on the product page, not only at the payment step, so a shopper in a non serviceable pincode is not discovered after they have entered card details. Suppress COD automatically where your own RTO for that pincode crosses your threshold. Route to your best performing courier for that pincode rather than the cheapest across the country.

What a clean pipeline is worth

The savings show up in three lines, and they compound.

First, reattempts. Every failed first attempt costs an internal reattempt fee plus an NDR call plus a day of transit. Second, RTO. Published Indian cases show RTO reductions of roughly 4 to 6 percent from pincode level courier mapping and dynamic courier selection, before any checkout validation is added. Third, tickets. Address problems generate a disproportionate share of angry contacts, because the customer believes they gave you a valid address and the parcel came back anyway.

Track four numbers weekly and nothing else. First attempt success rate. Share of orders where the address was edited after placement. Share of NDR reasons coded as address incomplete or address not found. RTO rate split by address risk tier. When first attempt success moves, everything downstream moves with it, and you will know within a month whether the pipeline work paid.