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 vehicle 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 AOM 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?
For more on this, see a realistic deployment timeline across 30 lines, how to calculate the real ROI of an AVM/SAEIV 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.