Taxi booking software: how a job actually gets in

Taxi booking software is the system that captures a passenger's job and turns it into a priced, confirmed ride record: it takes bookings by phone, from a web booker on the operator's own site, from a passenger app, or from an account customer, validates the address and coverage, quotes a fare, and hands a complete job to dispatch for allocation.

The two are usually sold as one product, and they are not the same job. Booking software covers everything between a customer wanting a car and a complete, priced job existing in your system: capturing pickup and drop-off precisely, checking the route is inside your coverage, pricing it, attaching a payment method or account reference, and confirming back to the customer. Dispatch software starts at that point — which driver is offered the job, in what order, what happens when nobody accepts, and how the vehicle is tracked to completion. The handover is a specific moment: the job is complete enough to allocate.

Getting that boundary clear matters when you compare vendors, because weakness on one side gets blamed on the other. A dispatcher re-typing an address at 23:00 is a booking problem wearing a dispatch costume. A job sitting unallocated while the customer waits is a dispatch problem, and no booking form will fix it. So ask two separate questions in every demo: what does the system capture, and what does it then do with what it captured. The allocation half is documented separately at [dispatch software](/dispatch-software) — this page is only about how the work gets in.

Count your own mix before you shortlist anything. Work through the list: the phone, a web booker on your own site, a passenger app, account customers booking by portal or standing arrangement, hotel and venue desks, WhatsApp, and walk-ups. Whatever your list turns out to be, every channel on it has to end up in the same queue.

The channels fail differently, which is why the mix matters. On the phone there is a human who can catch a wrong postcode, ask which entrance, and recognise a regular from their number — but only if the system puts caller lookup, saved addresses and recent journeys in front of them while they type. Self-serve has no safety net: whatever the customer enters is what the driver gets, so the validation has to live in the form itself.

Market habits differ, and it is worth checking your own call logs rather than assuming. Channel mix varies by market and by operator, and your own call logs are better evidence than any generalisation. Some fleets take most work by voice, especially account and pre-booked jobs; others compete mainly on an app experience. Neither is a reason to close the other channel — the one you close is the one your best customers were using. Neither is a reason to close the other channel — the one you close is the one your best customers were using.

A web booker is a booking flow that lives on your site, under your name — not a link that throws the customer onto a vendor's domain halfway through a purchase. What decides whether it converts is unglamorous: it works properly on a phone; it shows a price before it asks for a card; it lets a first-time customer book as a guest with no account; it accepts a flight number for airport jobs and re-times the pickup when the flight moves; and it drops the finished booking into the same queue as your phone work rather than into an inbox somebody has to remember to check.

Be suspicious of any booking form that is really a contact form. If the output is an email, it is a lead, not a booking — no price, no reference, no confirmation, no place in dispatch.

The passenger app is your repeat-customer channel, not an acquisition channel. It earns its keep through saved addresses, saved cards, one-tap rebooking and live tracking. On TaxiDex the passenger app and the web booker carry your brand; the driver app is always TaxiDex-branded, which we would rather say here than have you discover at launch. More detail: [web booker](/web-booker).

A quote is a commercial promise, so the software has to be explicit about which kind you are making. A fixed price binds you to a number at the moment of booking, whatever the traffic does afterwards. A metered or estimated fare tells the customer roughly what to expect and settles at the end. Airport transfers, school and hospital contracts and corporate work are commonly quoted as fixed prices because the buyer wants a known number in advance; short local work can be run either way. Decide which applies to each type of work you take, and make sure the software can express both.

Whichever you use, four things belong in the booking rather than in the argument afterwards: what the price includes, what triggers a surcharge (night rate, waiting time, extra stops, tolls, airport pickup charges), what happens on a cancellation, and who bears the cost when the customer changes the destination mid-journey. If the system cannot show the customer the same breakdown the driver and the invoice will show, you are buying disputes.

Pricing is also where regulation bites. Taxi and private hire licensing differs by authority, and in India by state and by whether you are licensed as an operator or as an aggregator — including what you may charge, what must appear on a receipt, and what booking record you must keep and for how long. Confirm the current requirements with your licensing authority or broker rather than with any software vendor, ours included.

Pre-booked work is the most valuable thing a booking system handles, because it is predictable revenue you can plan driver cover around. It is also the easiest to lose quietly.

A scheduled job needs three rules attached to it: how far ahead it is released to drivers, what reminder the customer gets, and what happens if it is still unallocated as the pickup time approaches. A booking taken three weeks out that nobody looks at until the morning of is a predictable way to miss a contracted job, and contracted work is the hardest kind to win back.

Recurring work — school runs, dialysis and outpatient transport, staff shuttles, the same weekday run to the station — should be entered once as a standing order and generated automatically, with term dates and holidays honoured, individual instances editable without breaking the pattern, and a defined end date. A fair test in any demo: change one Thursday, cancel the week after, then shift the whole series to a later time, and watch whether the system keeps up.

Ask how far ahead the series is materialised, too. A system that only creates the next instance makes driver cover hard to plan; one that creates a year of jobs makes bulk changes painful. Either is workable if you know which you bought.

Account work is where booking software stops being a form and starts being a billing system. A corporate booking usually has to carry more than a pickup and a drop-off: who booked it, who travelled, which department or cost centre it belongs to, a purchase order or job reference the client's finance team will match against, and sometimes an approval step before it is confirmed at all.

If the reference is not captured at booking, someone reconstructs it at month end from memory, and that is where invoices get queried and cash gets delayed. Require those fields to be enforceable — a PO reference the booker cannot skip where that client demands one — and require them to survive onto the invoice line, not sit in a free-text notes box that no report reads.

The other half is access. Bigger clients want their own bookers with their own logins, saved addresses and agreed rates, ideally through a portal in your brand. Hotels want a desk that can book for a guest and bill the room or the hotel. TaxiDex handles account bookings with cost centres and references, per-client rates and a corporate booking portal for your account customers — the passenger app and web booker are the surfaces that carry your brand — though if your account work is one client and a spreadsheet, none of that needs buying yet.

Three failures are worth designing against specifically, and none of them look like an outage.

Bad address data. A free-text pickup field produces "the flats behind the station". Demand address autocomplete with a real geocode attached, saved and verified addresses for regulars, an explicit field for entrance, flat number or gate code, and a pin the customer can drag. An address that is only precise enough to argue about is why a driver waits at the wrong door and a job cancels.

No coverage check. If the form accepts work you cannot serve — outside your area, outside your hours, a vehicle class you do not run, a wheelchair-accessible request with no accessible vehicle available — you discover it in front of the customer. That check belongs at booking, not at allocation.

No fallback when nobody accepts. Some jobs get no takers. What matters is what happens next: does it escalate to a dispatcher, widen the offer, go to a partner fleet, or simply sit until the customer rings to ask? Make any vendor demonstrate the unhappy path live — a job nobody accepts, an address off the map, a card declined at booking. Demos are built around the happy path; your losses live in the other one.