“Dispatch” is one of those trade words everyone uses and almost nobody defines. Suppliers sell dispatch software, councils write licence conditions about dispatch systems, job adverts want dispatchers — and if you are coming into the trade from outside, none of them stops to say what the word means.
Here it is plainly: dispatch is everything that happens between a booking existing and the right driver arriving at the right place at the right time. Not the marketing that won the booking, not the payment that settles it afterwards — the middle. Matching work to drivers, and dealing with everything that tries to stop the match happening.
That middle is where transport businesses are actually run, so it is worth understanding properly before you hire for it or buy software for it.
The life of one booking
Strip away the technology and every job in every operation on earth goes through the same stages.
It arrives. By phone, website form, WhatsApp, email, an account customer’s PA, or a passenger’s raised arm at a rank. However it comes in, someone or something has to capture it: who, where from, where to, when, how many, any conditions — the child seat, the flight number, the account reference.
It gets priced. Metered work prices itself as it drives. Pre-booked work has to be priced up front — from a rate card, a fixed route price, or a judgement call — and the price has to be one you can honour when the customer accepts.
It gets assigned. A specific driver and a specific vehicle take responsibility for it. This is the decision people picture when they say “dispatch”: who is free, who is close, who has the right vehicle, whose shift does not end an hour before the pickup.
It gets confirmed. The customer learns it is really happening; the driver acknowledges they have really got it. Skipping either half of this is the source of most no-shows — a job both sides believed the other had in hand.
It runs, and it changes. Flights land early. Meetings overrun. A pickup moves twice in an afternoon. The measure of a dispatch operation is not the jobs that run as booked; it is whether a change reaches the customer, the driver and the schedule together, or reaches two of the three.
It closes. Completed, paid or invoiced, and written into the record — which for a licensed private hire operator is not bookkeeping hygiene but a licence condition. Councils typically require every booking kept with its time, hirer, pick-up, destination and allocated driver and vehicle; I have covered what booking records the law actually demands separately.
That is dispatch. Six stages, and every one of them is a place where a job can quietly die.
What a taxi dispatcher does all day
The job advert says “allocating drivers”. The actual day is triage.
A working dispatcher watches a board of jobs in different states and spends the shift on the exceptions: the booking nobody has priced yet, the 4pm airport run with no driver on it, the driver who has not acknowledged the job that leaves in ninety minutes, the customer message asking to move the pickup, the flight that is now forty minutes late, the account job that must be invoiced rather than paid in the car. In between, the phone rings and new work has to be captured without dropping any of it.
Two things about the role are underestimated from outside.
First, the dispatcher holds the record. In a licensed operation, the person allocating jobs is also the person whose discipline decides whether the booking record would survive a council inspection. The Friday-night scrawl on a notepad is a compliance failure waiting for an audit.
Second, the dispatcher is the memory. They know the customer who always books the estate car, the driver who will not work north of the river, the hotel doorman who feeds you work, the account that pays late. When a dispatcher leaves, that memory leaves too — unless the system has been capturing it as customer and driver records all along.
Street work and pre-booked work are different dispatch problems
Here is the distinction that explains most bad software purchases in this trade.
Instant work — street hail, ranks, app-hail — is a proximity problem. The job exists for seconds; the question is which available car is nearest, and the answer comes from GPS. Radio circuits and hail apps are engineered around exactly this, and at high volume it is genuinely hard engineering.
Pre-booked work — chauffeur, airport transfers, corporate accounts, school runs — is a scheduling problem. The job exists for days or weeks before it runs; the question is not who is nearest now but who is right then, and the answer depends on quotes, vehicle classes, flight times, account terms and everything the customer said in between. Proximity is nearly irrelevant; memory is everything.
A system built for one problem handles the other badly, whatever the feature list says. If you run pre-booked work on proximity-dispatch software, the failures arrive exactly where your business lives: the moved pickup, the quoted price, the message about the child seat. I have written up why generic dispatch tools break executive work in detail, and the buying side of the question in the UK dispatch software guide.
What dispatch software actually replaces
Software does not replace the decisions. It replaces the carrying.
Without a system, every stage above lives in someone’s head and several places at once: the diary, the notebook, the WhatsApp thread, the invoice folder. Each hand-off between those places is a chance to drop the job. Dispatch software’s real function is unglamorous — one record per booking that every stage writes to, so the job cannot fall between surfaces, and the reminders, confirmations and chase-ups fire without anyone remembering to send them.
The interesting recent shift is that the routine decisions themselves are starting to be encodable. We build RideDesk, so read this paragraph as an interested party’s description of it: its auto-approve pipeline is essentially a dispatcher’s checklist written down and enforced — the price is re-verified against your own rate card, the route is checked against your service area, the minimum lead time is respected, a suitable driver is auto-assigned, and the confirmation and payment link go out on their own. The design decision that matters is what happens when a check fails: the booking is never rejected — it stays pending with the reason written on it, waiting for a human. That is the honest shape of automation in dispatch: the machine handles the jobs that look like the last hundred, and the exceptions still get a person. There is a free tier covering ten transfers a month, which at explainer-reading size is likely all you need — and if your work is street hail, it is the wrong tool and a radio-circuit system is the right one.
Do you need a dispatcher at all?
At one or two cars: no. You are the dispatcher, and a calendar plus disciplined records is a perfectly professional dispatch system, provided every booking is captured with the details your licence requires. The trap at this size is not missing software; it is missing records.
The moment to take dispatch seriously is when you notice double-handling — writing the same job into two places, copying details into WhatsApp by hand, re-typing a regular’s address. For most operators that starts somewhere between fifteen and thirty jobs a week. What that costs and when paying beats free, I have covered in what dispatch software really costs in the UK and what “free” really means in this market.
A better question than “do I need a dispatcher” is one you can answer this week: count your exceptions. Every time a job changed after booking, every chase, every message hunted for, every detail re-typed. Under ten a week, your notebook is winning; over thirty, dispatch is already your full-time job — the only question is whether it is done well.
