A dispatcher coordinating an airport pickup is not tracking a car. They are maintaining a prediction — the moment a specific passenger will reach a specific curb — and adjusting a vehicle's position against it. Most of the work happens before the chauffeur is anywhere near the airport, and most of the value is in handling the four or five trips a day that go wrong rather than the thirty that go right.
Ask an operator what their dispatcher does and you will usually get a list of nouns: flights, cars, drivers, the board. That is what a dispatcher looks at. What they are doing is narrower and harder to automate.
What a dispatcher is actually holding
For every live airport job, a dispatcher is holding four moving values at once:
- When the passenger will reach the curb. Not when the aircraft lands — a derived estimate that shifts as the flight progresses and the terminal fills.
- Where the assigned vehicle is now. Including whether its previous job is running late.
- How long it takes that vehicle to get from where it is to the curb. Which at an airport is dominated by the airport's own internal circulation, not the freeway.
- What the fallback is. Which other vehicle could cover this if the first one cannot.
Those four values, for every job in the next few hours, simultaneously. The reason experienced dispatchers are valuable is that they hold the fourth one — the fallback — for trips that have not gone wrong yet.
The timeline of one airport pickup
Here is a single prearranged arrival as the operation experiences it. Times are typical for our own Los Angeles operation; the shape generalises to any large airport.
| When | What dispatch is doing | What can go wrong here |
|---|---|---|
| Day before | Confirm the trip exists in the schedule with a vehicle and chauffeur attached. Verify the flight number resolves to a real flight. | A flight number that was mistyped at booking and resolves to nothing, or to the wrong day. |
| Several hours out | Check the inbound aircraft. A late inbound is the earliest reliable signal that an arrival will slip. | Nobody looks, and the slip is discovered at the curb. |
| ~90 minutes out | Lock the plan: confirm the chauffeur is on schedule, confirm the previous job will clear in time. | Previous job overruns and no fallback was held. |
| ~45 minutes out | Chauffeur moves toward the airport and stages nearby rather than at the curb. | Chauffeur arrives at the curb too early and is cycled off by enforcement. |
| Wheels down | Start the curb-time estimate: domestic or international, carry-on or checked, terminal congestion. | Treating landing as arrival and pulling the car up immediately. |
| Passenger contact | Passenger confirms they have bags and are moving; chauffeur is released to the pickup point. | No passenger phone number, or a phone still in flight mode. |
| Curb | Match passenger to vehicle, load, depart, close the arrival portion of the trip. | Two parties at the same door expecting similar vehicles. |
Staging: the decision nobody sees
The single most consequential dispatch decision on an airport job is where the vehicle waits, and passengers never see it.
Stage too far away and the passenger waits at the curb — the failure they will remember. Stage at the curb itself and the vehicle is either paying for access it does not yet need or being moved along by enforcement, which means it is circling when the passenger appears. Airports are specifically engineered to prevent vehicles from idling at terminals, so "just wait outside arrivals" is not a strategy.
The workable answer is a holding position close enough to reach the curb inside the passenger's baggage window, plus a trigger that releases the vehicle. The trigger is the part that matters: it should be passenger-driven ("I have my bags") rather than clock-driven, because baggage delivery is the least predictable link in the chain.
We treat the release trigger as a hard rule rather than a preference: the vehicle moves to the pickup point when the passenger confirms they are walking out, not when the flight lands. It makes the arrival feel slower on paper and faster in practice, because the car arrives while the passenger is walking rather than twenty minutes before they clear baggage.
The corollary is that the passenger's phone number is not an optional field. A booking without a reachable number forces us back onto clock-based guessing, which is why we chase it at confirmation rather than at the airport.
Airport-specific rules about where prearranged vehicles may wait and where they may collect passengers change, and they are set by the airport rather than by the operator. For current LAX rules, the authority is Los Angeles World Airports' own ground transportation information — not a car service's blog post, including ours.
The four exceptions that consume the day
A dispatcher's day is not thirty identical jobs. It is thirty jobs that mostly run themselves and four that eat the afternoon. In our experience they are almost always one of these:
- The moved flight. Delay, early arrival, gate change, or diversion to another airport entirely. Early arrivals are more disruptive than delays, because the staged vehicle has less warning.
- The overrunning previous job. A chauffeur's earlier trip runs long and quietly threatens the next two. Catching this needs someone looking at the chain, not the individual job.
- The unreachable passenger. Phone off, wrong number, or a passenger who has walked to a different door. Resolution is manual and slow.
- The changed party. More passengers or more luggage than booked, which can mean the assigned vehicle physically cannot take the job. This is a vehicle-class problem created at booking — see matching the vehicle to the job.
Three of those four are detectable earlier than they are usually detected. That is the actual automation target.
What software should and should not take over
The useful division is between watching and deciding. Software is better than any human at watching. It is worse than a competent dispatcher at deciding, because deciding requires knowing that this particular passenger travels with a wheelchair, or that this chauffeur is reliable under pressure.
| Task | Who should own it | Why |
|---|---|---|
| Watching flight status for every live job | Software | Continuous, mechanical, and a human will miss one. |
| Detecting a schedule conflict or overrun | Software | A constraint check, not a judgement. |
| Deciding which chauffeur covers a failed job | Human | Depends on knowledge of people that is not in the database. |
| Deciding when to warn the customer | Human | Tone and timing matter; a premature automated alert creates anxiety. |
| Recording actual times and extras | Software | Accuracy decays with delay; capture at the curb. |
| Releasing the vehicle to the curb | Both | Software prompts on the passenger signal; the chauffeur confirms. |
Put differently: a dispatch system's job is to ensure that by the time a human is involved, the human is being asked a question rather than told a fact. "Flight AA118 is now 40 minutes early — move the 3pm assignment?" is useful. A screen that silently updates an arrival time is not. This is the distinction we develop in what flight tracking really does, and the same principle drives the constraint rules described in how a chauffeur booking system actually works.
If you are the dispatcher and the driver
Most transportation companies are small, and in a small company the dispatcher is also driving. The four values from the start of this article still have to be held — but by someone whose hands are on a steering wheel.
Three things carry disproportionate weight at that scale:
- Automated flight watching is not a luxury, it is the whole point. A one-person operation cannot monitor a flight board while driving. This is the single highest-value thing to automate first.
- Notifications must be push, and must be specific. A message that says what changed and what to do can be absorbed at a red light. A dashboard cannot.
- The fallback has to be pre-arranged, not improvised. A standing relationship with one trusted affiliate operator, agreed before it is needed, is worth more than any software feature — because the failure mode software cannot fix is that there is only one of you.
For a full worked example of how this is wired in one operation, including where the automation boundary sits, see our Lux4Rides booking and dispatch case study. For the passenger's view of the same process, see how an LAX transfer is coordinated, step by step.
Sources
Questions we actually get asked
Why can a car not simply be sent when the flight lands?
Because landing is not arrival. Between wheels-down and a passenger reaching a curb there is taxi time to the gate, deplaning, immigration and customs on international arrivals, and baggage. At a large airport that spread runs from roughly fifteen minutes for a carry-on domestic passenger to well over an hour for an international arrival at a busy hour.
A vehicle dispatched at wheels-down either waits and burns paid curb access, or is moved off and has to come back. The dispatcher's job is to predict the curb moment, not the landing moment.
Does a bigger operation need more dispatchers, or better software?
Both, but in an order. Software first removes the mechanical load — watching flight boards, retyping addresses, noticing conflicts — which is most of what a dispatcher does on a normal day. What is left is exception handling, and exception handling scales with headcount rather than code, because each exception is a judgement about a specific passenger.
Operators who add dispatchers before automating the mechanical load end up paying people to watch screens.
What does "live dispatch" mean when a company advertises it?
It should mean a human is reachable and empowered to change a trip in progress, at any hour. It sometimes means an answering service that can take a message. The distinguishing question is simple and worth asking before you book: if my flight diverts at 2am, who moves my car, and are they awake now?