Rider paths that recalculate the moment reality changes.
A route set at the start of a shift is a guess. A route set once an order arrives, then never revisited, is a slower guess. The route engine works the other way - a live plan, rebuilt every time a new order lands, a rider finishes a stop, or a road slows down.
Not one plan. A plan per rider, updated continuously.
Each rider carries an active path with an ordered set of stops. Whenever the fleet state shifts, the engine tests whether a different ordering, batching, or handoff improves the outcome across all open orders - not just the one that changed.
- Order insertion into existing rider paths without a full re-plan
- Automatic batching when two or more stops share direction and timing
- Corridor-aware sequencing that respects one-way roads and no-entry windows
- Pickup queue estimation to avoid stacking riders at the same origin
A rider's shift, mid-run
Plan
R07 is on a 4-stop path. ETA to final stop is 14:41 with 3 min slack.
New order
Order 2311 arrives near stop 2. Engine tests insertion between stops 2 and 3.
Rebuild
Insertion adds 2 min to path total but keeps every window intact. Accepted.
Traffic shift
Bellary Rd slows. Engine reverses stops 3 and 4 to save 4 min. Rider app updates.
Batching
Order 2317 also lands near stop 4 - batched with existing stop, saving a dispatch.
What actually feeds the route.
Live rider position
Position updates from the rider app - anchored to the road graph, not the raw GPS pin.
Road-network state
Segment speeds and closures from our routing layer. Cached per corridor and refreshed continuously.
Pickup queue length
How many riders are already waiting at the same origin - a heavy factor in single-store hub operations.
Historical corridor times
What that route actually took at that time of day across the last several weeks of your own operation.
Rider capacity and skill
Bag capacity, allowed parcel classes, and pass-throughs like refrigerated or fragile handling.
Window and SLA
How much slack the promised window has left - a shrinking window raises the cost of a bad ordering.
Honest notes on current coverage.
Coverage today
Route optimisation is tuned per city. Onboarding includes a two-week calibration where the engine learns your corridor patterns before it starts making reassignment decisions on your live orders.
Where it is weakest
New service areas with no historical data lean more heavily on the road-network layer for the first fortnight. On-time and window accuracy improve rapidly once corridor history is present.
What it will not do
It will not silently miss a hard SLA constraint. If a window cannot be honoured by any rider in the fleet, the engine raises it to the dispatcher board rather than pretending it is fine.
Next in the loop
A good route is only as trustworthy as the window it is promised for. See how the window model works.
Show us your fleet size. Watch the swarm move at your scale.
Type a rider count and a rough daily order volume. The view on the right rebuilds to that scale, with a sample reassignment playing every few seconds - the same kind of decision the delivery engine makes for a live fleet.
An illustrative view based on typical patterns - not a live read of your actual fleet. Numbers move with your inputs so you can see the shape of the problem the engine solves.