Shuttle management software is a promise about waiting time, not about maps

Shuttle management software is judged on one number, and it is not the position of the bus. It is how long a customer with a suitcase stood on a kerb at 05:12 on a Friday in July.

Every product ranking on this search sells vehicle tracking to campuses, hotels and corporate transport fleets. They optimise the map. An off airport car park is not a transport company, the route is two points, and the map is not the thing that goes wrong.

What a map tells you and what it does not

A map tells you where a vehicle is. It does not tell you that four people are standing outside your office with two large cases and a pushchair, and that three of them walked out ninety seconds after the shuttle left.

On a campus, vehicle position genuinely is the answer. The passengers are anonymous, the route is fixed, the stops are published, and the question a rider asks is "where is it". At an off airport car park the route is your gate to a terminal and back, eleven minutes each way, with nothing to optimise. Every passenger is a named booking with a flight number and a party size. The question is not where the vehicle is. It is who has been waiting longest, and whether the driver about to leave knows about them.

The promise you actually sold

The customer bought a shuttle that runs every fifteen minutes, or on demand, or whatever your booking page says. That sentence is the specification, and it is the only one a customer can verify from a kerb with a phone in their hand.

What they experience is headway, the gap between two departures. What you plan is frequency, runs per hour. Those two are the same number only when the runs are evenly spaced, and at 05:00 in July they never are. Two vehicles leaving four minutes apart and then nothing for twenty-six minutes is four runs an hour and a bad morning. There is a longer version of this in manage shuttle headway, not shuttle frequency.

Where the waiting list comes from

Nothing in a car park observes a customer landing. The waiting list is a declaration, made by a person, at a moment somebody chose, and everything downstream is built on that declaration and its timestamp.

The trigger varies. The customer rings the number on their voucher. They text. They walk up to the desk at arrivals. The dispatcher sees the flight marked landed on a public tracker and calls them. Whatever it is, a human types "these four are waiting, they are at door 4", and that is the moment the clock starts.

ParkAgenda has no flight feed. The console links out to a public tracker and no flight data enters the product. If a vendor tells you their system knows your customer has landed, ask which feed, what it costs per month, and what it does on a diverted flight to a different airport. The answer to the third one is usually silence.

Two zones, and why the order matters

A shuttle board needs exactly two zones: people who are actually waiting, and today's bookings sitting there as offers. Nothing moves from the second into the first until a person says so.

The bottom zone is inert. It is the day's arrivals and departures, sorted, with passenger count, phone number, spot, return flight number and a terminal hint. The top zone is a live queue of legs, each in one state: waiting, claimed, picked up, dropped off. A driver claims a leg from their phone, which is the mechanism that stops two drivers arriving at the same door for the same family.

The field that earns its place more than any other is the pickup note typed during the phone call. "Door 4, past the Relay, grey coat, one large case, wife in a wheelchair." That sentence saves five minutes of a driver walking the length of a terminal, and it is worth more on a July Friday than any map.

Count the not-found attempts

A not-found is a driver who arrived and could not find the customer. It is the most useful number on the board and almost nobody records it.

Every not-found is three things at once: a run that carried nobody, a customer who is now angrier than they were, and a second run you have to fit into an hour that was already full. Recorded against the leg, it tells you which terminals, which hours and which channels produce them, and most of them turn out to be one terminal at one time of day with one instruction that was never written down. Unrecorded, the same thing just looks like a slow shuttle, and the fix you buy is a third vehicle you did not need.

Measuring kerb wait without GPS

You do not need vehicle tracking to measure the wait. You need two timestamps per leg: the moment the customer was declared waiting, and the moment a driver marked them picked up. Everything useful comes out of the gap between those two.

Take a 400 space car park, eleven minutes each way to the terminals, two eight seat shuttles. On a Friday in July, 61 outbound customers are due at the terminals between 04:00 and 07:00, and 34 of them fall inside the 05:00 hour because two carriers push a wave of 06:50 departures. These numbers are an example, not a customer's.

Capacity is not the problem. Two vehicles on an eleven minute leg give you roughly five departures an hour from the lot and forty seats against thirty-four people. The problem is sequencing. A driver leaves at 05:02 with the two parties standing outside the office. Four more walk out at 05:04. They wait twenty minutes for a vehicle that left with six empty seats.

The fix is not a map. It is a dispatcher who can see that four bookings are due to depart within the next fifteen minutes and holds the vehicle for two minutes. Two timestamps per leg give you the distribution afterwards: median wait and the tail. The tail is the number that gets written into reviews. If your median is six minutes and your ninetieth percentile is twenty-seven, you do not have a shuttle problem. You have a 05:00 problem, on a handful of mornings you could name from last year's departures.

What ParkAgenda does here, and what it does not

ParkAgenda runs the board and the legs. It does not track vehicles, and it is worth being blunt about that before a demo rather than during one.

Not in the product:

• No live GPS, no map and no vehicle position.
• No ETA calculation and no automatic dispatch. The system does not decide who goes next. The dispatcher does, and the board shows who has waited longest.
• No route optimisation. There is no route to optimise.
• No flight tracking. The console links out to a third party tracker and no flight data enters the product.
• No SMS and no push to the customer. Email is the only channel out of the product.

In the product:

• A two zone board per parking, one panel per site rather than one merged stream, because merging two sites into one dispatch queue breaks the reconciliation afterwards.
• Legs moving through waiting, claimed, picked up and dropped off, with not-found attempts counted against the leg.
• Passenger count, phone number with a call button, the pickup note typed during that call, the spot, the return flight number and a terminal hint read out of the booking comment.
• A shift agenda per parking with an hourly demand hint built from expected arrivals and departures, so the 05:00 hour gets staffed against the movements rather than against habit.

If live vehicle tracking is a hard requirement for you, buy a telematics product and run it alongside. It answers fleet questions: mileage, driving style, where a van is when a driver stops answering. Those are real questions. They are a different purchase, and the customer on the kerb cannot feel the answer to any of them.

How to staff the 05:00 hour

Roster against the movement curve, not against the shift you have always run. The curve is already in your bookings and most operators have never plotted it.

1. Pull expected arrivals and departures per hour for the same week last year. Look at the hour, not the day.
2. Put the second driver on forty-five minutes before the wave, not on the hour. The wave starts before you think it does, because customers arrive early for a flight they are nervous about.
3. Put a dispatcher on the phone through the peak. On a bad Friday the pickup note is worth more than a third vehicle, and it costs nothing to try that first.

The driver's side of the same board is covered in airport shuttle software has one job, telling the driver what is already waiting, and the channel side, where the booked party size comes from in the first place, in what a parking booking system has to do when you do not own the sales channel.

Questions we get asked about this

Do I need GPS tracking on my airport shuttles?

For measuring customer wait, no. Two timestamps per leg cover it and they are free. GPS answers fleet questions instead: mileage, driver behaviour, where a vehicle is when it stops replying. Buy it for those reasons, not to fix a queue.

What is a good kerb wait for an off airport car park?

The one you sold. If your booking page promises a shuttle every fifteen minutes, then your ninetieth percentile wait is the number to manage, not your average. An average of six minutes hides every morning that matters.

How does a dispatcher know a customer has landed?

Somebody tells them. A call, a text, a walk-up, or a dispatcher watching a public tracker and picking up the phone. No car park software observes a landing by itself, and any product that says it does is reading a third party flight feed you should ask about by name.

What to do next

Take last July, pick your three worst Fridays, and write down for each one how many customers were due at a terminal in each hour. If the shape is a spike rather than a slope, your shuttle problem is a sequencing problem and no map will fix it. The board and the shift agenda are on the features page.