Airport transfers look like the simplest work an operator can take. One pick-up, one destination, a fixed price, no negotiation. In practice they are the most operationally fragile jobs in the business — because you have committed a driver to a moment in time that someone else controls.
A flight moves and your whole afternoon moves with it. This is why transfer specialists obsess over things that sound trivial: which flight, which terminal, how long we wait, who pays for the wait.
Here is what a booking system has to handle if transfer work is a real part of your revenue.
The flight number is a data field, not a note
This is the single biggest difference between a system that suits airport work and one that does not.
In most generic dispatch tools, the flight number ends up in a free-text comment box. Nobody watches it. The pick-up time stays where the customer originally typed it. When the flight is two hours late, one of two things happens: your driver sits at the terminal burning an afternoon, or the passenger lands to no car.
What you actually need:
- The flight number captured as a field, validated at booking time
- The scheduled arrival, so the pick-up time is derived rather than guessed
- A way to see status before dispatch — the last check before a driver leaves matters more than continuous tracking
- A clear rule for how far a pick-up moves when an arrival shifts, and who confirms it
If a system cannot separate “the time the customer asked for” from “the time the driver should actually leave”, it will fight you on every delayed arrival.
A word on realism: full automated flight-status integration is a genuine feature with a genuine cost, and not every operator needs it. If you do twenty transfers a month, a disciplined manual check an hour before dispatch works fine — as long as the flight number is somewhere findable. If you do two hundred, manual checking is a full-time job you have not hired for.
Waiting time is where the margin quietly dies
Almost every dispute on airport work is about waiting. The passenger cleared immigration in ninety minutes; the driver was there for ninety minutes; who pays?
The answer must be decided before the booking, visible to the customer, and stored on the job:
- How much free waiting time is included after landing — commonly a period measured from the actual arrival, not the scheduled one
- What happens for delayed arrivals — is free waiting measured from the new landing time?
- The charge per period after free waiting ends
- Whether waiting is billed in fifteen-minute blocks or by the hour
- What counts as arrival — wheels down, or the passenger reaching the meeting point
A system that only holds a price cannot express this, so it gets written in an email and forgotten by invoicing. The result is either an argument with a good customer or an unbilled hour. Both are expensive; the argument is worse.
Get this on the confirmation the customer receives. A waiting policy the customer has already read is not a dispute.
Meet and greet is a promise you have to keep
“Meet and greet” means different things at different price points, and if it is not specified you will be judged against whichever version the customer imagined.
Record it explicitly on the booking:
- Kerbside or inside arrivals with a name board
- The exact meeting point — and terminals change theirs
- The name on the board (which is often not the booker’s name)
- Whether the driver parks and waits or circulates
- Who calls whom, and when — “call when you have your bags”, “text only”
- Parking cost, and whether it is included or passed on
None of this is exotic. All of it goes wrong when it lives in a WhatsApp thread rather than on the job. The driver who has the booking on their phone should see the meeting point and the board name without ringing the office at 6am.
No-shows: the cost you can design away
A no-show on an airport job is a driver’s morning for nothing, and it is nearly always avoidable.
The genuine no-shows are rare — a missed connection, a cancelled flight. The rest are communication failures: the customer forgot, gave the wrong terminal, went to the wrong door, or never saw the confirmation because it landed in spam.
Three things cut them dramatically:
- A confirmation the customer actually reads — sent immediately, with the pick-up point, the driver contact and the waiting policy in plain language.
- A reminder before the pick-up — around 24 hours out for outbound trips, so a wrong terminal or a changed time surfaces while it is still fixable.
- A driver reminder a few hours ahead, with the meeting point and board name.
These are automations, not habits. A reminder that depends on someone remembering to send it is not a control. Ask any vendor whether reminders fire automatically on a schedule you set — and, crucially, whether they re-schedule themselves when the pick-up time changes. A reminder that still fires at the old time after you moved the job is worse than none.
Then decide and publish a no-show policy: how long the driver waits before standing down, what is charged, and how the customer is told. Enforce it consistently. Operators lose more to inconsistent enforcement than to the no-shows themselves.
Return legs and the second booking nobody takes
Most airport passengers fly home. A meaningful share of transfer revenue is simply the return journey — and it is routinely left on the table because nobody asked.
Your system should make the return leg trivial: duplicate the job with the direction reversed, pre-fill the customer, price both together. Operators who quote outbound and return as a pair convert noticeably more of the second trip than those who wait to be asked.
The same applies to the repeat customer. Somebody who flies monthly is worth far more than a single fare, but only if you have their history to hand when they call. That is a CRM question, not a dispatch question.
Pricing that survives contact with reality
Fixed transfer pricing is what customers want and what wins the booking. It only works if the edges are defined:
- Zones or postcode-based rates, so quoting is consistent between staff
- Vehicle class — saloon, estate, MPV, first class
- Passenger and luggage limits per class, checked at booking, because a family of four with skis is not a saloon job
- Out-of-hours supplements — the 04:00 airport run is the least popular shift you have
- Extra stops, child seats, additional passengers
- Tolls, parking and congestion charges — included or extra, stated up front
The test for any system: can two different staff members quote the same job and reach the same number without asking each other? If not, your pricing lives in someone’s head, and it will leave when they do.
What to ask on the demo
Bring one real, awkward job and make them run it:
- A booking arrives for a flight landing at 06:20 on the 14th. Where does the flight number go?
- The flight is delayed by 100 minutes. What changes, and who is told?
- The customer asks by WhatsApp for a child seat. Where does that message live?
- The passenger takes 70 minutes to clear customs. How is the waiting charge calculated and added to the invoice?
- The passenger never appears. What does the driver do, what is charged, and what does the customer receive?
- The customer wants the return leg two weeks later. How many clicks?
- Show me every airport job in March with its waiting charges.
If the demo handles one to seven without a spreadsheet, it is built for transfer work. If it stalls at question two, it is a taxi tool with an airport label.
The child-seat message, and where it ends up
Of the seven above, the one that exposes a system fastest is the third: where does the WhatsApp message about the child seat live?
We build RideDesk, so this is a disclosure rather than an impartial review. Its answer is that the message lives on the booking — customer emails and WhatsApp threads sit inside the job alongside the pickup, the flight and the allocated driver, because that is the single failure we saw ruin more airport mornings than delayed flights ever did. The flight itself is watched too: airport jobs pull live flight status, including terminal and gate where the data source provides them, so the 5am “has it landed?” check happens on the booking rather than in a second tab. The automations that matter here run on a schedule you set: a customer reminder before pickup, a driver reminder a few hours out, a payment nudge on an unpaid invoice, a review request afterwards. Every booking also records where it came from, so you can tell which routes actually produce transfers.
It is built for pre-booked transfer and chauffeur work, not instant street hail. To put it against your own worst Monday, get in touch, or see how FrankfurtRide runs its transfers.
Whatever you run, the discipline matters more than the software: decide your waiting policy before the booking rather than during the argument, put it in the confirmation, and make sure the flight number lives somewhere a human will actually look an hour before dispatch. Most no-shows are not passengers who vanished — they are messages that never reached anyone. And if the harder truth is that the airport bookings are not arriving at all, that is a ranking problem rather than an operations one: start with how to rank for airport transfers in your city.
