Last Mile Rider Productivity In Indian Cities
Deliveries per rider hour explains most of your last mile cost, and most brands never see the number because it sits inside a partner's operations. Here is how to define it, benchmark it and move it.
- Count successful deliveries over logged-on hours including wait and idle time. Attempts per hour and active travel time both flatter the number into uselessness.
- Dense metro residential clusters run roughly 4 to 6 successful drops per hour on a two wheeler. Outer suburbs and tier 2 run closer to 2.5 to 4.
- Lifting first attempt success from 82 to 90 percent adds close to 9 percent effective productivity without hiring a single rider.
- Pay a base per logged hour with the variable tied to completing a cluster and to first attempt success, never to raw trip count, and cap the daily variable.
Rider productivity is the largest single cost lever in last mile, and most brands never see the number because it sits inside a partner’s operations. If you run any part of your own delivery, or you are negotiating rates with a 3PL, this is the metric that explains almost everything about your cost per order.
Define deliveries per rider hour before you benchmark it
Deliveries per rider hour is successful deliveries divided by logged-on hours. Two definitions get quietly swapped, and they are not the same thing.
- Attempts per hour flatters the number. A failed attempt consumed a slot and produced nothing. Count only successful deliveries.
- Logged-on hours must include waiting at the hub, idle time between assignments and the return leg. Count only active travel time and you will benchmark yourself into a fantasy.
- Report it by beat and by daypart, not as a citywide average. A morning shift in a dense residential cluster and an evening shift across an industrial belt do not belong in the same number.
Rough working bands in India. In a dense metro residential cluster, ecommerce parcel riders manage roughly 4 to 6 successful drops per hour on a two wheeler. Outer suburbs and tier 2 cities run closer to 2.5 to 4. Quick commerce dark store runs sit around 3 to 4 because trips are short but almost always single drop. Food delivery is lower again because of restaurant wait time.
Density is the biggest lever, not technology
Drops per square kilometre decides everything downstream. A rider with 40 drops inside three square kilometres spends most of the shift delivering. The same rider with 40 drops spread over 12 square kilometres spends most of the shift riding.
Practical ways to buy density:
- Cluster by building and society, not by pincode. Ten drops in one gated complex is one stop with ten handovers, roughly a third of the time of ten separate stops.
- Consolidate volume onto fewer partners per city. Splitting 300 daily orders across three couriers gives each of them a thin, unprofitable beat, and you pay for that in the rate card.
- Batch by time window rather than by order sequence. Same slot orders in the same cluster should ride together.
- Route engines help, but they multiply density rather than replace it. Reported gains sit around 8 to 15 percent fewer kilometres per shipment and 10 to 22 percent more shipments per rider per day.
First attempt success and pickup wait
These two leaks are usually worth more than any routing improvement.
Non delivery reports in Indian ecommerce run anywhere from 20 to 40 percent depending on category and geography, and RTO for D2C brands typically sits at 20 to 30 percent, higher in cash on delivery heavy fashion. Every failed attempt burns a delivery slot that produced no revenue. Lifting first attempt success from 82 percent to 90 percent adds close to 9 percent effective productivity without hiring a single rider. The fixes are unglamorous: verified phone numbers, address quality enforced at checkout, a pre delivery message with a live window, and a same day reattempt path instead of a next day one.
Wait time at pickup is the second leak. Manifest, scan and handover at a hub commonly takes 8 to 15 minutes per trip. On a six hour shift with four trips that is up to an hour, roughly 15 percent of capacity, spent standing in a queue. Pre sort bags before riders arrive, stagger call times in 15 minute waves instead of one crush at 8 am, and run scan out at more than one window during peak.
Incentives that do not buy speed with risk
Pure per drop piece rates reward riding fast and taking chances. That is not an abstract concern. It shows up as accidents, and it shows up as churn when riders get hurt. Design the pay structure so the safest way to earn more is to work a well planned beat, not to ride harder.
- Pay a base per logged hour, with the variable layer tied to completing a full cluster rather than to raw trip count.
- Add a first attempt success bonus. It rewards the calling, the waiting and the second knock, which is exactly the behaviour a piece rate punishes.
- Cap the daily variable so nobody is chasing a payout at 11 pm on wet roads.
- Pay weather surge as a higher rate per drop, not as a target for more drops.
- Track accident and near miss rate as an operational KPI alongside productivity. If productivity rises and incidents rise with it, you bought the wrong thing.
What good looks like across Indian cities
Metros give you density and take it back in traffic, parking and building access. Mumbai and Bengaluru riders lose real minutes to gate entry, lifts and security registers. Delhi NCR is spread out, so beats have to be drawn tighter. Tier 2 and tier 3 cities move faster on the road but have far lower drop density, so deliveries per rider hour typically run 30 to 40 percent below metro clusters.
That gap is not automatically a problem. Rider cost per hour in tier 2 is usually 20 to 30 percent lower, so cost per successful drop can land close to metro levels. This is why deliveries per rider hour should never be your only scorecard. Track cost per successful drop, first attempt success and incident rate together. Optimise the first, protect the second, and never let the third get worse to improve the other two.