Booking and Dispatch Software for Transfer and Shuttle Companies

Almost all booking software in this category was designed for tours. That is fine until you try to run transfers on it, at which point you discover the system wants a departure time and a capacity while your actual business runs on origins, destinations, vehicles and drivers.

Most transfer operators end up in the same place: bookings in the software, and the real operation in a spreadsheet or a group chat. This is about what actually differs, what to look for as a result, and where booking software stops being the right tool.

Why transfers are structurally different

The gap is not a missing feature. It is a different shape of thing being sold, and four consequences follow.

The booking has two ends. A tour has a meeting point. A transfer has an origin and a destination, and both need capturing precisely — a hotel name is not an address, and an address is not a pickup point at a terminal with four of them.

What is scarce is a vehicle over a window, not a seat. A tour with sixteen seats can sell them one at a time. A transfer commits an entire vehicle and driver for the journey plus the time to get there and back, so selling one transfer does not reduce capacity by one — it removes a block of time from a specific vehicle.

Departures are continuous, not scheduled. You are not running the nine o'clock. You are running whatever times customers ask for, which means availability is a question about vehicle utilisation rather than about remaining seats on a listed departure.

The cost is incurred before the customer appears. A no-show on a tour costs you an empty seat. A no-show on a transfer costs you a driver who has already driven across the city, which is why prepayment matters more here than almost anywhere else in travel.

The empty leg nobody prices

The cost line with no equivalent in the tour business, and the one most likely to be quietly eroding your margin: the vehicle has to get to the pickup, and it has to get back afterwards.

A forty-minute transfer to a hotel an hour outside the city is not forty minutes of vehicle time. It is potentially two and a half hours once repositioning is counted, and if you priced it on the journey the customer takes, you priced a third of what it cost you.

• Price on vehicle time committed, not passenger time travelled. That is the number that determines how many jobs a vehicle can do in a day.
• Pair legs where you can. An arrival and a departure from the same hotel, or two jobs in the same direction an hour apart, halve the repositioning. Being able to see the day laid out is what makes this visible.
• Charge properly for outlying destinations rather than applying a distance-based rate that ignores the return.
• Watch for the trap of cheap long-distance work that leaves a vehicle stranded three hours from your next booking.

This is the transfer equivalent of a tour operator publishing more capacity than they can staff — the number that looks fine on paper and fails on the day.

Airport transfers and the flight problem

Airport work is most of the market for many transfer operators, and it carries a complication nothing else in travel has: the booked time is not the real time.

A guest books a pickup for 14:00 because that is when their flight lands. The flight lands at 16:40. Your driver has been at the terminal for nearly three hours, or was not there at all — and neither outcome is acceptable.

What handles it:

• Capture the flight number at booking, as a required field on airport products. Without it you cannot check anything, and asking afterwards is a message most guests will not answer.
• Build in a buffer by default — arrivals need time for immigration and baggage, and the honest figure for that varies enormously by airport and by season. Set it per airport rather than globally.
• Check arrivals before dispatching. Whether that is automated or somebody looking at a screen depends on your size, but it needs to be somebody's job at a defined time.
• Write down the waiting policy — how long the driver waits, what happens after that, and what a significantly delayed flight costs. Decide it once rather than repeatedly at the roadside.
• Give the guest a way to reach the driver that works on a foreign phone with no local credit, which in practice means a messaging app rather than a call.

Departures have the mirror problem and get less attention: a guest who misses a flight because the pickup was cut fine will hold you responsible, and they are not entirely wrong. Build the buffer into the product rather than leaving it to whoever takes the booking.

Per-route and per-vehicle pricing

Tour pricing is per person. Transfer pricing usually should not be, because your cost is the vehicle and driver whether one passenger travels or four.

The structure that works for most operators is a price per route per vehicle class — sedan, minivan, minibus — with the passenger count determining which class is offered rather than what is charged. Shared shuttles are the exception and genuinely are per seat, which is why an operator running both needs software that can express both without a workaround.

• Define your routes as products, with a fixed price each, rather than trying to compute distance on the fly. Guests want a number before they book.
• Handle luggage and child seats explicitly. Both change which vehicle is required and both cause arguments at the kerb when unstated.
• Decide your night and holiday supplements in advance and publish them, since a 04:00 airport run genuinely costs more to staff.
• Price waiting time beyond your included window, and say so at booking rather than on an invoice afterwards.

A common mistake worth naming: quoting a per-person price for a private vehicle because the booking system only supports per-person pricing. It confuses guests, it makes a party of one look expensive, and it is the tail wagging the dog.

Where booking ends and dispatch begins

These get conflated, and the distinction determines whether you need one system or two.

Booking software sells the job, takes the money, holds the details and tells you what tomorrow looks like. Dispatch software allocates jobs to drivers in real time, tracks vehicles, and reassigns work as the day moves.

Which you need is mostly a question of fleet size and how much changes during the day:

• A handful of vehicles, mostly pre-booked work: booking software with a clear day view is sufficient. The allocation happens the evening before and rarely changes, and adding a dispatch system would be solving a problem you do not have.
• A larger fleet with same-day work and frequent reassignment: you need real dispatch — live vehicle positions, jobs pushed to drivers, reallocation mid-shift. Booking software will not do this and should not pretend to.
• In between: booking software plus a disciplined daily process, reviewed each season to see whether the manual coordination is still cheaper than the software.

