How Taxi Dispatch Software Actually Works

Most explanations of dispatch software are feature lists. This one follows a single booking from the moment it arrives to the moment the fare is settled, because that sequence is the product — everything else is configuration.

Step 1: the booking arrives

A booking enters the system from one of four places, and after that point they are all treated identically:

• The phone. A controller types it into the console. With caller ID integration the passenger's history and usual addresses appear before they finish saying hello.
• The passenger app. The passenger sets pickup and destination, sees a price, and confirms.
• Your booking website. The same flow in a browser, for passengers who will not install an app.
• Automatically. Scheduled jobs, recurring school or hospital contracts, and account bookings placed by a corporate client.

The single most useful thing dispatch software does at this stage is unglamorous: it turns a free-text address into a precise latitude and longitude. Every downstream decision — which zone, which driver, what fare, how long — depends on that being right.

Step 2: the fare is calculated before dispatch

The system prices the job at the point of booking, not at the end. It works out which tariff applies from the pickup and destination zones, the time of day, the day of the week, and any rules layered on top — airport pickups, waiting time, surge periods, account discounts.

Step 3: the system picks a driver

This is the part people mean when they say "auto-dispatch", and it is simpler than it sounds. The system holds an ordered queue of available drivers for every zone. When a job comes in for a zone, it offers it to whoever is at the front.

What decides queue position

1. The driver is on shift and available — not on a job, not on a break, and inside the zone.
2. They are plated for the job. A wheelchair-accessible booking only offers to a WAV; a six-seater request skips saloons.
3. They have waited longest in that zone. Time in queue is the default fairness rule, and it is the one drivers accept because they can see it.
4. Some systems weight by proximity rather than pure queue order for very urgent jobs — better ETA, less fair. Most operators run queue-first and override when they need to.

What happens when nobody takes it

The offer sits with one driver for a fixed window — commonly 15 to 30 seconds. If they decline or the timer runs out, it moves to the next driver in the queue. Once the local queue is exhausted, the job cascades to adjacent zones, widening the search rather than giving up. Only when that fails does the job land in the controller's lap flagged as unallocated.

That cascade is the difference between a controller managing exceptions and a controller manually allocating every job. On a busy Friday the system should be handling the overwhelming majority without anyone touching it.

Step 4: the driver app takes over

The accepted job appears on the driver's phone with navigation to the pickup. From there the driver moves the job through a small set of states, each of which the office and often the passenger can see:

The reason these states are worth understanding is that every report you will ever want — driver utilisation, average pickup time, no-show rates, which zone is under-covered at 7pm — is derived from the timestamps on those transitions.

Step 5: money moves

Payment is either taken through the app on completion, sent as a pay-by-link text for a phone booking, settled in cash, or billed to a corporate account for invoicing at month end. The important part is that all four routes land in the same ledger, so driver settlements and account invoices are calculated from one set of records rather than reconciled by hand on a Sunday.

Where the controller still matters

Auto-dispatch is not autopilot, and it is worth being clear-eyed about that before a busy Saturday proves it. An experienced controller keeps full override on every job: reassign it, hold it, price it by hand, force it to a specific driver, or push it back to the queue.

The things a human still does better are judgement calls the software cannot see — the regular who needs the same driver, the account client whose job must not be late whatever it costs, the driver having a bad night. Good taxi dispatch software removes the mechanical work and leaves the judgement.

What this replaces

For a firm still running on a whiteboard, a radio and a spreadsheet, the change is less about any single feature and more about there being one record of the truth. The booking, the fare, the driver, the GPS trail, the payment and the receipt are the same object rather than six pieces of paper that have to agree.

If you are weighing that change up, the 24-point checklist for choosing dispatch software covers what to test in a demo, and the guide to switching systems covers doing it without losing a day's work.