You've crossed 30 orders a day. The store is stable, the ads are working, and one courier has carried every parcel so far. Then it happens: your only courier has a bad month in the West zone, RTO on those pincodes jumps, and there's nothing you can do about it because there's no other courier to switch the order to. You watch the returns pile up and pay for every leg twice.
This is the moment most founders start asking the real question: should I run more than one courier, and if so, how do I decide which order goes to which one? That decision is what this guide resolves. Not "which courier is cheapest" (that's a separate comparison), but the strategy of running two or three couriers and allocating orders between them so each parcel ships on the network most likely to deliver it.
This is written from the operations seat. Ravikant Tyagi spent years running distribution at Eureka Forbes and supply chain and operations at Atomberg, where routing decisions across a national network were a daily job, not a theory. By the end you'll have allocation rules you can actually configure this week, a failover setup so one bad courier never sinks a day, and the data you need to route each pincode to its lowest-RTO option.
Past ~30 orders a day, running a single courier is a concentration risk: one bad zone, one strike, one rate hike, one weak-coverage pincode, and you have no switch to flip. Run two or three couriers and allocate orders by rule: route each pincode to its lowest-RTO courier, split by weight slab where rates differ, send high-risk COD to your best-delivery network and let prepaid take the cheapest, and match delivery-SLA promises to the fastest lane. Add a backup-courier failover rule so a rejected pickup auto-reassigns instead of missing dispatch. Pincode-level allocation is the single highest-ROI setting most founders never configure: industry data shows smart allocation cutting failed deliveries by 30 to 48%, and even a 3 to 5% RTO improvement on a COD-heavy book moves real money in the Margin Waterfall. You need per-courier per-zone delivery %, RTO % and TAT to allocate well; an aggregator's auto-allocation is a good default, but override it where your own first-party data disagrees. Review the allocation table monthly.
Why running a single courier is a risk you can't see until it hits
At 10 orders a day, one courier is fine. You have no bargaining power, no data, and no reason to complicate things. But somewhere past 30 a day, single-courier dependence turns from simple into fragile, and the failure modes are all outside your control.
One bad zone sinks a chunk of your book. No courier is good everywhere. A network that delivers 98% in metros routinely drops to 75% in Tier 3 towns, per industry analysis of courier allocation. If your only courier is weak in the exact region where your ads are converting, every order there is a coin-flip you're paying two-way freight to lose.
One operational hit stops everything. A courier strike, a hub fire, a festive-season backlog, a sudden pickup-team shortage in your city. When you run one network, their bad week is your bad week, and there's no order you can move to keep dispatching.
One rate hike, and you have no answer. The day your sole courier raises rates or tightens COD terms, you either eat it or scramble to onboard an alternative under pressure. A founder with two live accounts just shifts volume and keeps the first one honest. A founder with one has no bargaining chip at all.
One weak pincode, repeated 500 times. This is the quiet one. Your courier is fine on average, but there are 30 or 40 pincodes where its rider coverage is thin, and those pincodes generate a disproportionate share of your RTO. With one courier you can't route around them. With two, you send those specific pincodes to whoever delivers them.
None of this means you complicate life at order one. It means that as volume grows, a second courier stops being overhead and becomes insurance you're already paying for in RTO losses.
Aggregator or direct contract as you scale
Before allocation, one structural choice: how do you hold your couriers? Two routes, and the answer changes with volume.
An aggregator (Shiprocket, NimbusPost, iThink, and others) is a software layer sitting between you and 40-plus courier companies. One dashboard, one wallet, one pickup request, and the aggregator's pre-negotiated rates across Delhivery, Bluedart, Xpressbees, Ekart and the rest. Critically for this guide, the aggregator is itself a multi-courier setup: you get many networks and per-shipment courier choice without opening a single direct account. Shiprocket alone lists 42 courier partners across 19,000-plus pincodes, per its recommendation engine page.
A direct contract means opening your own account with one courier, usually Delhivery, and shipping on their network at rates tied to your volume. Faster COD remittance, a named account manager, and one throat to choke when disputes arise. The cost: you need volume before the rates make sense, and you're exposed to that one network's coverage gaps unless you pair it with something else.
| Setup | Best at | Multi-courier? | Trade-off |
|---|---|---|---|
| Single aggregator | 0 to 30 orders/day | Yes, 40+ couriers in one dashboard | Middle-layer margin, slower COD remittance |
| Aggregator + a second aggregator | Volatile coverage, redundancy | Yes, plus platform-level backup | Two wallets and dashboards to manage |
| Direct contract + aggregator | 30 to 100+ orders/day | Yes, direct network plus aggregator's spread | Direct needs volume; more setup |
| Multiple direct contracts | Large, ops-heavy brands | Yes, but you build the allocation yourself | Heavy operational overhead, needs a team |
For most founders reading this, the practical answer is: run an aggregator for the multi-courier spread from day one, and once you cross roughly 30 orders a day, add a direct Delhivery contract alongside it for the bulk of your volume while keeping the aggregator live for weak pincodes and overflow. That combination gives you negotiated economics and genuine failover. The rate math behind that threshold is worked out in the Shiprocket vs NimbusPost vs Delhivery comparison.
Courier allocation rules: the table that runs your dispatch
Allocation is the whole game. Once you have more than one courier available, every order needs a rule deciding where it goes. Get this right and you're routing each parcel to the network most likely to deliver it profitably. Here are the four allocation dimensions that matter, in the order they move the needle.
| Allocate by | Rule | Why it works | What you need |
|---|---|---|---|
| Pincode / zone performance | Route each destination pincode to the courier with the highest delivery success (lowest RTO) for that pincode | The single biggest RTO lever; coverage quality is intensely local | Per-courier per-pincode delivery % and RTO %, built from 60-90 days of your data |
| Weight slab | Send parcels to the courier cheapest in the slab they fall into (light <500g vs 1kg+ differ) | Rate cards break at slab boundaries; volumetric-heavy items price differently per courier | Each courier's rate card by weight slab and your SKU dimensions |
| COD vs prepaid | High-risk COD → your best-delivery / lowest-RTO network. Prepaid → your cheapest reliable option | COD carries 3-5x the RTO risk of prepaid, so it deserves the stronger network | Payment mode at checkout (you already have this) plus per-courier RTO on COD specifically |
| Delivery SLA | Fast-promise or premium orders → fastest-TAT courier for that lane. Standard orders → economy | Matches the promise on your product page to the network that can keep it | Per-courier TAT (turnaround time) by zone |
You don't need all four on day one. Start with pincode performance, because that's where the RTO money is. Add COD-vs-prepaid next, since you already have the payment flag. Weight and SLA come once your catalog and delivery promises justify the extra complexity.
A note on precedence, because rules will conflict. A high-value COD order to a weak pincode hits two rules at once. The safe default: delivery reliability wins over price, always. The ₹8 you save routing a risky COD order to the cheapest courier evaporates the first time that saving triggers one extra RTO at ₹340 of loss. According to the Founder Decision Loop™, you optimise for the decision that protects contribution margin first and shaves cost second, never the reverse.
How allocation actually cuts RTO
Here's the mechanism, plainly. RTO is overwhelmingly a delivery-execution problem, and delivery execution is local. Courier A might run 97% success in pincode 110001 (Connaught Place) and only 78% in a rural Rajasthan pincode, per Metaport's allocation analysis. Courier B might be the reverse. If you ship everything through one of them, half your orders are on the wrong network for their destination.
Allocation fixes this by sending each pincode to whichever courier delivers it best. You're not improving any courier's performance; you're stopping yourself from handing orders to the courier that's bad at that specific place. The same analysis reports brands seeing 30 to 48% fewer failed deliveries after implementing performance-based allocation, ramping from an 8 to 12% reduction in month one to the full effect by month four to six as the pincode data matures. Independent write-ups put fashion-brand RTO cuts from pincode-level courier mapping at over 6 percentage points, per ClickPost's RTO analysis.
Be honest about the ceiling, though. Allocation routes around bad coverage; it does not fix hollow COD orders that were never going to be accepted. That upstream work (address validation, COD verification, partial prepaid, NDR follow-up) is a separate and equally important playbook, covered in full in the guide to reducing RTO on COD orders. Allocation and demand-quality work stack; neither replaces the other. Allocation is the layer most founders skip because it lives in a settings screen nobody opens.
When I ran national distribution, the map on the wall was never a rate card. It was a heat map of where each partner actually delivered, updated monthly. The pattern is always the same: 30 or 40 pincodes drive a wildly disproportionate share of failures, and they're not random, they're the pincodes where one partner's last-mile is thin. The founders who cut RTO the fastest weren't the ones who found a cheaper courier. They were the ones who stopped shipping the North East on the network that was weak there. Allocation isn't a growth hack. It's just refusing to hand orders to the courier you already know will lose them.
Backup-courier failover: never miss a dispatch
Allocation decides where an order should go. Failover decides what happens when that first choice can't take it. Without a failover rule, a rejected pickup or a courier that's non-serviceable to a pincode means the order just sits, unshipped, silently breaching your dispatch SLA until someone notices.
The rule is simple and every aggregator supports it: if the primary courier rejects the pickup or can't service the destination, auto-assign the next-best courier for that pincode. In aggregator language, courier A rejects, the system falls to courier B, per Metaport's allocation guide. Configure a ranked fallback list per zone, not a single backup, so a bad day for two couriers still ships on a third.
If the destination pincode is serviceable by your primary and it's your best performer there → ship primary. If the primary rejects pickup or is non-serviceable → auto-fall to the ranked backup for that pincode. If it's a high-value or high-risk COD order → force it to your lowest-RTO network even if that's not the cheapest. If a courier's delivery rate on a zone drops below your threshold two months running → demote it in that zone's ranking and promote the backup. If you're below ~30 orders/day → don't over-engineer; run one aggregator with its default recommendation on and revisit at volume.
The data you need to allocate well
Allocation is only as good as the data underneath it. Route on guesses and you'll route wrong. Three numbers, tracked per courier per zone (ideally per pincode cluster), are the whole foundation:
- Delivery success % (and its inverse, RTO %): of orders handed to this courier for this zone, what share delivered and got paid. This is your primary allocation signal.
- TAT (turnaround time): days from pickup to delivery for this courier on this lane. Drives your SLA-based rules and your product-page delivery promise.
- COD-specific RTO %: RTO on COD orders alone, per courier, because a courier can look fine on blended numbers while being weak on the COD orders that actually carry the risk.
Where does this come from? Two sources, used together. Your aggregator or courier dashboard exposes delivery and RTO reports per courier; that's your starting map. But your own first-party ledger (your orders, your product, your customers) always beats a generic score, because a courier that's great for electronics in a pincode may be worse for fragile cosmetics to the same pincode. Give it 60 to 90 days of shipping before you trust your own pincode buckets; before that, lean on the aggregator's data.
Monthly, pull every shipment from the last 90 days into one sheet: columns for courier, destination pincode (or cluster), payment mode, delivered vs RTO, and TAT. Pivot delivery success % by courier by pincode-cluster. Any cell where a courier is 10-plus points below the best available option for that cluster is a re-route: demote that courier for that cluster and promote the winner. Flag clusters where even the best courier is under 80%; those need demand-quality fixes, not re-routing. Re-run monthly, because coverage shifts.
When to trust the aggregator's auto-allocation, and when to override it
Modern aggregators ship with an auto-allocation engine, and it's genuinely good as a default. Shiprocket's CORE (Courier Recommendation Engine) analyses 50-plus data points, including each courier's COD remittance time, RTO percentage, pickup time and committed delivery time, then recommends a courier per shipment. It gives you four preset modes (best-rated, fastest pickup, lowest price, fastest delivery) plus custom rules by payment mode, destination pincode and weight slab, per Shiprocket's recommendation engine documentation.
Trust the auto-engine when you're new, low-volume, or lack your own pincode data yet. It's trained on far more shipments than you've run, and its default beats manual guessing every time at the start. Turn it on, set the mode to best-rated (not cheapest), and let it work.
Override it when your own first-party data disagrees. The engine optimises on network-wide averages; you have something it doesn't, which is how each courier performs on your specific product to your specific customers. If your ledger shows courier B losing your fragile SKUs in a cluster where the engine keeps picking it on price or speed, override with a custom rule. The engine is a strong default, not a replacement for reading your own RTO report. Set it to a reliability-first mode, layer your custom pincode and COD rules on top, and revisit monthly.
A founder doing 60 orders a day left his aggregator on "cheapest courier" auto-mode and never looked again, because the dashboard showed the lowest per-shipment rate and that felt like winning. Three of his top pincodes were being routed to a courier weak in exactly those areas, running ~30% RTO there while a better courier on the same platform sat at ~15%. Across a quarter, roughly 400 avoidable RTOs at ₹340 each burned about ₹1,36,000, to save maybe ₹8 a shipment. He'd optimised the one number that was visible and ignored the one that mattered. Reliability-first allocation with his own pincode overrides would have paid for itself in the first week.
What a 3 to 5% RTO improvement is worth: the Margin Waterfall impact
Founders wave off "a few percent of RTO" as a rounding error. On a COD-heavy book, it's one of the largest swing lines in the whole P&L. Here's why, using the Margin Waterfall.
Margin Waterfall™: selling price minus COGS, packaging, shipping, payment or COD fees, RTO loss, then CAC. RTO is its own layer, not a footnote inside logistics, because at Indian COD rates it is frequently the second or third largest deduction in the entire waterfall. Shave the RTO layer and the effect drops straight to the number at the bottom, where survival is decided.
Take a store shipping 60 COD orders a day, ₹599 average, where one RTO burns about ₹340 in cash (forward freight, return freight, written-off packaging, restocking labour, and the CAC already spent to win the order). That's roughly 1,800 orders a month.
| Line | At 25% RTO | At 20% RTO (5-pt cut) |
|---|---|---|
| Orders shipped / month | 1,800 | 1,800 |
| RTO orders | 450 | 360 |
| RTO cash burned (× ₹340) | ₹1,53,000 | ₹1,22,400 |
| Delivered orders | 1,350 | 1,440 |
| Monthly gain from the cut | ~₹30,600 less burned + 90 more paid orders | |
A 5-point RTO cut on this book saves about ₹30,600 a month in pure return losses and turns 90 previously-refused parcels into paid, delivered orders. Even a 3-point cut is worth roughly ₹18,000 a month here, straight to the bottom of the waterfall. Annualise it and a settings-screen change most founders never make is worth more than a full-time hire. That is why allocation earns its place in the operating system, not as a logistics detail but as a margin decision. If you haven't built this model on your own numbers, start with the D2C unit economics guide and plug in your real RTO.
Review cadence: allocation is a habit, not a setup
Courier coverage is not static. A network that's strong in your West pincodes this quarter can slip next quarter after a hub change or a capacity crunch. The founders who keep their RTO low treat allocation as a monthly review, not a one-time configuration.
The rhythm that works: monthly, rebuild the courier scorecard from the last 90 days and re-rank couriers per pincode cluster, promoting and demoting on delivery success. Quarterly, renegotiate rates now that you have volume and a second courier as a bargaining chip, and review whether your aggregator-plus-direct split still makes sense. Immediately, react to any operational signal: a strike, a festive backlog, a courier that misses pickups two days running, shift that volume the same day. According to the Inventory Confidence Model™, you plan reorders against delivered-and-paid demand, and your delivery rate is a direct input to that, so keeping allocation sharp isn't just an RTO play, it keeps your inventory math honest too.
- Pull per-courier, per-zone delivery %, RTO % and TAT for the last 60 days.
- Map every high-volume pincode to its lowest-RTO courier.
- Write allocation rules across four axes: pincode/zone, weight slab, COD vs prepaid, delivery SLA.
- Assign a ranked backup courier for every primary, with failover on a missed pickup.
- Override the aggregator default wherever your own RTO data disagrees with "cheapest."
- Review allocation performance monthly; re-map pincodes to couriers every quarter.
- Track the RTO delta after each change and run it through the Margin Waterfall so the saving is real, not assumed.
Your next action today
Open your aggregator's courier-allocation settings right now and check one thing: what mode is it on? If it's set to "cheapest," switch it to best-rated or best-delivery today, that single change protects margin from the first shipment. Then pull your last 90 days of shipments into one sheet and find your five worst pincode-courier combinations, the cells where a courier you're using is well below the best available option for that area. Re-route those five this week. That's thirty minutes of work for an RTO improvement that compounds every month. If you're not yet at the volume where a second courier makes sense, bookmark this and set it up the day you cross 30 orders a day. For the demand-quality half of the RTO fight, pair this with the COD RTO reduction playbook, and if you're still choosing your fulfilment approach, the guide to choosing a 3PL in India covers the layer above this one. For NDR, the last line before an order becomes RTO, the NDR management guide goes deep.
This guide is by Ravikant Tyagi, who ran national distribution and supply chain operations at Eureka Forbes and Atomberg and now works with early-stage D2C founders as a Fractional COO. If you'd like the complete execution system, calculators, SOPs, templates and operating frameworks behind this process, continue inside D2C Acquisition.Lab.