Be honest about which you are, because buying dispatch capability for a four-vehicle operation is the transfer version of overbuying, and running a twenty-vehicle same-day operation off a booking calendar is the opposite mistake.

Getting the day to the driver

Whatever system you run, the last step is the same: a driver in a vehicle needs to know where to be, when, for whom.

• Their jobs only, in time order, on a phone. Not the whole company's day.
• Pickup as a map pin, not an address typed into a message. Addresses resolve badly and drivers should not be transcribing.
• Passenger name, count, luggage and phone number, plus the flight where relevant.
• Whether payment is outstanding, because a driver collecting cash needs to know and a driver asking for money already paid is a complaint.
• A way to confirm completion, which is what settles a later dispute about whether the transfer ran.

With subcontracted drivers there is an extra requirement: assigned is not the same as confirmed. A job sent to a partner who has not acknowledged it is a wish, and at 05:30 that distinction is expensive.

Payments and the numbers that matter

Take payment at booking wherever you can. The argument is stronger for transfers than for tours because the cost is already spent when the guest fails to appear — the driver drove there regardless.

Where you cannot — corporate accounts, hotel partners, agency work — you need invoicing rather than checkout, and a clear record of what was delivered against what was agreed. That is a genuine requirement for transfer operators and one many tour-shaped platforms handle poorly.

Three numbers worth watching, none of which appears in standard tour reporting:

• Vehicle utilisation — hours committed against hours available, by vehicle. This tells you whether to add a vehicle or fix your scheduling.
• Revenue per vehicle-hour, including repositioning. The figure that reveals which routes are genuinely worth running.
• Jobs by source — direct, hotel partners, agencies, marketplaces — with net revenue after commission, because transfer work arrives through a wider mix of channels than most tour businesses.

Hotel and agency relationships deserve particular attention here, since for many transfer companies they are the main channel rather than a supplement — the partnerships guide covers the commercial models, and the thirty-second test at a hotel desk applies exactly as much to a transfer as to a tour.

Where Travelity fits

Transfer providers are one of the four business types we build for, alongside tour operators, agencies and independent guides — so transfers are a first-class case rather than a tour with the labels changed. Bookings from your own site, partners and marketplaces land in one place, payment is taken at booking through the booking widget, and daily operations gives you the day's jobs with guest details attached.

Plans are $39, $139 and $399 a month, with a 21-day trial requiring no card, and fees of 1.9% on online bookings and 0% on offline ones — the second of which matters here, since a large share of transfer work arrives by phone or through a hotel desk rather than through a website.

What we are not: a real-time fleet dispatch system. If you are reassigning jobs across twenty vehicles during a shift, tracking positions live and pushing work to drivers as it changes, that is a dedicated category of software and you should buy it. We are a booking and operations platform, which suits pre-booked transfer work and the small to mid-sized fleets that run it.

Testing the fit

The trial is 21 days without a card. Build your most complicated route first — the airport run with a flight number, luggage, a child seat and a night supplement. If that models cleanly, the rest will.

Frequently asked questions

Can I use tour booking software for airport transfers?

You can, but check how it models the job before committing. Tour software is built around seats on a scheduled departure, while a transfer is a vehicle committed to a journey between two points. If the system cannot hold an origin, a destination and a vehicle assignment, you will end up keeping the real information somewhere else.

What is the difference between booking software and dispatch software?

Booking software takes the reservation, holds the money and tells you what is happening tomorrow. Dispatch software allocates jobs to drivers in real time and reacts to changes during the day. Small fleets generally need the first with a simple way to share the day plan; larger fleets reassigning jobs hour by hour need the second as well.

How should transfer companies price their routes?

Per vehicle and per route rather than per person, in most cases, because the cost is the vehicle and driver for the journey whether one passenger travels or four. Price by vehicle class, and remember to account for the return leg — a transfer to a remote hotel occupies the vehicle for the trip back as well.

How do transfer companies handle flight delays?

The booked time and the actual pickup time are different things, so capture the flight number at booking and check arrivals before dispatching. Set a written policy on how long a driver waits and what a significantly delayed flight costs, because that decision made repeatedly on the day will otherwise be inconsistent.

What should transfer operators look for in booking software?

That it can store a route rather than only a departure, assign a specific vehicle and driver, capture flight numbers and pickup addresses at booking, price by vehicle rather than per head, and put the day plan on a driver phone. Anything that cannot hold a route and a vehicle will leave you running the operation in a separate spreadsheet.

Bottom line

Test any platform on one question: can it hold a route and a vehicle, or does it want you to invent a product for every departure time? That single check predicts whether you will be running a parallel spreadsheet by mid-season.

Then price on vehicle time committed rather than passenger time travelled, capture flight numbers as a required field, take payment at booking because your cost is already spent when nobody appears, and be honest about whether you need dispatch or just a day view a driver can read.

Related guides

• Tour booking software for small operators: a complete guide
• Managing tour operations: guides, schedules and capacity
• Partnering with hotels and local businesses to grow bookings
• Reducing no-shows for tours and activities
• Communicating with guests before, during and after the tour
• How transfer companies can reduce no-shows and manage dispatch