Every taxi platform sold today claims "AI-powered dispatch." Almost none of them explain what that means, and a fair number mean "we assign the nearest driver, and we have a timer." The phrase has been stretched so far that it no longer tells a buyer anything.
This article is the unglamorous version. What does a dispatch engine actually decide? What is a driver score really made of? And which parts of the AI story should you push back on when a vendor tells them to you?
What Dispatch Actually Decides
Strip away the marketing and a dispatch engine answers three questions every time a rider books:
- Who gets offered this trip? One driver, five drivers, or everyone in range.
- How long do they have to accept? Usually 15–30 seconds.
- What happens when nobody takes it? Widen the radius, drop to the next tier of drivers, or hand it to a human dispatcher.
Every improvement worth paying for is an improvement to one of those three answers. If a vendor's AI story does not change any of them, it is a chart in a slide deck.
The Strategies That Actually Exist
Across serious platforms, dispatch strategies cluster into five recognisable shapes:
- Nearest driver. Find drivers within a radius, sort by distance, offer to the closest few. First to accept gets the job. This is the default nearly everywhere, and for a fleet under about fifteen drivers it is the right default.
- Broadcast to all. Every available driver in range gets the offer at once, no distance limiting. Fastest to fill a job, worst for fairness — your most aggressive drivers win everything.
- Premium drivers first. Drivers with premium status, whether granted by an admin or earned through a subscription, get the offer before everyone else. After a configurable wait, it falls back to the rest of the fleet.
- Score-based. Drivers are ranked by a performance score rather than by distance, with distance breaking ties. More on what that score contains below.
- Manual assignment. No automatic offer at all. A dispatcher looks at a live map and picks the driver. This is what you want for VIP bookings and corporate pickups, and it is not a fallback for a broken system — it is a deliberate mode.
Notice what is not on that list: zone-weighted dispatch and round-robin rotation. Both get described in vendor material regularly. Both are genuinely rare in shipping products. If either matters to you — and for a cooperative fleet with fairness obligations, round-robin matters a great deal — ask to see it running in the admin panel before you sign anything.
What a Driver Score Is Really Made Of
"Score-based dispatch" sounds like a machine learning model. In practice, in most systems, it is a running tally of things the driver did today. A representative scheme:
| Driver action | Score effect |
|---|---|
| Accepts a job | +1 |
| Ignores a job (times out without answering) | −1 |
| Cancels a job they accepted | −2 |
| Creates a booking themselves (street pickup entered into the app) | +4 |
| Receives a five-star rating | +1 |
The highest score gets the next job; distance breaks ties. And in most implementations the whole tally resets at midnight.
That daily reset is the detail nobody mentions, and it cuts both ways. A driver who had one bad afternoon is not punished for a fortnight — they start even tomorrow. But it also means the score is not a reputation. It cannot tell you that a driver has been reliable for eight months, because it does not remember yesterday. If you want long-run reliability to influence dispatch, ask whether the score has any memory beyond the current day. Usually the answer is no.
The second thing worth asking: can you change the weights? In most systems those numbers are fixed in the code. If cancellations are your worst problem and you want them to cost a driver more, you generally cannot make that change yourself.
Where AI Genuinely Helps Today
There is real machine intelligence in modern taxi platforms. It is just not usually in the dispatch loop. Where it shows up:
- Supply-gap forecasting. The system looks at your historical demand and tells you, the operator, that tomorrow between 8 and 10 AM you will be roughly three drivers short. That is a genuinely useful message. Note who it is addressed to — you, not the dispatcher, and not the algorithm.
- Better ETAs. Instead of dividing distance by an assumed average speed, the system uses historical journey times for that zone at that time of day, adjusted for how loaded your fleet currently is. This measurably improves the number the rider sees.
- Zone and revenue diagnostics. "Zone 3 revenue dropped 31% this week; two drivers went inactive." Pattern-spotting across your own operational data, written up in plain language.
All three are advisory. They tell a human something worth knowing. None of them reassigns a trip.
Two Claims to Push Back On
"Our routing uses real-time traffic"
Live traffic data is proprietary and expensive — Google and a handful of others own it. Platforms that run open routing engines such as Valhalla or OSRM to avoid per-request map fees do not have a live traffic feed, because that is precisely the cost they removed. This is a reasonable trade: you save $500–$2,000 a month in map API charges, and your rush-hour ETAs are off by a couple of minutes.
What is not reasonable is being sold both at once. If a vendor tells you their maps are free because they are self-hosted and that their routing accounts for live traffic, one of those is not true. Ask which.
"The system positions drivers before demand arrives"
Predictive repositioning — moving idle drivers toward a stadium fifteen minutes before the match ends — is real technology, and Uber and Didi do versions of it at enormous scale. It is very rare below that scale, for a simple reason: drivers are independent contractors who do not have to go where the app suggests. A system can send a notification recommending a zone. It cannot position anybody.
If this capability is being sold to you, ask what the driver actually sees, and what happens when they ignore it.
What to Measure Instead of Believing the Percentages
You will be shown figures: 30% shorter waits, 25% better utilisation, 20% fuel savings. Treat all of them as marketing until you have your own baseline. Before you change any dispatch setting, record four numbers for two weeks:
- First-attempt acceptance rate — how often the first driver offered a trip takes it
- Average time from request to driver assigned — not to pickup, to assignment
- Reassignment count per trip — how many drivers a booking passes through before it sticks
- Trips per driver per online hour
Then switch strategy and watch the same four for two more weeks. Whatever moves, moved because of your fleet in your city — which is the only evidence that should change how you run it.
The Questions Worth Asking
- Which dispatch strategies ship today, and can I see each one running in the admin panel?
- What exactly goes into the driver score, and does it reset?
- Can I adjust the scoring weights myself, or is that a code change?
- Does routing use live traffic — and if so, who pays for that data?
- When the first driver declines, what happens next, and how long does it take?
A vendor who answers those five plainly is worth more than one with a better word for the same for-loop. Dispatch is not where the intelligence in this industry lives yet. It is where the vocabulary lives.
Dispatch strategy shapes, scoring schemes and reset behaviour described here reflect common implementations in commercial ride-hailing platforms as of 2026, including our own. Map API cost range reflects published Google Maps Platform pricing for typical ride-hailing call volumes. No performance percentages are claimed because we have not measured them across a controlled sample — measure your own, as described above.
