AI-Powered Dynamic Routing for Quick Commerce: Why Sub-30-Minute Delivery is a Different Routing Problem

Why quick commerce routing is its own problem

A conventional delivery route is planned once against a known set of stops. Quick commerce has no such set. Orders arrive continuously, each with a promise measured in minutes, and couriers are already in motion when the next one lands.

That difference is not a matter of degree. It changes what is being solved. Instead of sequencing a known list, the system is continuously deciding which courier should take a new order, whether that order should travel alongside others, and what the consequences are for every promise already made.

The academic literature treats this as a separate problem class. The Meal Delivery Routing Problem, formalised by Reyes, Erera, Savelsbergh, Sahasrabudhe and O’Neil, addresses exactly this: dynamically assigning couriers to time-critical orders while consolidating orders into batches so that one courier serves several pickups and drop-offs. Subsequent work by Yildiz and Savelsbergh extended the treatment.

That formalisation matters commercially, because it means a platform built for conventional route optimization is not solving your problem more slowly. It is solving a different problem, and the gap will not close with faster hardware.

The economics make this urgent rather than academic. McKinsey defines instant grocery around delivery windows of roughly 30 minutes or less, and identifies unit economics rather than GMV growth as the decisive challenge in the model. And McKinsey separately finds that same-day delivery raises fulfilment costs 1.5 to 2 times standard delivery, which is a conservative floor for a model operating far tighter than same-day.

Also Read: How AI Route Optimization Drives Profitable Quick Commerce Unit Economics in North America

The four decisions a quick commerce system makes continuously

1. Batching: which orders travel together

The decision that determines profitability. A courier carrying one order earns one delivery fee against a full trip cost. A courier carrying three compatible orders spreads that trip across three.

Compatibility is the hard part, and it is multi-dimensional: pickup proximity, drop-off proximity, promise times that can all be met in sequence, product compatibility including temperature, and capacity on a two-wheeler or bicycle rather than a van.

The peer-reviewed evidence is direct. Work on crowdsourced on-demand food delivery order batching and assignment in Transportation Research Part C, and FoodMatch: Batching and Matching for Food Delivery in Dynamic Road Networks in ACM Transactions on Spatial Algorithms and Systems, both demonstrate that algorithmic batching and courier matching reduce delivery times and operational cost against naive assignment.

Naive assignment here means the intuitive approach: give each new order to the nearest available courier. It is fast to implement, it feels sensible, and it systematically underbatches, because proximity at the moment of assignment says nothing about whether two orders could have travelled together.

2. Insertion: where a new order fits across all active routes

When an order arrives, the system evaluates the cost of inserting it into each active route, then assigns to whichever insertion damages the network least.

The word network matters. Assigning to the nearest courier optimises one decision in isolation and can push that courier’s existing orders past their promises, converting one on-time delivery into three late ones. The correct evaluation considers the consequence for every promise already committed, which is a computation rather than a judgement, and it has to complete in the seconds available before the order ages.

3. Courier assignment under uncertain acceptance

Where capacity is gig-based, an assignment is an offer rather than an instruction. A system that treats acceptance as certain will build plans on capacity that declines them, and the failure surfaces at the worst moment, when the promise clock is already running.

Modelling acceptance probability, and holding fallback capacity for high-risk assignments, is the difference between a plan and an intention.

4. Re-optimisation when reality diverges

A courier is delayed at a pickup. A store cannot fulfil an item. Traffic closes a route. Each event invalidates part of the current allocation, and in a 30-minute window there is no recovery time, so the response has to be immediate and automatic.

This is where most platforms stop. Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time. In quick commerce that gap is not a cost inefficiency, it is a missed promise, because the window closes before a human can intervene.

Also Read: Dynamic Route Optimization: The Real-Time Routing Stack for Big-Box Rapid Delivery

Why the last stretch dominates the clock

A 30-minute promise divides into pickup, travel, and the final stretch, and operations consistently underweight the third.

Urban Freight Lab research at the University of Washington, based on more than 1,800 real deliveries, found urban commercial vehicles spend around 80 percent of daily operating time parked, with most of a driver’s time spent outside the vehicle walking the final stretch to the customer. For cargo-cycle riders, roughly 60 percent of time went to parking and walking against 40 percent driving.

