Operations guide · 3 August 2026
How to reduce ecommerce RTO: diagnose the cause before the cure
Return to origin, or RTO, means an order travels toward the buyer but comes back without a completed delivery. The return is an event. It is not yet a root cause.
| Step | Question | Output |
|---|---|---|
| Define | Which event counts as RTO? | One shared rule |
| Split | Where does the rate change? | Useful cohorts |
| Trace | What happened before return? | Likely cause |
| Test | What one change can be checked? | Measured result |
Start with the event
Define RTO the same way across every team
An RTO rate is useful only when its parts use the same rules. Decide which orders sit in the base, which return states count, and which date controls the report. A report based on shipped orders can look unlike one based on orders created in the same week. Neither view is wrong, but mixing them can hide the real trend.
Keep buyer returns after a completed delivery apart from orders that never reached the buyer. Keep cancelled orders apart as well. Note how partial shipments, repeat delivery tries, and lost parcels are handled. Write this rule next to the report so sales, support, finance, and operations discuss the same event.
Find the pattern
Break the RTO rate into useful groups
A single company-wide rate can point to a problem, but it cannot tell you where to act. Split the data by order month, destination area, payment type, item group, basket value band, carrier path, dispatch site, and time from order to first attempt. Use only fields that are steady enough to compare and clear enough to explain.
Look for both size and change. A small group with a high rate may create fewer returns than a large group with a modest rate. A group that changed after a new offer, carrier route, product launch, or order process deserves close study. Do not assume that two things seen together prove that one caused the other.
Reason quality
Replace broad labels with an event trail
Labels such as “customer refused” or “address issue” may be too broad for action. Build a short event trail for a sample of orders. Include order time, check or confirmation time, dispatch time, promised date shown to the buyer, delivery attempts, contact events, reason codes, and the final return scan. This trail shows where facts end and guesses begin.
Ask support and delivery teams how each reason code is chosen. The same event may receive a different code from two people. Free-text notes can add context, but do not treat them as clean data without review. A small, checked sample can teach more than a large report built on weak labels.
Cause map
Match the likely cause to the team that can test it
| Possible cause | Evidence to check | First test | Likely owner |
|---|---|---|---|
| Wrong or weak address | Missing fields, edit rate, contact notes | Improve field checks and buyer review | Store and support |
| Order not wanted | Offer source, confirmation trail, refusal notes | Review promise and order check | Growth and support |
| Delivery delay | Order-to-attempt time by route | Test a tighter path for one cohort | Operations |
| Failed contact or attempt | Attempt times, call trail, local pattern | Improve notice and issue follow-up | Carrier and support |
| Item or pack concern | SKU pattern, damage notes, buyer reason | Check listing, item, and pack process | Product and warehouse |
Speed as a factor
Test whether faster fulfillment addresses the proven cause
Speed is one possible input, not a full RTO plan. It may matter when longer order-to-attempt time links with more refused or unreachable orders in a like-for-like group. Yet the link can change by item, payment type, place, or campaign. Check those parts before you decide that a closer stock node will solve the issue.
A regional node also creates stock work. The brand must decide which items to place there, how much to hold, when to refill, and what to do with slow stock. Orders need clear routing, while inventory records must stay aligned. Read the same-day coverage guide before treating a second node as a simple delivery change.
Test design
Run one controlled change at a time
Choose a cohort where the cause looks clear and the action is practical. Write the start date, owner, order set, change, and success measure before the test begins. Keep a fair comparison group when you can. If many parts change at once, a better result will not show which part helped.
Track more than the RTO rate. Watch completed delivery, cancellation before dispatch, delivery attempts, time to first attempt, support contacts, return cost fields, and stock issues. A change that lowers one type of return but creates more cancellations or stock errors may not be a sound result for the business.
Measurement
Use a baseline that can survive close review
Set the baseline before the change. Use the same event rule, data window, and order groups in both views. Note sales events, product launches, major weather, holidays, or carrier changes that could affect the result. If the order mix shifts, show the result by group rather than hiding it inside one blended rate.
Do not turn a short test into a broad promise. Record sample size, missing data, and any manual work used to clean the report. If the outcome is mixed, say so. The goal of the diagnostic is a better next decision, not a strong claim that the data cannot support.
Operating review
Check the full order path, not only the warehouse
RTO can begin before the warehouse sees an order. Review the ad or offer, product page, checkout fields, payment choice, buyer notice, order check, stock status, pack work, dispatch, carrier handoff, delivery attempt, and support response. Each handoff can add delay or confusion that later appears as a return.
A fulfillment provider should explain the parts it can control and the parts it cannot. Ask what data is captured, when orders are released, how issues are raised, and how dispatch proof is shared. For a wider scope review, use the guide to provider comparison and the page on fulfillment role map.
Decision rules
Know when a North India node is worth a closer look
A North India inventory node may deserve study when your own data shows steady demand in the region and delay-led RTO within that demand. The case must also include stock cost, refill work, order routing, goods fit, and the scope of the provider. It should not rest on a headline RTO rate alone.
Bring order-level data rather than a savings guess. A useful review includes demand by postcode, items ordered, payment type, order and attempt times, reason codes, stock needs, and current handoffs. TheSameDay.Club can review these inputs as part of its ecommerce fulfillment services in India, but exact scope and service terms must be confirmed in writing.
Limits
What this diagnostic does not prove
This guide does not supply a normal RTO benchmark because a useful rate depends on the event rule, category, order mix, payment mix, place, and time window. It does not promise that speed, a new warehouse, or any provider will lower returns. It gives your team a way to test causes with its own data. Keep the raw order set, field notes, and reason-code rules with the report. That record helps a later reviewer see what changed and prevents a new team from comparing two rates built in different ways.
Use the result as one input to an operations choice. Review commercial terms, goods limits, service area, cut-off rules, stock duties, and issue ownership on their own. If the main cause sits in the offer, checkout, or buyer contact process, fix that part before moving inventory or changing the fulfillment network.
Review the evidence behind your RTO
Bring a sample of returned orders, the event trail, and demand by place. We can help you test whether fulfillment work or a North India node belongs in the action plan.
Book an operations review