A chauffeur reservation is not one transaction. It passes through seven distinct states — quote, hold, confirm, assign, monitor, complete, reconcile — and a booking system is really seven systems wearing one interface. Most software sold to transportation operators is strong at quoting and confirming, because that is what a demo shows, and weak at assignment and monitoring, because that is where the work actually is.
Every transportation company that outgrows a phone and a notebook buys or builds the same thing, and almost nobody describes what it is. "Booking software" implies one job: take a reservation. The reservation is the easy part.
What follows is the structure we arrived at after building this for a working Los Angeles black-car operation, then rebuilding the parts that turned out to be wrong. It is deliberately framed as stages rather than features, because the stages are what every operator has regardless of what software they run — including operators running on a spreadsheet, who are performing all seven by hand.
The seven stages of a reservation
A prearranged trip moves through these states in order. Each transition is a place where information can be lost, and each has a characteristic failure.
| Stage | What has to be true at the end of it | Characteristic failure |
|---|---|---|
| 1. Quote | A price exists for a trip that has not happened, and it is the same price anyone in the company would give. | Two staff quote the same trip differently. |
| 2. Hold | Capacity is provisionally reserved and visible to everyone. | Two customers are sold the same vehicle slot. |
| 3. Confirm | The customer has agreed, the terms are recorded, and the trip is committed. | Confirmation sent, nothing committed internally. |
| 4. Assign | A specific chauffeur and vehicle are attached, with travel time to the pickup accounted for. | Assignment made too late, or made while ignoring the previous job. |
| 5. Monitor | Reality is being watched — flight times, traffic, chauffeur status — and change reaches a human. | The flight moved and nobody was told. |
| 6. Complete | The trip closed with actual times, actual route and any extras captured. | Extras and wait time recorded from memory hours later. |
| 7. Reconcile | Money charged matches money owed, and the trip is attributable to a source. | Revenue is known; where it came from is not. |
1. Quote
Quoting is pricing something that has not happened. That sounds trivial and is not, because a chauffeur rate is not a function of distance alone. It is a function of distance, the time of day, the vehicle class, how far the vehicle has to travel empty to reach the pickup, what happens if the passenger is late, and whether the pickup point charges the operator for access.
The architectural decision that matters here is whether rates live in data or in code. If the rate table is data — routes, zones, vehicle classes, multipliers, all editable — the operator can change pricing on a Tuesday afternoon without a developer. If it lives in code, every seasonal adjustment becomes a release, and in practice pricing stops being adjusted at all. We have seen operators running two-year-old rates because changing them was someone else's job.
The second decision is whether the quote is reproducible. A quote that cannot be re-derived later is a liability: when a customer disputes a charge six weeks on, you need to show the inputs that produced the number, not recalculate it against today's table. Storing the quote's inputs alongside its output costs almost nothing and settles arguments permanently.
Our own quoting bug that taught this lesson was small and expensive. A rate table change applied to existing unconfirmed quotes, because quotes were stored as references to the table rather than as resolved numbers. Customers who had been sent one price saw another. The fix was to freeze the quote at the moment of quoting and keep the inputs — which is now the first thing we build.
2. Hold
Between "here is a price" and "we have a reservation" there is a state most systems skip: the hold. It exists because a customer who has asked for a 6am airport run on a Sprinter has not yet agreed, but the Sprinter is now a scarce resource that someone else may ask about in the next ten minutes.
Skipping the hold state is why double-booking happens. The trip sits in an inbox as an enquiry rather than in the system as provisional capacity, so nothing knows the vehicle is nearly committed. A hold with an expiry — even a crude one — converts a conversation into a visible constraint.
3. Confirm
Confirmation is where a reservation becomes an obligation, and the requirement is boring: everything the trip needs must be captured now, because the person who knows it is on the phone and will not be reachable at 5am tomorrow.
In practice, "everything" is a short and stable list: exact pickup point rather than a building name, a passenger phone number that will be switched on at the pickup, flight number where relevant, luggage count, any child seats, whether anyone in the party has mobility needs, and who is paying. The single highest-value field is the pickup point, because it is the field most often wrong and the one that cannot be fixed by a phone call at the moment it matters.
This is also where terms get recorded — wait-time allowance, cancellation window, what happens if the flight is cancelled outright. Recording them at confirmation rather than quoting them verbally is the difference between a policy and an argument.
4. Assign
Assignment attaches a real chauffeur and a real vehicle to a committed trip. It is the stage operators most often leave entirely manual, and the stage where software earns the most.
Not because a system should choose the chauffeur — often it should not, since the choice involves knowledge a dispatcher has and a database does not. But because there is a set of constraints a system should refuse to let a human violate:
- The vehicle is not already committed to an overlapping trip.
- The chauffeur is not already committed, including travel time from their previous drop-off.
- The vehicle class matches what was sold — a sedan cannot quietly serve a booking that was priced and confirmed as an SUV.
- The chauffeur is cleared for the vehicle and, where relevant, for the pickup location's access requirements.
Every one of those is a constraint a tired dispatcher will eventually break at 4am. A system that enforces them is doing the one thing software is genuinely better at than people.
5. Monitor
Monitoring is where a prearranged operation differs most sharply from on-demand transport. Between confirmation and pickup, the world changes: flights move, the 405 stops, a chauffeur's previous trip runs long. The reservation is a promise about a future that is still being written.
The design question is not "do we track flights" — everyone says they do. It is what happens when the tracked value changes. A system that displays a new arrival time on a screen nobody is looking at has not monitored anything. Monitoring means a changed input produces a notification to a specific person with a specific decision to make. We treat that as the actual deliverable, and it is covered in detail in what flight tracking really does in an airport-transfer operation.
6. Complete
Closing a trip means capturing what actually happened, as opposed to what was planned: actual pickup and drop-off times, actual waiting time, any extra stops, any tolls or airport fees incurred, and anything the chauffeur needs to report.
The failure here is latency. Details captured at the curb are accurate; details captured at the end of a shift are approximate; details captured the next morning are fiction. Whatever the chauffeur uses to close a trip has to work in about fifteen seconds on a phone, in daylight, with one hand — which is a user-interface constraint masquerading as an accounting requirement.
7. Reconcile
Finally, the money has to match, and the trip has to be attributable. Reconciliation is not just payment capture; it is the answer to "which of the things we do actually produces revenue". An operator who knows monthly revenue but not which booking route, referral source or repeat customer generated it is flying on one instrument.
This is the stage that most often does not exist at all. It is invisible to customers, so it never gets prioritised, and its absence is why operators make marketing decisions on instinct.
Where these systems actually break
Across the operations we have seen, failures cluster in three places, and none of them are the booking form.
- The seam between confirm and assign. The reservation is real, but nothing has committed a vehicle to it. It survives in a dispatcher's intention. This is the single most common cause of a passenger standing at a curb with no car.
- Monitoring that displays instead of notifies. The data was correct and present; no human was told. The operator then discovers the system "had the information all along", which is worse than not having it.
- Pricing that lives in people. Rates in someone's head produce inconsistent quotes, and inconsistent quotes produce disputes that cost more than the margin on the trip.
The specific failure modes and the guards that catch them are worked through in the booking and pricing errors that cost operators the most.
What to ask a vendor
If you are evaluating software, the seven stages give you a better script than a feature comparison. For each stage, ask the vendor to show it happening — not describe it.
- Quote: change a rate in front of me, without a developer. Then show me the inputs behind a quote issued last month.
- Hold: show me what an unconfirmed enquiry does to vehicle availability.
- Confirm: show me the reservation record, and tell me which fields are mandatory.
- Assign: try to double-book a vehicle. I want to see the system stop you.
- Monitor: change a flight time in a test booking. Show me who gets told, and how.
- Complete: close a trip on a phone, outdoors, while I time you.
- Reconcile: show me last month's revenue broken down by source.
A vendor who can demonstrate all seven is rare. A vendor who can demonstrate assignment and monitoring is already better than most. The buying framework around this — including the costs that do not appear in the quote — is in how to choose software for a limousine or black-car company, and a worked example of all seven stages in one operation is in our Lux4Rides booking and dispatch case study.
Sources
Questions we actually get asked
Is a chauffeur booking system the same thing as a rideshare app?
No, and the difference is structural rather than cosmetic. A rideshare app is built around dispatch now: the passenger opens the app at the moment of need and the system matches the nearest available driver. A chauffeur booking system is built around prearrangement: the reservation is created hours, days or months ahead, the price is fixed at that moment, and a specific vehicle and chauffeur are committed to a future time slot.
That changes almost everything downstream. Prearranged work needs a quoting engine that can price a trip that has not happened yet, a calendar that can detect a conflict three weeks out, and a monitoring layer that watches a flight the passenger has not boarded. None of those are needed to match a driver standing two blocks away.
Can an operator run on a booking form plus a spreadsheet?
Up to a point, and plenty do. The arrangement survives while one person holds the whole schedule in their head. It fails at a predictable place: the first time two reservations need the same vehicle and nothing in the system objects.
The second failure point is quoting. Once rates live in a person rather than a table, two staff quote the same trip differently, and the operator finds out when a customer forwards the cheaper email.
Which stage causes the most trouble in practice?
Assignment. Quoting errors are embarrassing but usually recoverable; a missed assignment means a passenger standing at a curb. It is also the stage most often left manual because it feels like judgement work — and it partly is. The productive split is to let software enforce the hard constraints (no double-booked vehicle, no chauffeur without the right vehicle class, no assignment that ignores travel time between jobs) and leave the genuine judgement to a dispatcher.