How to reduce RTO on Amazon and Flipkart: a seller checklist

RTO is not the same as a normal customer return. It happens before a successful delivery: the customer refuses the parcel, cannot be reached, the address cannot be served, or delivery otherwise fails and the shipment returns to origin. Flipkart's Returns API documentation separates customer returns from courier returns and exposes the recorded reason, while an Amazon representative describes a refused delivery as a “Doorstep Reject” that becomes RTO in Amazon Seller Forums.

The useful goal is not an internet benchmark. It is a lower, profitable RTO rate for your own category, fulfilment model and order mix without cancelling valid orders.

Calculate your RTO rate and cost from your own data

For a chosen period, use one definition consistently:

RTO rate = RTO shipments ÷ dispatched shipments × 100

Keep COD and prepaid orders separate. Also split marketplace, fulfilment model, courier, pin code, SKU and recorded return reason. A blended account rate can hide a concentrated problem.

Calculate cost at order level rather than applying a generic rupee estimate. For each returned shipment, include only costs your records show you actually retained:

• forward and return logistics charges that were not reimbursed;
• packaging and handling already consumed;
• marketplace fees or adjustments that remained after the return;
• inspection, repacking or markdown cost if the item came back unsellable or damaged;
• documented inventory carrying cost while the unit was unavailable.

Fee treatment changes by platform, programme and transaction status. Check the current settlement line and applicable terms before counting a charge as a loss. Do not assume every RTO costs the same or that every visible charge is final.

Build an RTO reason table before changing policy

Create one row per shipment with the order ID, payment mode, marketplace, courier, destination pin code, SKU, dispatch date, promised delivery date, first-attempt date, final status and recorded reason. Keep the marketplace or courier's original reason text, then map it into a small working set:

• customer refused;
• customer unreachable or unavailable;
• incomplete or invalid address;
• delivery attempt or serviceability issue;
• delayed delivery;
• reason unclear or missing.

The working labels help analysis; they do not replace the platform's official status. Preserve screenshots, tracking events and case IDs for any dispute.

Reduce preventable RTO before dispatch

Verify the orders that carry more risk

Blanket calls on every order add delay and cost. Start with segments that your own history shows have higher RTO: for example, a repeated customer-contact problem, an incomplete address, a specific SKU, or a courier and pin-code combination with enough orders to judge.

Ask the customer to confirm the product, amount, address landmark and intention to accept the parcel. Amazon's seller-forum guidance recommends confirming COD orders and verifying delivery address and contact details before dispatch. Shiprocket's RTO support guidance similarly describes order confirmation, address verification and targeted action on higher-risk orders.

Do not treat non-response as fraud. Define a documented follow-up and cancellation rule that fits the marketplace's policies and your dispatch deadline.

Validate address details

Check whether the pin code, city and state agree; whether the house or building detail is usable; and whether the phone number has the expected length and format. Ask the buyer to correct missing information before handover where the platform permits it.

Carrier tools can add a risk signal, but they should not become an unexplained automatic rejection rule. Delhivery's RTO Predictor documentation says its score uses inputs such as address, phone number, product, shipment value and payment method, then allows confirmation or payment-mode actions on higher-risk COD orders. Treat a score as one input and measure false positives.

Set accurate delivery expectations

Make the product title, images, size, quantity, compatibility and included items unambiguous. A buyer who receives what the listing promised has less reason to refuse at the door. Amazon's RTO guidance explicitly includes accurate listings among its recommended actions.

Share the expected delivery window and tracking updates through channels the customer agreed to receive. Avoid promising a faster delivery date than the carrier or marketplace shows.

Act on non-delivery reports while delivery is still recoverable

Review NDR or failed-attempt records daily. Confirm the reason with the customer, correct permitted address details, and request a re-attempt when the customer still wants the order. Shiprocket's support documentation describes NDR workflows that allow sellers to contact the customer, request re-attempts or report a disputed attempt.

Track these outcomes separately:

• delivered after intervention;
• returned despite intervention;
• returned with no intervention possible;
• cancelled before dispatch after verification.

This distinguishes a useful process from activity that merely creates more calls and messages.

Choose couriers and COD rules from sufficient evidence

Compare RTO within the same pin code, payment mode and similar product group. A courier's account-wide average can be misleading if its route mix differs. Set a minimum order count before changing a courier or blocking COD for a pin code, and review the decision regularly.

Use a controlled test where possible. For example, apply confirmation to one defined higher-risk segment for four weeks while leaving a comparable segment unchanged. Track dispatch rate, delivery rate, RTO rate, cancellation rate, cost per delivered order and customer complaints. This is an illustrative test design, not a promised result.

Audit returned parcels and settlement entries

When an RTO parcel comes back, record the date, condition, seal or packaging state and inventory outcome. Match the return ID or tracking ID to the settlement entry. Flipkart's returns documentation exposes return and tracking identifiers plus the return reason; those are the starting points for a reproducible audit.

If the physical return, scan history or charge does not match the record, preserve the evidence before opening a case. Amazon's guidance advises including specific order IDs when reporting suspected delivery or scan issues. Describe the documented mismatch rather than claiming courier fault before the case is reviewed.

A weekly RTO control routine

1. Export dispatched, delivered and RTO shipments.
2. Recalculate COD and prepaid RTO rates using the same denominator.
3. Rank reasons, couriers, pin codes and SKUs by both count and cost.
4. Review new NDRs and open evidence-backed cases.
5. Apply one defined intervention to one defensible segment.
6. Record cancellations and false positives as well as avoided returns.
7. Reconcile returned parcels and settlement entries.

The process should produce an audit trail: what changed, which orders were affected, and whether delivery economics improved. It should not rely on an unsupported industry percentage or a guarantee that one tactic will work for every seller.