Scheduled Taxi Booking, and Why Most Firms Get It Wrong
The Short Answer
A scheduled taxi booking is a job taken now and performed later — an airport run next Tuesday, a hospital appointment, a standing school contract. The part that matters is not storing it; any diary does that. It is when the system offers it to a driver. Offer too early and the driver drifts away; too late and nobody is free. Well-built dispatch releases a pre-booked job into the live queue a calculated lead time before pickup, and escalates to a controller if it goes unclaimed.
Every taxi firm takes work in advance. Airport runs, hospital appointments, school contracts, the Thursday supermarket regular, the wedding in six weeks. In most offices this is the most profitable work on the board and the least well handled by the software, because it is treated as a storage problem when it is actually a timing problem.
The bit that is easy, and the bit that is not
Writing down that somebody wants a car at 04:30 on the 14th is trivial. A paper diary does it. A spreadsheet does it. Every dispatch system on the market does it, and every vendor demo shows you it being done, because it demos well and takes four seconds.
The hard question is the one no demo covers: at what moment does that booking stop being a note and start being a job somebody is responsible for? Get that wrong and the booking is still perfectly recorded at 04:30 when the passenger rings to ask where the car is.
Why pre-booked jobs go missing
There are three failure modes, and almost every missed advance booking is one of them.
1. Offered too early
A job assigned to a named driver a week out looks tidy on the board and is fragile in reality. Drivers get ill, swap shifts, take holidays, and leave. By Tuesday the 4am airport run belongs to somebody who is no longer working Tuesdays, and nothing in the system noticed, because as far as it is concerned the job has a driver.
Firms that allocate advance work early tend to compensate with a human process — a controller who checks the next morning's pre-bookings at the end of every shift. That works, right up until the shift where it is busy and nobody does.
2. Offered too late
The opposite failure. A job released into the queue ten minutes before pickup at 4am, when the fleet is three drivers, is a job nobody can take. Late release also removes the controller's ability to do anything about it — by the time the problem is visible there is no time left to solve it.
3. Offered, refused, and then forgotten
The worst of the three, because it looks handled. The job was offered, a driver declined it, and it fell into a state nothing was watching. Live work has a controller staring at it; a pre-booked job that quietly failed at 03:10 has nobody.
How it should work
The mechanism worth having is a release window, not an assignment. The booking sits as a scheduled job until a calculated lead time before pickup, then enters the live dispatch queue exactly as a phone booking would, and is offered by the normal rules — longest-waiting driver in the pickup zone, cascade outward if missed.
- Taken and priced. The fare is calculated when the booking is made, from the tariff that will be live at the pickup time — not the one live now. A 5am Sunday airport run is priced at the Sunday-night rate even if it is booked on a Wednesday afternoon.
- Held, visible, unassigned. It sits on the forward board where a controller can see it, and it belongs to nobody. Nothing about a driver's shift changing can orphan it, because it was never attached to one.
- Released into the queue. At a lead time worked out from the pickup point — further out for an airport run twenty miles away than for a town-centre collection — it becomes a live job and is offered normally.
- Escalated if unclaimed. If it is not accepted within a defined window, it stops being an automatic problem and becomes a controller's problem, loudly, while there is still time to ring somebody.
- Reminded. The passenger gets a confirmation on booking and a reminder before pickup, which is most of what stops advance no-shows.
The fourth step is the one that separates systems. Everything up to it is scheduling; step four is the difference between a job that fails silently at 3am and a job somebody was told about at 3am.
Recurring work is a different problem again
School runs, dialysis appointments, standing weekly contracts. These are not one booking repeated — they are a rule that generates bookings, and the difference shows up the first time term ends.
| What you need | Why it matters |
|---|---|
| A pattern, not fifty bookings | Changing the pickup time should be one edit, not fifty |
| Term dates and exclusions | Half-term, bank holidays and INSET days are not journeys |
| A named preferred driver, softly | Vulnerable and school passengers benefit from continuity — but a preference must degrade to the queue when that driver is off, not fail |
| Per-contract rates | The account rate, not the meter, and it should be the rate on every generated job automatically |
| One invoice, many jobs | The contract is billed monthly from completed jobs, not job by job |
The "softly" in the third row is the one that catches people. A hard driver assignment on a recurring school contract means that on the morning the regular driver is ill, forty children's worth of transport quietly has no vehicle. A preference that falls back to the normal queue keeps the continuity when it can and keeps the service when it cannot.
What to check in your own system this week
None of this needs new software to investigate. Three checks, on whatever you run now:
- Take a booking for 6am tomorrow and ask when it gets offered. If nobody in the office can answer, that is the answer.
- Look at last month's late and failed jobs and split them into live versus pre-booked. If pre-booked work is over-represented — and at most firms it is — the problem is timing, not drivers.
- Find a recurring contract and change its pickup time by ten minutes. How many edits was that? If the answer is more than one, the system is storing bookings rather than the rule behind them.
Why this work is worth protecting
Advance bookings are disproportionately your best work. They are longer, better paid, more likely to be account or contract jobs, and far more likely to be the sort of passenger who tells other people. An airport run booked three weeks out is worth several town jobs and carries a customer who has planned their morning around you.
It is also the work where failure is least forgivable. A five-minute wait for a town pickup on a Friday night is an inconvenience. A car that does not arrive at 4am is a missed flight, and that passenger does not come back — and, increasingly, says so in a review that costs you the next ten.
Cabica holds scheduled and recurring bookings unassigned on the forward board, releases them into the live queue on a lead time calculated from the pickup point, and escalates anything unclaimed to a controller while there is still time to fix it.
See how dispatch handles itFrequently Asked Questions
- What is a scheduled taxi booking?
- A scheduled or pre-booked taxi booking is a journey taken now and performed later — an airport transfer next week, a hospital appointment, a standing school contract. It is distinguished from an immediate booking by the gap between when it is agreed and when the car is needed, and that gap is where most of the operational difficulty lives.
- How far in advance should a pre-booked job be given to a driver?
- It should not be given to a named driver in advance at all, in most cases. The better pattern is to hold it unassigned and release it into the normal dispatch queue a lead time before pickup — longer for distant or early-morning pickups, shorter for town-centre work. Assigning a week ahead ties the job to a person whose availability may change, and nothing notices when it does.
- What happens if no driver accepts a pre-booked job?
- In a well-built system it escalates to a controller, loudly, with enough time left to do something about it. This is the step most systems are weakest on: live work has somebody watching it, and a pre-booked job that fails at 3am often has nobody. Ask any vendor specifically what happens in this case.
- How do recurring bookings like school runs work?
- A recurring booking should be a rule that generates jobs — a pattern with term dates and exclusions — rather than a large number of individual bookings. That way changing the pickup time is one edit, half-term is handled without cancelling forty jobs by hand, and the contract rate applies automatically to every journey it produces.
- Should a regular passenger get the same driver every time?
- As a preference, yes — continuity matters a great deal on school, hospital and vulnerable-passenger work. As a hard assignment, no. A preference that falls back to the normal queue when the driver is unavailable keeps the continuity when it can and keeps the service when it cannot; a hard lock means the contract has no vehicle the first morning that driver is ill.
Written By
Cabica
Taxi and private-hire software
Cabica builds dispatch, driver and passenger software for independent taxi and private-hire operators.