The same live state - shown to the customer, the rider, and the dispatcher.
The reason tracking usually feels broken is that the customer's page, the dispatcher's board and the rider's app are pulling from different sources with different refresh rates. In Iyerxpress there is one live state - three views on top of it.
A link, a rider, a window. Not a spinning page.
Each order carries a live status page reachable by a short URL. The customer sees the rider's current position, the predicted window with any adjustments, and the last status change - not a stale "out for delivery" line.
- Branded status page per client - your colours, your logo, your domain
- Automatic SMS or email at key events - assigned, on the way, at doorstep, delivered
- Window updates surfaced honestly - if a window slips, the customer sees the new one and why
- Reassignments handled quietly - the customer sees a rider change, not a status reset
What a customer sees
Order confirmed
Window 16:20 - 16:35. Rider R09 assigned. Link sent by SMS.
Picked up
Rider left origin. ETA remains 16:30.
Two stops away
Rider is 2 stops away. ETA held at 16:29.
At doorstep
Rider arrived. Customer notified once, not four times.
Delivered
Handover confirmed. Feedback link included in final SMS.
One board. Every rider. Every open window.
The dispatch board is the operational surface. Every open order, every active rider, every window countdown - in one grid, filterable by client, corridor, or SLA tier. Reassignments show up with a reason line so the human on shift understands why the engine moved something.
- Live map with rider states colour-coded to fleet health
- One-click hold to freeze an order in place if a manual decision is needed
- Reason log per reassignment - visible at a glance, exportable per shift
- Escalations for orders where no rider in the fleet can meet the window
Dispatcher event stream
Reassign R03 to R09
Reason - R03 pickup queue longer than modelled. Saved 4 min.
Cluster A-14 batched
Four stops in Malleshwaram bundled to R05. Saved one dispatch.
R14 stalled
Stationary 6 min. Two orders reassigned. R14 flagged to fleet manager.
Traffic escalation
Bellary Rd slowed 30%. Three windows widened, customers notified.
On-time holding
Shift on-time rate 94.2% against SLA target of 92%.
Enough. Not more.
Channel choice
SMS, email, WhatsApp or webhook to your own system - each client picks the channel and cadence.
Event-driven, not periodic
Notifications go out at real events - assigned, en route, at doorstep, delivered - not on a timer that fires whether anything happened or not.
Rate-limited
Guardrails prevent a customer being hit by four messages when a reassignment happens - only the meaningful change goes out.
Templated by client
Each client's tone and template is preserved so the customer's status message reads like theirs, not ours.
Next in the loop
Everything the engine did becomes an input to fleet-level analytics - on-time rates, window accuracy, corridor performance.
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.