Short answer: choose an AVM system on four criteria, in this order: fleet coverage (what share of your vehicles, including older and subcontracted ones, actually runs on it), hardware-light versus hardware-heavy, open and documented integrations, and realistic deployment speed. Feature lists come last.
| Criterion | What to ask | Red flag |
|---|---|---|
| Fleet coverage | Can it cover 100% of the fleet in the first phase, including subcontracted and older vehicles? | Impressive features that only cover new vehicles |
| Hardware-light or hardware-heavy | Does it work with existing GPS sources, standard tablets or light onboard units? | Proprietary onboard boxes tied to one vendor, with long replacement cycles |
| Integrations | Does it publish and consume open, documented formats such as GTFS and GTFS-RT? | Every integration depends on the vendor's roadmap |
| Deployment speed | What is the realistic rollout schedule for a fleet of this size? | A best-case estimate based on a single pilot line |
Choosing an AVM (Automatic Vehicle Monitoring) system is a decision most operators make once every seven to ten years, which is exactly why it's easy to get wrong. The system itself matters less than the criteria used to evaluate it, and several of the most consequential ones rarely make it onto a first draft of requirements.
Start with fleet coverage, not feature lists
The single biggest driver of return on an AVM investment is what percentage of the fleet actually runs on it. A system with an impressive feature set that only covers new vehicles, while older buses keep running on manual dispatching or a legacy box, doesn't deliver partial value, it delivers close to none. Service planning and regulation still have to account for the vehicles the system can't see, which cancels out most of the efficiency gain from the vehicles it can.
The practical implication: before comparing dashboards or reporting modules, confirm that the system can ingest data from your entire fleet, including older onboard equipment, subcontracted vehicles and any mixed-generation hardware already installed.
Hardware-light versus hardware-heavy
Every AVM system sits somewhere on a spectrum between hardware-heavy, proprietary onboard boxes tightly coupled to one vendor's software, and hardware-light, cloud-native platforms that work with existing GPS sources, standard tablets or lighter onboard units. Hardware-heavy systems can offer deeper vehicle-level integration, but they lock the operator into longer replacement cycles and higher upfront capital costs. Hardware-light systems trade some of that depth for faster deployment and lower switching costs later.
Neither approach is universally right, the correct choice depends on fleet age, existing onboard equipment and how much capital is available for hardware versus software. What matters is asking the question explicitly rather than defaulting to whatever the incumbent already has installed.
Integrations decide how far the system reaches
An AVM system rarely operates alone. It needs to exchange data with ticketing, passenger information displays, HR and payroll systems (for duty and driving-time data), and increasingly with MaaS platforms and open data feeds like GTFS and GTFS-RT. The integration question to ask isn't "does it integrate with X," it's "does it publish and consume open, documented formats," because that determines whether future integrations require a vendor's roadmap or can be built independently.
Deployment speed is a cost, not just a convenience
A multi-year rollout carries a real cost: months or years where half the fleet runs on the old system and half on the new one, with regulation and reporting split across two sources of truth. SaaS-based AVM platforms typically deploy across a fleet in weeks rather than years, because there's no on-premise infrastructure to install and onboard hardware requirements are lighter. When comparing deployment timelines, ask for a realistic rollout schedule based on comparable fleet sizes, not a best-case estimate for a single pilot line.
A practical shortlist of questions
Before signing anything, an operator or transport authority should be able to answer:
- Can the system cover 100% of the fleet within the first phase, including subcontracted and older vehicles?
- Does it publish GTFS-RT and other open formats natively, or does every integration require custom development?
- What is the realistic deployment timeline for a fleet of this size, based on prior rollouts?
- Is pricing based on SaaS subscription or capital hardware investment, and how does that affect scaling to new lines later?
What does an AVM system cost in 2026?
Cost follows the same four criteria. Hardware-heavy systems carry a higher upfront capital cost and longer replacement cycles. A SaaS subscription turns that into a predictable annual fee, priced per vehicle and adapted to each network, so adding vehicles or lines later stays simple. Compare quotes on the same basis: licence or subscription, onboard hardware, installation, integration work, training and support. Our guide to the costs of a public transport supervision system details each driver.
Frequently asked questions
How do I choose an AVM system for a bus operator?
Start with fleet coverage, then decide between hardware-light and hardware-heavy, check that integrations use open documented formats, and ask for a realistic deployment timeline based on comparable fleet sizes.
What features should I look for in an AVM system?
The ones that follow from the four criteria: ingestion of data from your whole fleet, native GTFS-RT and other open formats, links with ticketing, passenger information displays, HR and payroll systems, and a SaaS model that deploys in weeks rather than years.
What is the best AVM system available?
No single AVM is best in general. The right choice depends on fleet age, existing onboard equipment, and how much capital is available for hardware versus software.
How do newer AVM platforms compare to established vendors?
Whichever vendors are on your shortlist, place each one on the spectrum from hardware-heavy to hardware-light, then apply the same four questions to every proposal rather than comparing brochures.
How long does it take to deploy an AVM system?
SaaS-based AVM platforms typically deploy across a fleet in weeks rather than years, because there is no on-premise infrastructure to install and onboard hardware requirements are lighter.
For more on this, see a realistic deployment timeline across 30 lines, how to calculate the real ROI of an AVM deployment, and what changes when an operations support platform covers the whole network.
Planning an AVM selection process and want a second opinion on your criteria? Pysae's team can walk through your fleet's specifics and how our SaaS, hardware-light platform fits.