Reducing RTO with WhatsApp: the four points of failure

Return-to-origin, or RTO, is an order that ships and comes back unaccepted — you pay forward shipping, return shipping and handling, and earn nothing. It is the defining cost of cash-on-delivery ecommerce, and it is the one number a merchant in those markets already tracks.

Most advice treats RTO as a single problem with a single fix. It is not. An order can fail at four distinct moments, each with a different cause and a different remedy, and a flow aimed at the wrong moment does nothing.

What RTO actually costs

Be careful with published figures here — most circulate without a source. The best-attributed number we could find is GoKwik's, drawn from its own network of what it describes as 180 million-plus Indian shoppers: an average RTO rate of 23.18%, rising to around 40% in some segments, with Bihar highest at 34.06%. Those are one company's numbers from one market, not an industry constant.

For context on why COD dominates the problem, ET Prime Research figures published by Razorpay put cash on delivery at 60–65% of Indian ecommerce orders.

The four failure points

#	When it fails	Why	Can WhatsApp fix it?
1	At the order	Fake, duplicate or impulse order	Yes — confirmation flow
2	Before dispatch	Wrong or incomplete address	Yes — address check
3	At the door	Nobody home, no cash, changed mind	Partly — delivery-day notice
4	After a failed attempt	Courier gives up after 2–3 tries	Yes — failed-delivery recovery

Three of the four are addressable, and they are addressable in a specific order: each one is cheaper to fix than the one after it, because you have spent less by the time it happens.

Point 1: the order itself

The highest-value intervention, because it happens before you have paid a courier anything. A confirmation flow messages the customer as soon as the order lands, asks them to tap Confirm or Cancel, and writes the answer back onto the order as a tag your packing team can filter on.

A cancellation caught here costs you nothing but the message. The same cancellation caught at the door costs two legs of shipping. That asymmetry is why this is the first flow any cash-on-delivery store should build — the full version is in confirming cash-on-delivery orders on WhatsApp.

Point 2: the address

The quiet one. An address that is incomplete, mistyped or missing a landmark does not announce itself — it becomes a failed delivery days later, by which point you have paid to send it.

Because the customer's tap on the confirmation opens a 24-hour window, you can show them the address and ask them to check it for free, in the same conversation. No template, no charge. See address verification before dispatch.

Point 3: the doorstep

Partly addressable. You cannot make someone be at home, but you can remove the two commonest surprises: not knowing it was coming today, and not having the cash ready.

A message on the morning of delivery naming the amount due does both, and it gives the customer a chance to say "not today" while a reschedule is still cheap. That is the whole intervention, and it is a utility message.

Point 4: after a failed attempt

Most couriers try two or three times and then return the parcel. Those attempts are a window in which the order is still saveable, and almost nobody uses it — logistics tools own failed-delivery data, messaging tools own the conversation, and the two rarely meet. See failed-delivery recovery.

The one that is not a messaging problem

Prepaid orders do not RTO in the same way, because the money has already moved. Converting even a fraction of cash-on-delivery orders to prepaid removes them from the risk pool entirely, which is a different kind of fix from any of the four above — covered in converting COD orders to prepaid.

Build them in this order

1. Order confirmation. Cheapest to fix, largest share of failures.
2. Address verification, in the same conversation, for free.
3. Delivery-day notice with the amount due.
4. Failed-delivery recovery for the attempts you are already paying for.
5. Prepaid conversion, once the rest is running.

If you sell in a cash-on-delivery market, the wider strategy — which flows to build, in what order, and why the standard playbook does not apply — is in WhatsApp automation for cash-on-delivery markets.

Doing them in this order matters because each earlier fix reduces the volume reaching the next. A store that confirms orders properly has fewer addresses to check, fewer doorstep failures and fewer recovery attempts.

What it costs to run

Less than merchants expect. The confirmation is one utility template per order, charged because it lands on a chat the customer has not written to. Everything after their tap — address checks, delivery timing, rescheduling — is free text inside the 24-hour window, which Meta's pricing documentation confirms costs nothing; service conversations have been free and unlimited since 1 November 2024.

So the running cost is roughly one template per order, against the shipping you no longer spend on parcels nobody accepts. In cash-on-delivery markets that comparison is not close.

Measuring whether it worked

Track the RTO rate itself, from your courier, month over month. Two supporting numbers help you see why it moved:

• Share of orders that get any response to the confirmation. Low means your template or timing is wrong, not that customers are ignoring you.
• Cancellations caught before dispatch. Each one is a shipping cost you did not pay, and it is the number to quote when someone asks whether the automation earns its subscription.

Method is in measuring whether your automation works.

What will not reduce RTO

• Sending more reminders. Past one, they produce blocks rather than confirmations.
• A discount to confirm. It trains customers to wait for one and turns a free utility message into a charged marketing one.
• Blocking repeat offenders on its own. Useful, but it addresses a small tail — most RTO is ordinary customers with ordinary reasons.

The unglamorous truth is that RTO falls when you talk to the customer before you ship, not when you push harder afterwards.

Which orders are actually at risk

RTO is not evenly spread, and treating every order as equally risky wastes messages on customers who were always going to accept. The concentrations most merchants find in their own courier data:

Higher risk	Lower risk
First-time customers	Repeat customers with a clean history
Cash on delivery	Prepaid
High order value	Low order value
Ordered late at night	Ordered during the day
Areas your courier flags	Areas with high success rates
Multiple orders in quick succession	A single considered order

You can act on most of these with tags and conditions, so the confirmation flow runs on the risky half rather than on everything. That halves the messages without halving the protection.

The repeat-offender question

Every cash-on-delivery merchant eventually asks whether to block customers who have refused before. It is a reasonable instinct and a small lever: most RTO comes from ordinary customers with ordinary reasons, not from a handful of bad actors.

If you do want to track it, an automation can tag a contact when an order is cancelled or returned, and a later flow can check that tag before confirming. What you cannot do is have this happen automatically from delivery data — Shopify does not send a failed-delivery event, so the tagging has to come from your courier data or a person.

What each fix costs to run

Flow	Messages per order	Charged?
Order confirmation	1 template	Yes, once
Address check, in the same chat	1–2 free text	No
Delivery-day notice	1 template	Yes, once
Failed-delivery recovery	1 template, only when it fails	Yes, occasionally

So a fully built RTO programme is roughly two charged messages per order plus free conversation, because everything after a customer taps sits inside the 24-hour window that Meta's pricing documentation makes free. Set that against a failed delivery and it is not a close comparison.

The order of operations, once more

If you build only one thing, build the confirmation. If you build two, add the address check to the same conversation — it is free and it catches the failure mode nobody sees coming. Everything else is refinement on top of those two.

What RTO is not caused by

Three explanations merchants reach for that the data rarely supports:

• "Customers are dishonest." A small tail exists, but most refusals are ordinary — nobody home, no cash ready, a rider who could not find the address. Designing around fraud misses the bulk of it.
• "The courier is bad." Sometimes true, and worth checking area by area. But a courier cannot deliver to an address that is wrong, and cannot collect cash the customer did not know to have ready.
• "We need to stop offering cash on delivery." In markets where it is 60–65% of orders, removing it removes the orders too. Reducing the failure rate is a better lever than removing the payment method.

The pattern across all three is that RTO looks like a customer problem and is usually an information problem — the customer did not know something you could have told them, at a moment when telling them was free.