Scoring cash-on-delivery orders for RTO risk starts with the address, not a model

A cash-on-delivery order costs you forward shipping before the buyer has paid a rupee. If the parcel comes back, you have paid forward and return freight, the COD handling fee on a collection that never happened, and the packaging, and the stock has been out of circulation for two or three weeks. That makes RTO a cost worth deciding about before dispatch, not after.

We have built this scoring into order flows as rule sets and, later, as models. The lesson from both: the method matters far less than the signals it is fed, and one signal outweighs the rest.

Address quality dominates every other signal

An RTO happens because a courier could not complete a delivery or the buyer refused it. The first cause is written on the label. 'Near bus stand, Main Road' with a pincode is an address a rider cannot find on the first attempt, and a second attempt on a COD parcel is where refusals happen, because the buyer's intent has cooled. Address quality is not merely correlated with RTO. It produces it.

It is also the one signal you can check on every order, including the first one from a new customer with no history at all. Look for a house or flat number, a street or locality name beyond the pincode area, a landmark, and a pincode that is six digits, exists, and matches the city and state the buyer typed. Then check that your courier serves that pincode for COD specifically, since prepaid serviceability and COD serviceability are different lists.

Signals that carry information

• Address completeness, as above. Score it on structure, not length; a long address with no house number is still incomplete.
• Your own delivery history for the pincode: delivered against returned, from your shipments with your couriers. This ages, so weight recent months over old ones, and ignore it for any pincode where you have only a handful of orders.
• Order value against the norm for its category. A first-time COD order well above what that category usually sells for is a different risk from a typical one. The comparison has to be within category, since a high value is normal for a mattress and unusual for a phone case.
• Repeat-customer status, measured as delivered orders on this phone number or address, not as account age. A customer who accepted two COD parcels is your best evidence.
• Phone verification: an OTP confirmed at checkout, or a WhatsApp confirmation answered before dispatch. An unanswered confirmation is itself information.
• Order velocity. Several COD orders from one phone number or address within minutes, often under different names, is a pattern worth holding.

Signals that look predictive and are noise, or worse

Any inference from the buyer's name is out. A name encodes religion, caste, community and gender in India with uncomfortable precision, and a score that uses it is discriminating on protected grounds whatever the model thinks it learned. The same goes for using a whole city, district or state as a feature. That is a proxy for who lives there, and it punishes a buyer with a perfect address for the returns of strangers a hundred kilometres away. Pincode-level history from your own shipments is the acceptable version, and only with enough of your own orders behind it.

Device type, operating system, browser, time of day and day of week look predictive in a training run and usually reflect which ad campaign was live that week. Discount-code usage is similar: it tells you which campaign the order came from, not whether the buyer will open the door. Low-volume pincode statistics are the most seductive noise. A pincode with five orders and two returns is not a bad pincode. It is a pincode you know nothing about yet.

A false positive costs a customer, an RTO costs freight

The two errors are not symmetric, and the asymmetry depends on your margin. An RTO costs forward and return shipping, the COD fee, packaging, handling time, and sometimes the product itself if it comes back damaged. A false positive, where a real buyer is refused COD or pushed to prepay and leaves, costs the margin on that order and whatever that customer would have bought later. On a low-margin product one RTO can wipe out the margin on several delivered orders, so a stricter rule pays. On a high-margin product the refused customer is the larger loss, and the rule should be permissive.

Put your own numbers in before you choose a threshold. The COD & RTO Cost Calculator works out what a single return costs you and what a discounted prepaid alternative nets per order, the Shipping Cost Calculator gives you the forward and return legs by weight and zone, and the Profit Margin Calculator tells you how many delivered orders one RTO consumes.

Score to choose an intervention, not to refuse

A binary accept or reject wastes the score. Three outcomes are more useful: ship as normal, confirm before dispatch, and offer prepaid with a small incentive. Confirmation is a WhatsApp message or a call, and it recovers orders a hard rule would have rejected, since a buyer who confirms an address has just fixed the strongest signal. Offering UPI at a modest discount, with COD still available, converts part of the middle band and is easier to accept than a refusal. Reserve outright refusal for the patterns that are close to certain: an unserviceable pincode, a failed verification with no response, and velocity abuse.

Start with rules, because a model needs the data the rules will generate

A model needs labelled outcomes: thousands of orders marked delivered or returned, with the features recorded as they were at order time. A new store has none of that, and an older store usually has the outcomes but not the features, since nobody stored what the address looked like before ops corrected it. Rules need no history. They also explain themselves, to the ops person who has to phone the customer and to the customer who asks why they were asked to prepay.

Rule                                              Points
No house or flat number in address                +3
Pincode does not match city or state              +3
Pincode not COD-serviceable                       hold
OTP or WhatsApp confirmation failed               +2
First order and value above category norm         +2
Delivered COD order on this phone before          -3
Poor pincode history (only with enough volume)    +1

0 to 2   ship
3 to 4   confirm before dispatch
5+       offer prepaid, or hold

The weights above are a starting shape; tune them against your own outcomes. Log the score and the action on every order alongside what eventually happened. After a few months you have the labelled dataset a model would need, plus a baseline for it to beat. Move to a model when the rules have stopped improving, when you can still explain an individual decision, and when someone owns retraining it. A rule set reviewed monthly is safer than a model nobody has looked at since it shipped.

Measure the score against outcomes, or it will drift

Whatever produces the score, check it monthly. For each band, count delivered against returned. For each intervention, count what the buyer did: confirmed, prepaid, or abandoned. If the confirm band converts almost everyone and returns few, it is too wide. If the ship band's returns are climbing, a courier has changed its pincode coverage or a campaign has brought in a new kind of buyer, and the pincode history needs refreshing. The score is a snapshot of your delivery network and your customers, and both move.

How do you reduce RTO on cash on delivery orders?

Check every COD address for a house number, locality, landmark and a matching, COD-serviceable pincode, and confirm doubtful ones by WhatsApp or OTP before dispatch. Score with plain rules built on address quality, your own pincode history, order value against category norm and delivered-order history, and use the score to offer confirmation or prepaid before refusing anyone.