Teaching riders where the next order will be, before it exists

The problem

In quick commerce, delivery speed is decided before the order exists: a rider two minutes from the restaurant beats a rider fifteen minutes away, every time. But rider positioning was habit and guesswork — riders waited where they always waited, not where the orders were about to come from. The cost showed up everywhere downstream: slower pickups, longer deliveries, idle riders in quiet areas while busy zones starved.

My role

I built the model. Using months of order history, I clustered demand by location and time into a network of hotspots — the places where orders concentrate, and when. Then I turned the math into an operational system: a hotspot network riders can actually be scheduled against, specced for the teams that run rider operations, and carried it through to the global rollout.

What the data shaped

• Hotspots are drawn from where orders actually cluster, not from administrative zone boundaries — demand doesn’t respect the map humans drew.
• Time matters as much as place: a lunch hotspot and an evening hotspot can be different corners of the same neighborhood.
• The network connects retailers to their nearest demand centers, so positioning serves both sides — riders reach customers faster and retailers get riders sooner.

What shipped

A hotspot network and scheduling approach for rider positioning — now live across all operational zones.

What I learned

Models earn trust in production, not in notebooks. The model was defensible on historical data long before it went live — but production taught us things the backtest couldn’t: how riders actually respond to being repositioned.