RTO, or return to origin, happens when a shipped order never gets delivered and comes back to the seller. It eats into margins in a way that’s easy to underestimate. The cost includes not just the lost sale but two-way shipping, repackaging, and often damaged or unsellable returned stock. Reducing RTO rates is one of the highest-leverage things a COD-heavy Indian e-commerce seller can work on. Even a small percentage improvement compounds across order volume.
Why RTO is worse for COD-heavy sellers
Cash-on-delivery orders carry meaningfully higher RTO rates than prepaid orders. This holds across most categories and courier networks. Placing a COD order costs the buyer nothing upfront. So some share of orders get placed impulsively, without serious intent to accept delivery. This makes COD-heavy catalogs and audiences structurally more exposed to RTO than prepaid-first stores. That’s especially true in tier-2 and tier-3 India, where COD trust still runs much higher than prepaid trust.
Address quality is the single biggest lever for reducing RTO rates
A large share of RTOs trace back to incomplete or wrong addresses, not buyer refusal. A missing landmark, a wrong pincode, or a house number the delivery agent can’t find are common culprits. Address verification at checkout catches a meaningful share of these before the order even ships. That means pincode-level serviceability checks, structured address fields instead of one open text box, and a confirmation step showing the full address back to the buyer before order submission.
Pre-delivery confirmation calls and messages
An automated WhatsApp or SMS message confirming the order before it ships helps a lot. Sending another right before out-for-delivery helps too. Both give buyers a chance to cancel a COD order they no longer want, before a courier makes a wasted trip. They also catch wrong-number or wrong-address issues early. Couriers often offer this as a built-in feature, calling before the delivery attempt. It’s worth checking that it’s actually enabled on the account, since it’s sometimes off by default.
Choosing and monitoring courier partners
RTO rates vary meaningfully between courier partners, sometimes by a significant margin for the same pincode and product type. A courier with strong last-mile coverage in one region can perform far worse in another. Sellers serious about reducing RTO run multiple couriers. They route orders to whichever performs best for a given pincode, instead of sending everything through a single default courier. Most courier aggregator platforms make this kind of routing possible without much manual work.
Packaging and product-match issues
Some RTOs happen because the buyer opens the package, which couriers increasingly allow before payment. The product then doesn’t match what they expected: wrong size, wrong color, or a quality gap versus the listing photos. This loops back to accurate product descriptions and photography. A listing that oversells the product creates RTOs and returns downstream, even when the logistics side works perfectly.
Tracking RTO rate by SKU and pincode
RTO rate at the overall business level hides useful detail. Breaking it down by SKU and by pincode usually reveals specific problem areas. That might be a particular product with a sizing issue, or a particular region with weak courier coverage. Either way, it’s worth fixing directly rather than applying a blanket fix across the whole catalog.
Using NDR (non-delivery report) data instead of ignoring it
Most courier partners generate a non-delivery report whenever a delivery attempt fails. Each one carries a reason code: customer unavailable, address not found, customer refused, and similar categories. Sellers who review NDR data regularly, not just the final RTO count, catch patterns early. A specific reason code might spike for a specific region. A specific courier might consistently mark “customer unavailable” for orders that were actually awaiting delivery. Acting on an NDR before it converts to a full RTO, by calling the customer directly or rescheduling delivery, recovers a meaningful share of orders that would otherwise come back.
When to consider a partial prepaid model
Some stores struggle with high RTO on specific high-value or high-risk products. For those, requiring a small partial payment upfront for COD orders on those SKUs filters out a portion of low-intent orders. It stops short of going fully prepaid-only, which many price-sensitive audiences in India still resist. This isn’t a universal fix. It works better for some categories and price points than others. Test it selectively on the SKUs or regions where RTO runs consistently highest, rather than applying it store-wide immediately.
Setting realistic RTO targets
RTO rates differ a lot by category and price point, so there’s no single “good” number to aim for. A useful approach tracks a store’s own RTO rate over time. Treat each fix as a test: change one thing, watch the number for a few weeks, then decide whether it’s worth keeping. Small, steady improvements usually beat chasing a single big fix that never quite works as promised.
Reducing RTO ties directly into how accurately a store’s logistics and order data flow, and how honestly product listings represent the actual product. Our e-commerce SEO and listing work often surfaces RTO-driving mismatches between what a listing promises and what gets delivered.
Related reading: Understanding Amazon PPC: A Simple Guide to ACOS.
For more background, see Google’s SEO Starter Guide.
For more background, see Google’s guide to how Search works.
4 Responses