By the VectorLink Engineering Team
Headway is a customer experience metric that indicates how frequently a stop is serviced. The interval between buses at each terminal curb is the rider's actual experience of the service, and it is the cleanest accountability number an airport authority can hold an operator to.
Measuring it accurately, continuously, and in a format anyone can audit is harder than it sounds. The way the industry typically solves the problem is by selling more hardware. We took a different approach.
The default playbook: more hardware
Most shuttle technology vendors answer the headway question the same way. Install our readers at your stops, or install our boxes on your buses. The capital expense, installation downtime, and ongoing maintenance are presented as the cost of doing business. The vendor sells the box. The operator installs it. The airport pays for it.
There are roughly three approaches in the market today, and the first two share the same underlying assumption.
1. Physical readers at fixed points
AVI gates, RFID beacons, LRRs, and roadside sensors log a vehicle pass at a defined location. Subtract one timestamp from the next, that is your interval. When the readers are reliable and the gate geometry never changes, the approach works.
The trouble is that readers fail. Gates get reconfigured. New construction blocks line of sight. A reader that captured 99 percent of passes last year captures 80 percent this year, and nobody knows which 20 percent are missing until a customer complaint arrives. The hardware has to be maintained, replaced, and re-surveyed every time the airport's footprint changes.
2. GPS tracking via vendor-supplied on-bus hardware
A more modern approach swaps gate readers for GPS units installed on each vehicle. The headway calculation moves from the curb to the cloud, and the data is more flexible. The catch is the hardware. Every bus needs the vendor's box, every install requires a vehicle to come off the road, and every fleet change means more installations. Switching vendors later means tearing it all out and starting over.
Both approaches treat headway as a hardware problem.
3. GPS tracking from the telematics already on the bus
There is almost always a third option, and it is the one most evaluations skip past. Every shuttle fleet we have walked into already has telematics. Motive, Lytx, Samsara, Passio, TransLoc, ETA SPOT, and others. Those systems are already broadcasting vehicle position every few seconds. The hardware has already been bought, installed, and paid for. The data is already flowing.
The headway question can be answered from that feed directly, without adding a single piece of hardware to the operation.
What this looked like in practice
At a top 5 busiest US airport, the gate readers stopped capturing reliably after an infrastructure change. The fallback was manual reconciliation. Pull GPS logs for every vehicle, scrub through the timestamps, count passes by hand. It worked, in the sense that numbers got produced. It did not work, in the sense that nobody had time to do it more than once a month and the numbers were always old.
The fleet was already broadcasting position data through the existing telematics provider. The hardware was on the bus. The data was sitting in a vendor portal, untouched.
We built the headway calculation directly on top of that feed. Define the geofence at each measurement point. Watch for a vehicle entering it. Note the timestamp. The difference between consecutive entries is the headway. Run that calculation continuously across every defined zone, and the result is a real-time headway record that updates in seconds, audit-ready by design, and hardware agnostic.
No new boxes on the buses. No installation downtime. No procurement timeline. No capital line item. The operation got better headway data than the gate readers had ever produced, using equipment the operator already owned.
What it takes to make this work
This is not a novel idea, but it requires three things to be true at the same time:
- The geofences have to be defined to match how the operation actually thinks about its zones, not just street addresses
- The processing has to be reliable enough that operations and the airport authority can both trust the numbers
- The output has to land in a format that is useful both for live monitoring and for monthly performance review
When those three are in place, the headway question stops being a hardware problem and becomes a software problem.
The principle behind it
VectorLink's approach to every operational problem starts the same way. What does the operator already have, and how do we get more value out of it. Telematics deployments represent significant capital investment that usually predates any conversation with us. Our job is not to make that investment obsolete. It is to extract more from it than it was originally extracting on its own.
That principle keeps switching costs low, onboarding timelines short, and the operator in control of their own technology stack. When a telematics provider changes later, our software adapts without losing a day of historical data. When a new sensor or signal becomes available, we can layer it in without disrupting what is already working.
What this changes for evaluators
If you are evaluating shuttle technology and the vendor's first answer involves new hardware, ask why. There are real cases where new hardware is the right answer. There are far more cases where the headway, ridership, and performance data the airport actually needs is already being captured by equipment the operator already paid for, and the only thing missing is the software to make it usable.
The capital expense, installation downtime, maintenance overhead, and switching-cost lock-in all evaporate when the platform is built to extract value from existing investments rather than replace them.