How to choose software for a limousine or black-car company

We build custom transportation software, so treat this page accordingly: it is written by an interested party. What makes it worth reading anyway is that the honest answer for most operators is do not commission a custom build yet, and the framework below is the one we use to work out whether that is true for a particular company.

The three real options

The middle row is where most operators belong. The industry platforms exist because the core problem — prearranged reservations, vehicles, chauffeurs, flight monitoring — genuinely is common across companies. Paying to rebuild a solved problem is not sophistication.

What to test before you sign

Feature lists are written to survive comparison. Behaviour is not. Insist on doing these six things yourself, in a live or sandbox system, before any commitment. Each maps to a stage of the reservation lifecycle described in how a chauffeur booking system actually works.

1. Change a rate. Yourself. Add a route, adjust a time band, create a surcharge — with no developer and no support ticket. If pricing changes require the vendor, your pricing will stop changing.
2. Try to double-book a vehicle. Assign two overlapping trips to the same car, including two that are impossible only because of travel time between them. The system should stop you. A warning you can click through is not a constraint.
3. Move a flight. In a test booking, change the flight to one that is delayed, then to one that is early. Ask to see exactly who gets notified, through which channel, and what the message says. This is the test most platforms fail — see what flight tracking really does.
4. Close a trip on a phone, outdoors, one-handed, while someone times you. If it takes more than about fifteen seconds, your chauffeurs will do it later from memory, and your trip data will be approximate.
5. Book on your own phone as a customer. The whole flow, on cellular, at the screen size your customers actually use. Count how many taps and how much typing. See building a booking flow that works on a phone at the curb.
6. Ask for last month's revenue by source. Not total revenue — revenue attributed to booking channel, referral and repeat customer. Many platforms cannot answer this, and an operator who cannot answer it is making marketing decisions blind.

Then add a seventh, which is not a software test at all: ask what the system does about your compliance obligations. In California, a charter-party carrier has to participate in the DMV Employer Pull-Notice programme and the CPUC's drug and alcohol testing programme, and has records to retain. Software that holds chauffeur records without any awareness of those obligations has left the awkward part with you — which may be fine, but should be a decision rather than a discovery.

The costs that are not in the quote

The monthly licence is usually the number everyone negotiates and rarely the number that hurts.

• Per-lookup and per-message charges. Flight data, geocoding, mapping, SMS. These scale with reservation volume, which means the cost rises exactly as the business grows.
• Payment processing. A percentage of revenue, not a fixed fee, and frequently the largest software cost an operator has.
• Setup and data migration. Moving existing customers and rate tables in. Charged once, and frequently underestimated by both sides.
• Configuration labour. Yours. Building the rate table properly is days of work whoever owns the software, and it is the work most likely to be done badly under time pressure.
• Staff transition. The period where dispatchers run the old and new systems in parallel because they do not yet trust the new one. Budget for it; it always happens.
• The workarounds. The most expensive and least visible cost. Every mismatch between the platform's assumptions and your operation becomes a manual step, performed forever. A single daily workaround costing ten minutes is over forty hours a year.

Questions about leaving, asked before you arrive

Ask these during the sales process, when you have leverage, rather than in two years when you do not:

• Can I export my full customer list, reservation history and rate tables, in a usable format, without asking you? Self-service export is the single best indicator of a vendor's confidence.
• Whose domain does the booking flow run on? If it is theirs, the search and referral value you build accrues to their URL.
• Who owns the customer communications? If confirmations come from the vendor's address, your customers' relationship is partly with the vendor.
• What happens to trips in flight if I cancel? There should be a defined wind-down, not an abrupt switch-off.
• If I need a change to how the system works, what is the process and the realistic timeline? The answer tells you whether you are a customer or a tenant.

When off-the-shelf stops being enough

Custom is the right answer less often than people selling it suggest. In our experience it becomes genuinely rational when at least two of these hold:

1. Your pricing model does not fit the platform's. Not "we want different numbers" — different structure. Negotiated corporate tariffs, multi-day itineraries, event logistics with staged vehicles, or affiliate networks with their own rate cards.
2. The workarounds have become a job. Counted and costed, per the note above.
3. The booking experience is strategically important. You compete on the booking experience itself, or you need it wholly under your brand and domain for reasons that outlast any vendor.
4. You have operational data nobody else has, and cannot use it. Years of trip history that could inform pricing and staffing, locked in a format you cannot query.
5. You are being charged for growth. Per-vehicle or per-user pricing that makes expansion disproportionately expensive.

Conversely, if your complaint is that the interface is ugly, or that one report is missing, or that a competitor has something shinier — that is not a custom build. That is a support ticket or a different platform.

A decision you can defend

Write down, before you talk to anyone:

• The three workflows that waste the most time today, with a rough hours-per-week number against each.
• The two failures that have actually cost you customers in the last year.
• Whether the booking experience needs to be on your domain, and why.
• Your realistic reservation volume for the next two years, for pricing the usage-based costs.

Then run the six tests against every candidate and price the full cost. A vendor who performs well on assignment constraints and flight-change notification is already better than most of the market, and those two are the failures that lose customers.

If you want to see how the seven stages look wired end to end in one real operation — including where we drew the automation boundary and what we got wrong first — that is our Lux4Rides booking and dispatch case study.