Most dispatch demos look impressive. Most in production disappoint. Here is what separates tools that work from tools that get abandoned within 90 days.
Every shuttle dispatch product demos well. A map with moving dots. Clean assignment panels. Smooth animations. In the demo, everything works because there are three shuttles, five pickups, and zero exceptions.
In production, there are eight shuttles across four terminals, 47 pending pickups, two drivers on break, one vehicle with a flat tyre, a flight delay affecting 12 customers, and a dispatcher who has been on shift for six hours. That is where dispatch software is actually tested.
The question is not whether the software looks good. The question is whether it reduces the cognitive load on your dispatcher when everything is happening at once.
This is table stakes. If the dispatch software does not show you where every shuttle is, right now, on a map, it is not dispatch software. It is a booking list.
GPS tracking must be continuous (not periodic check-ins every 5 minutes), accurate to within 50 metres, and displayed on a map that your dispatcher can read at a glance during peak operations. The position data must be used for assignment recommendations - not just displayed as a visual.
Test this in evaluation: ask the vendor to show the tracking refresh rate. If positions update every 30-60 seconds, the system is operating on stale data during peak hours when shuttle positions change every 2-3 minutes.
An airport is not a single point. It is a set of terminals separated by distance, traffic patterns, and access routes. A dispatch system that treats the airport as one location will consistently make suboptimal assignments.
Terminal-aware dispatch means: the system knows that Terminal 1 is 4 minutes from your facility via the service road, Terminal 3 is 11 minutes via the main access, and Terminal 5 is 8 minutes but has a 3-minute queue at the pickup zone during 17:00-19:00.
These distances and time estimates should update based on historical traffic data, not just static calculations. A system that recommends sending your nearest shuttle to Terminal 3 at 17:30 without accounting for the pickup zone queue is making a bad recommendation.
The most valuable data source for shuttle dispatch is not your booking system. It is flight arrival data.
When Flight NZ247 lands at Terminal 2 at 14:32, and you have 6 customers on that flight, you should not wait for 6 phone calls. The system should create a pickup demand forecast 15-20 minutes before those customers reach the pickup zone, recommend a shuttle pre-positioning, and send automated notifications to the customers.
This single integration transforms dispatch from reactive (wait for call, then respond) to proactive (anticipate demand, pre-position vehicle). Average pickup time drops from 10-15 minutes to 4-7 minutes.
Evaluate: does the vendor use real-time flight data (FlightAware, FlightStats) or scheduled departure/arrival times? Scheduled times do not account for delays - and delays are when dispatch stress is highest.
The single highest-volume inbound call at off-airport parking facilities is: where is my shuttle?
This call consumes dispatcher time, interrupts coordination flow, and generates customer frustration. The fix is automated ETA notifications via SMS.
When a shuttle is assigned: "Your shuttle is on the way. Estimated arrival: 7 minutes. Pickup at Terminal 2 Zone B." When the shuttle is 2 minutes out: "Your shuttle is arriving now."
These two messages eliminate 30-40% of inbound calls. That is not a convenience feature. It is an operational efficiency gain that compounds every day.
The dispatch system’s value is measured not by how it handles normal operations, but by how it handles exceptions.
Flight delayed 2 hours? The system should automatically reschedule the predicted pickup, free the assigned vehicle, notify the customer, and update the demand forecast.
Vehicle breakdown? Redistribute pending assignments across the remaining fleet within 60 seconds, alert the operations manager, and update affected customer ETAs.
Customer at wrong terminal? Reroute the nearest available vehicle without requiring the dispatcher to cancel and recreate the assignment.
If your dispatcher still needs to manually manage exceptions by cancelling assignments, calling drivers on the radio, and sending individual customer messages, the software is not handling dispatch. It is displaying dispatch.
Dispatch data should answer these questions monthly:
- What is our average pickup time, and is it improving? - Which terminal has the longest average wait? - What is our vehicle utilisation rate, and are we running too many or too few shuttles? - How many dead miles are we driving, and which routes generate the most waste? - Which drivers are most efficient, and what do they do differently? - What time windows have the worst service quality?
If the dispatch system cannot answer these questions from its own data, you are operating blind. You will make fleet sizing decisions, driver scheduling decisions, and terminal staging decisions based on intuition rather than evidence.
The dispatch software that matters is the one your dispatchers are still using 90 days after deployment. The reasons systems get abandoned:
- Too slow: map takes 3 seconds to update, assignments lag behind real-time positions - Too complex: requires 4 clicks to make a simple assignment that the old radio method handled in 5 seconds - No exception support: works fine on normal days, useless on the days that matter most - Bad mobile experience: drivers cannot use the app effectively in a moving vehicle - No flight integration: still waiting for customer calls instead of dispatching proactively
Before committing, run a 2-week parallel trial during peak season - not during your quietest month. The software that handles your worst Thursday afternoon in July is the software worth paying for.
Terminal-aware assignment, flight data integration, customer ETAs, and exception handling - built for operators who run real fleets.