AGGREGATORS vs DISPATCH
COULD DISPATCH PROVIDERS BE THE NEW AGGREGATORS?
Article by Rob Finlayson City Cars Glasgow
rob@citycarsglasgow.co.uk
For years the taxi and private hire industry has had a clear distinction. On one side sat dispatch providers: Autocab, Cordic, Datamaster icabbi etc. - on the other side, aggregators. Dispatch platforms powered fleets, aggregators brought demand to
the table.
Straightforward, simple, understood. Except it’s not that simple anymore.
Quietly, without much fanfare, dispatch providers have started to shift. Integrations have deepened, networks of fleets are forming, and supply is becoming increasingly fluid. What we’re now seeing is the early shape of a future where dispatch systems don’t just support operators, they begin to compete with aggregators directly. The real question is no longer if that happens, it’s when; and more importantly, who gets there first.
Traditionally dispatch systems have been the backbone of the industry. They handled allocation, tracking, pricing and the day to day business of running a fleet. Aggregators, by contrast, owned demand. They controlled distribution, customer access and increasingly the expectation of service on a national and international scale.
That separation is breaking down.
Both sides are now converging on something incredibly powerful. Direct, real time access to fleet supply. Not estimates, not availability guesses, but actual vehicles, actual drivers and the data that sits behind them which is the real crown jewels.
And this is where the difference really starts to matter.
Aggregators, for all their scale and technical ability, operate largely on permissioned data. What they receive is a filtered version of reality, packaged through APIs and handed over in a usable format. It works, but it’s still several steps removed from the source.
Dispatch systems are not removed from the source. They are the source.
22
They don’t just see whether a job can be fulfilled, they see how the fleet is behaving in real time. They understand vehicle composition, driver patterns, acceptance behaviour and the operational nuances that never make it into an API response. They know which drivers are active, which are selective and which simply won’t move on certain types of work. They see the actual flow of the market, not what a model predicts, not what a map suggests, but what drivers actually do.
That’s not just data. That’s control.
Aggregators are connected. Dispatch systems are embedded. That’s the difference.
An aggregator can ask if a job can be covered. A dispatch system already knows who will cover it, how long it will take in real conditions, what it should cost to guarantee coverage and what happens next. As the industry moves toward automated decision making, predictive allocation and dynamic pricing, the platform with the deepest and most accurate understanding of reality will always have the advantage.
So why hasn’t this been exploited yet?
The industry has already seen what this looks like when it is done properly. The model exists. Demand, supply, pricing and behaviour all unified into a single ecosystem. Dispatch providers already sit on many of the same building blocks, they’ve just never chosen to assemble them into something outward facing.
Which brings us to the obvious question. Could we realistically see a major player, something like ComfortDelGro or
Booking.com, snap up a dispatch provider in the near future?
It’s not as unlikely as it sounds.
Large scale demand platforms don’t struggle to generate bookings. What they lack is deep, embedded control of supply. Owning demand is one thing, controlling how that demand is fulfilled across fragmented fleets in real time is something else entirely.
Dispatch systems provide that layer.
They don’t just give access to vehicles, they provide the operational intelligence that dictates how those vehicles behave, how they are allocated and how they
MAY 2026 PHTM
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76