Applied to a 30-minute window, that means the difference between a ground-floor drop and a twelfth-floor apartment behind a security desk can consume a fifth of the entire promise. A batching decision that treats those two stops as equivalent because they are 200 metres apart will produce a plan that misses.

The implication for the model is specific: service time has to be estimated per location rather than as a constant, and it has to feed the batching decision rather than being applied afterwards.

Congestion compounds it unevenly. INRIX found US drivers lost 49 hours to congestion in 2025, with congestion rising in 88 percent of the 290 cities analysed, and Chicago drivers losing 112 hours against New York’s 102. A promise calibrated on one metro will not hold in another.

What this requires from a platform

Six capabilities, and the first three are where conventional route optimization falls short.

Batching as a first-class decision, not post-processing. Orders evaluated for compatibility across pickup, drop-off, promise time, product type, and capacity, at the moment of assignment rather than grouped afterwards.

Network-wide insertion evaluation. New orders costed against every active route rather than assigned to the nearest courier, with the consequence for existing promises included in the comparison.

Sub-second to seconds decision latency at volume. The window is the constraint. A system that produces a better answer after the order has aged has produced a worse outcome.

Per-location service time modelling. Learned from observed data rather than assumed, since it is the largest source of promise error.

Acceptance probability for gig capacity. Offers modelled as probabilistic rather than certain, with fallback held for high-risk assignments.

Continuous re-optimisation on events. Delays, stockouts, and cancellations triggering immediate reallocation without a human in the loop.

Also Read: What Actually Works for Sub-2-Hour Urban Delivery in US Markets

How to evaluate a platform for quick commerce

Six questions that separate systems built for this problem from systems adapted to it.

1. Is batching a decision the engine makes, or a grouping applied after assignment? Ask to see the compatibility logic.
2. When a new order arrives, is it costed against all active routes or assigned to the nearest available courier?
3. What is decision latency at your peak order rate, measured rather than quoted?
4. Is service time modelled per location, and learned from delivery history?
5. How is gig acceptance probability handled, and what happens when an offer is declined mid-window?
6. What triggers automatic reallocation, and what still requires a dispatcher?

Question one is the fastest disqualifier, because a platform that batches after assignment has already made the decision that determines profitability, and made it without the information required.

Where Locus fits

Locus, the world’s first Decision-Intelligent, Agentic TMS, is built for continuous decisioning rather than scheduled planning, which is the property quick commerce requires. The Fireworks Routing Engine plans against 250+ real-world constraints per computation, and within DiSCO, the Dispatch agent re-sequences on live events while the Capacity agent matches demand against available rider capacity across owned and contracted pools.

Also Read: The Hyperlocal Fulfillment Equation: Building 2-Hour Delivery Networks That Profit

Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

Two deployments show the batching and continuous-dispatch mechanisms at scale. Siam Makro, the largest B2B online-to-offline retailer in Asia, moved from two hours of human planning per store per day to continuous wave-based dispatch running in 30-minute increments across 160+ stores and 10,900+ active riders, with multi-trip routing built into the same loop. Orders per rider per day rose from 10 to 15 up to 18 to 20, dispatch time per store fell to under 30 minutes, and logistics cost fell 16.7 percent. Static zone logic was replaced with dynamic, sublocality-based zoning, which is the spatial equivalent of the batching argument above.

A global food and beverage leader operating across six markets recorded a 15 percent improvement in rider time efficiency specifically, attributed to constraint-aware routing and real-time re-sequencing freeing rider hours across daily runs. Rider time is the currency in a sub-30-minute model, since it is what batching converts into margin.

Also Read: The Rider Shift Problem: How AI Dispatch Lifts Driver Productivity Across SEA

The measurement that predicts profitability

Orders per rider hour, segmented by batch size.

Most quick commerce operations track orders per rider per shift, which blends batched and unbatched work and hides the lever. Splitting by batch size shows what share of volume travels alone, and that share is the gap between current and achievable unit economics.

Pair it with promise adherence by batch size. If adherence falls sharply as batches grow, the compatibility logic is too loose. If it holds while batch sizes stay small, the logic is too conservative and there is margin available.