CMMS for Fleet and Vehicle Maintenance

Almost every organisation I have worked with that runs both buildings and vehicles arrived at the same place by accident. The CMMS was bought for the estate. The fleet was added later as an asset class, with a calendar PM and a text field for the plate number. In parallel, operations bought a fleet or telematics platform for fuel cards, driver compliance and tracking. Two years on there are two systems, each holding part of the truth about the same truck, and a monthly meeting whose main purpose is reconciling them. Nothing in that story is a software defect. It is a design decision nobody made deliberately, and that decision is what this guide is mostly about.

The message up front: fleet maintenance software is not a feature list, it is four design commitments. Meter readings arrive automatically and are validated before they trigger anything. The driver defect report is a first-class work-request channel, not an email. In-house workshop and third-party garage work post to the same unit on the same cost ledger. And exactly one system is the declared system of record for each data domain, written down, with the other syncing from it. Get the fourth one wrong and you will spend years arguing about which report is correct.

A note on scope. This is about the software and system design, not the maintenance content. Intervals, task lists, forklift and truck schedules and operator checklists are covered in the preventive maintenance for fleets and trucks guide. If you are earlier still, the CMMS buyer's introduction and core modules explained set the baseline.

1. What changes in the software when the asset moves

Each difference maps to a specific configuration requirement, not a vague sense that fleet is harder.

• The trigger source is external to the system. A building PM fires on a date the system already knows. A vehicle PM fires on an odometer or hour reading the system has to be told, by a person or a device. The trigger now depends on an inbound feed, and feeds fail quietly.
• The work-request channel is the operator. The highest-volume genuine defect source on a fleet is the driver doing a pre-use check: a structured, recurring, per-shift submission, which is a different intake pattern from a helpdesk ticket.
• Location is never stable, so you cannot route work by location hierarchy in the usual way. A vehicle's location is a telematics-supplied property that changes hourly.
• Execution may happen outside your organisation. Franchise dealers, tyre bays and independent garages do a large share of the work, and the system has to hold that as real history with cost, not as a note.
• Documents expire, cost is per distance or hour, and there is an operational substitute. Registration, insurance and inspection certificates are date-driven obligations on the asset. Cost per kilometre needs fuel, tyres and external invoices on the same asset as the labour. And because a spare unit absorbs another's downtime, availability is pooled.

2. The fleet-specific capability table

This is the list I work through when assessing whether a CMMS can genuinely carry a fleet. It is about capabilities rather than products, because the same product varies enormously with which modules were licensed and how it was configured. Take it into a demo and make the vendor show each row rather than confirm it.

On products: IBM Maximo, Infor EAM, Hexagon EAM and SAP PM generally cover the essential rows well, because meter-based maintenance, statutory inspection and cost rollup are core to the industries they were built for. Fiix, Limble, eMaint, MaintainX and UpKeep handle multiple meters, triggers and mobile inspection capture competently and stand up far faster, but tend to be thinner on finite bay scheduling, tyre position tracking and warranty claim workflow. Dedicated fleet platforms are stronger on fuel, driver compliance and tracking, weaker on maintenance planning and cost rollup. No product is best at everything, which is why the system-of-record question matters more than the shortlist.

3. Meter-based PM and the data-quality problem underneath it

Meter-based triggering is the right design for fleet and the biggest source of silent failure in fleet software. The logic is trivial; the data is not. For a 10,000 km service to fire correctly the reading must reach the system, attach to the right unit, be plausible and be recent. Each fails routinely.

• Readings arrive late. A monthly spreadsheet means a busy vehicle passes its trigger by thousands of kilometres before the system notices. The PM is on time against the reading and weeks late against reality.
• Readings are transcribed wrongly. A reading overstated tenfold fires every PM on the unit at once, then suppresses all of them for years because the system now believes the vehicle is far ahead of every interval.
• Readings go backwards. A replaced instrument cluster, a rollover, a trip meter read instead of the total. Without a rollover rule and a meter-replacement procedure the history becomes unusable.
• Readings attach to the wrong unit, which is common where the plate is the identifier and plates get transferred. The internal fleet number, never the plate, is the asset identifier.

Source hierarchy, best first: telematics feed, driver capture on the pre-use check, workshop capture at job open and close, manual collection. Run at least two, with telematics primary and the operator check as cross-check. Keep the operator check even after telematics goes in, because a box that stopped reporting three weeks ago looks exactly like a vehicle that has not moved, and only a human reading contradicts it.

4. Telematics integration and fault-code ingestion

Telematics is the feed that makes meter-based PM honest. The design decisions worth making explicitly:

• Direction and ownership. Telematics is the source, the CMMS the consumer. Decide who owns the integration: a vendor-supported connector, middleware, or your own code against an API. A supported connector for your exact pair of products is worth paying for, because otherwise a schema change on either side becomes your incident.
• Identity mapping. Telematics keys on a device id, the CMMS on fleet number. You need a mapping table, a named owner, and a process for devices moved between vehicles. An unmapped device must raise an exception, because a silently dropped feed is how a unit stops receiving PMs unnoticed.
• Frequency and granularity. A daily meter snapshot per unit plus fault codes as they occur is enough. Streaming position pings into a maintenance system bloats it and buys nothing.

Fault-code ingestion deserves most of the design effort, because unfiltered codes are worse than none. Maintain a catalogue mapping each code you care about to one of three actions: stop now, return at end of shift, or log and review at next service. Uncatalogued codes default to log-and-review, and the catalogue grows as you learn. De-duplicate so one active code produces one open item with a recurrence count, not fifty identical requests. Switch off known-noisy codes as a documented decision with a named owner, rather than letting everyone learn to ignore the list. And only stop-now codes should page a human, because alert volume is the mechanism by which telematics programmes die. For the integration architecture itself, see the IoT fleet management integration guide.

5. The daily inspection and driver defect report as a work-request channel

The inspection as a maintenance practice is covered in the fleet PM guide. What matters here is how it sits in the system, because this is the intake channel most implementations handle worst. Design it as a recurring inspection record rather than a work order: one submission per unit per shift, carrying unit, person, timestamp, meter reading, pass or fail per item, observations and photographs. That record has two outputs, the meter reading and any failed items, which become defect work requests.

• Offline-first mobile capture. Drivers start in basements, yards and depots. If the form needs connectivity, the paper clipboard comes back. Queued submissions must survive an app restart and sync without the user thinking about it. Test this on real devices, and see the mobile CMMS guide for how to evaluate it properly.
• A distinct work order type for operator-reported defects, with its own triage target, queue and reporting, so defects are visible as a stream instead of disappearing among planned work. The work order types guide covers the structure.
• Severity captured at source, triaged by a human. Let the driver mark a defect safety-critical and route those immediately, but do not let a checkbox decide roadworthiness, and do not make the driver the final authority either.
• A nil-defect submission is still a submission. Without the clean records you cannot tell a compliant driver from one who skipped the check, and completion rate per unit is a real control.
• Open safety-critical defects should block allocation, and rectification should link back so the reporter sees it was actioned. This is the one place I would accept a hard system block, because the alternative is a judgement call under operational pressure.

The reporting value is underrated. A year of structured records tells you which units generate most defects, which check items fail most, which depots have suspiciously perfect compliance, and whether defect volume rises before a failure. Free text gives you none of that.

6. Workshop scheduling: bays, capacity and technician skills

Building maintenance schedules people. Fleet maintenance schedules people and places, because a vehicle job needs a bay, ramp, pit or tyre machine, and those are finite. A CMMS that models only labour will cheerfully schedule six jobs into a four-bay workshop and produce a plan that cannot be executed.

• Bays as a schedulable resource with attributes. Heavy-vehicle ramp, pit, hoist of a given capacity, tyre bay, wash bay. A job requires a bay type and the schedule respects it.
• Realistic durations. Labour hours are not elapsed bay time. A service with a parts wait occupies the bay far longer than its labour content, so schedule on occupancy.
• Skills and certifications as constraints. Air brake work, tachograph calibration, refrigerant handling, high-voltage work on electric and hybrid units, statutory inspection competence. Hold these as qualifications with expiry dates on the person record and let the scheduler refuse an unqualified assignment. A lapsed certification is a compliance exposure, not a scheduling inconvenience.
• Parts gating the schedule. No job enters a bay until its parts are reserved or kitted. This one change removes a large share of workshop idle time in the fleets I have reviewed.
• A visible schedule board, and batching by location. Bays down one axis, time across the other. If the foreman keeps a whiteboard alongside the system, the system's view is inadequate. On dispersed fleets, group planned work by depot and by the release window operations has agreed.

One pattern worth adopting: reserve a fixed share of bay capacity for unplanned work rather than filling the schedule with PMs. Fleets generate breakdowns continuously, and a fully committed workshop absorbs them by displacing planned work, which is how compliance erodes.

7. Parts and inventory for vehicles

The general model is in the spare parts and MRO inventory guide. The fleet-specific adjustments:

• Fast movers dominate. Filters, blades, bulbs, belts, pads and shoes, hoses, clamps. High turnover, low value, and the usual failure is a stockout idling a bay over a part worth very little. Generous min-max levels, and pre-kitting per service type per unit class is one of the highest-return changes available in a fleet workshop.
• Fluids are issued by volume. Oils, coolant, brake fluid, DEF, grease: bulk stock consumed in fractions, needing partial-issue units of measure and a reconciliation process, because fluid variance is where inventory accuracy quietly degrades.
• Tyres need their own model. Not a consumable but a tracked item with a life: received, fitted to a wheel position, rotated, retreaded, scrapped. Position tracking makes alignment and suspension problems visible in wear patterns, and tyres are typically the largest consumable spend after fuel.
• Serialised, warranty-bearing components. Engines, transmissions, axles, turbochargers, injectors, aftertreatment units, traction batteries. These carry warranty independent of the vehicle and move between units as exchange items, so they need serial tracking or you lose recoveries. Rotables also need core-liability tracking, or someone pays a core charge because a removed unit was scrapped instead of returned.
• Mixed-make fleets multiply part numbers. Five makes across three model years means several times the part numbers for the same coverage, with more stock, more obsolescence and more supplier accounts: a genuine and usually unstated cost of buying on lowest tender each cycle.

One catalogue discipline pays for itself: hold both the manufacturer and internal part number, and record supersessions. Vehicle part numbers are superseded constantly, and a catalogue that ignores that fills with orphaned items nobody will order against.

8. In-house workshop versus third-party garage

Almost every fleet uses both: routine servicing in-house, warranty and specialist work at the dealer, tyres at a tyre bay, statutory inspection at an approved body. Many fleets are mostly outsourced, and a system that models only internal labour cannot hold the truth about such a fleet. The requirement is that both paths produce the same asset history: one timeline per unit, with cost.

• A work order, not just a purchase order. The job exists on the unit with a type marking it externally executed, linked to a purchase or service order for the commercial side. Treating external work as procurement only is how service history develops holes.
• Supplier and authorisation control. Approved supplier list, authorisation limits, quote approval above a threshold. Uncontrolled garage spend is one of the most common leakages in outsourced fleet maintenance.
• Invoice reconciliation against the job, so you can see what was charged for what and catch duplicated lines or work the unit did not need. Where finance owns procurement this is an integration; the pattern is in the CMMS and ERP integration guide.
• Supplier performance measured, and meter capture mandatory at every visit. Turnaround, first-time-fix, rework, invoice accuracy, price variance against agreed rates: if you outsource maintenance, supplier performance is your maintenance performance. And a vehicle serviced only by a dealer otherwise contributes no meter data at all.

9. Downtime, availability and spare-vehicle management

On a fleet, downtime is pooled rather than per-asset, and the system has to support that.

• Out-of-service status with a reason code, not merely an open work order. A distinct availability state with start, end and reason: planned PM, awaiting parts, awaiting external workshop, awaiting authorisation, accident damage, statutory expiry, operational. Without reason codes you know your availability figure and nothing about improving it.
• Awaiting-parts and awaiting-authorisation as first-class states. In most fleets these dominate downtime, not wrench time, and making them visible usually reveals the constraint is procurement or approval rather than workshop capacity.
• Spare and pool units tracked as such. A fleet with no float cannot be maintained preventively, and the system should make float size visible so it can be argued about with evidence.
• Availability by unit class, not fleet-wide. Ninety percent availability is meaningless if the two specialist units that matter are both down. Group by class and criticality using the asset criticality classification ranking.
• Hire cost captured against the downtime event. It is the most persuasive number available when arguing for a larger float or faster parts supply.

10. Fuel, cost per kilometre and the reporting that drives decisions

Cost per kilometre and cost per operating hour make fleet decisions defensible, and most fleets cannot produce them credibly. The reason is almost never the reporting tool; it is that the cost components live in different systems and never meet on the same asset record. You need internal labour at a loaded rate, parts at cost, external invoices, tyres, fuel, lubricants, statutory fees, allocated insurance, and the meter movement for the period, all on the same unit. Depreciation or lease cost I would report alongside rather than inside the maintenance figure, because mixing capital and operating cost tends to end the conversation rather than inform it.

Fuel is both the largest cost and the best diagnostic. Transactions matched to the unit give consumption per kilometre or per hour, and variance in that figure is genuinely diagnostic: a unit drifting up ten percent is telling you something mechanical, something about how it is driven, or something about fuel going somewhere other than the tank. Matching each transaction to a meter reading at the fill is what makes consumption calculable at all, which is why the odometer prompt at the pump matters more than it looks.

For selecting and framing these without ending up with a forty-metric dashboard nobody reads, the KPI framework guide covers the discipline.

11. Statutory records, licensing expiry and warranty claims

These belong together because both are date-driven obligations a maintenance system is well placed to hold and frequently is not configured to.

Statutory and licensing records should be document records on the asset carrying an expiry date, issuing body, certificate reference and the attached document, driving escalating reminders rather than one notification. Give the escalation teeth: ninety days to the planner, thirty to the fleet manager, seven to whoever can authorise taking the unit off the road. Statutory work must also be a distinct, non-deferrable class driven off certificate expiry rather than a meter, because the regulator cares about the date on the certificate and nothing else. It must never share a compliance bucket with discretionary PM, because a planner under pressure will always defer the wrong thing when the two look identical on screen.

Warranty claims. Fleet warranty is more recoverable than building-asset warranty and more often lost, because the claim window is short and the failure is found by a driver rather than a planner. The mechanics are in the warranty management guide. The fleet specifics: cover is multi-layered on one unit, with vehicle warranty by time or distance whichever expires first, a longer powertrain warranty, component warranties running from their own fitment date, anti-corrosion cover, and bodybuilder warranty on a fitted crane, tail lift or tipper body, all on different expiry bases. The system must flag warranty at work-order creation, not at invoice review, because a technician who repairs a covered failure without raising a claim has usually voided it. OEM terms also carry obligations you can breach: service at the specified interval, with approved fluids and parts, documented. A fleet extending oil-drain intervals on oil analysis, usually the right engineering decision, may be weakening a warranty position on a unit still in cover, so make that trade-off knowingly per unit class. Then report value claimed, recovered, and work done on in-warranty units where no claim was raised. That last figure justifies the tracking effort to finance, and it is usually larger than anyone expects.

12. Fleet system or CMMS: deciding the system of record

Here is the honest section. Fleet software and CMMS overlap heavily, each does part of the job better, and the common outcome is two systems that disagree about the same vehicle: a CMMS saying a truck's odometer is 148,000 km and a fleet platform saying 151,300, two service histories, two compliance figures, and a monthly reconciliation meeting that produces no decisions.

That is not a bug and is rarely solved by picking the better product. It is the absence of a declared system of record per data domain. Both systems were allowed to be authoritative about the same things, so both drifted, and neither can now be trusted without checking the other. The resolution is a written allocation, domain by domain, not a winner-takes-all choice, because the strengths genuinely differ.

Three tests for whatever allocation you land on. Every domain has exactly one owner, with the non-owners read-only, enforced by configuration rather than policy. Flow direction is stated per domain, and two-way sync avoided unless unavoidable, because a domain with two writers gives you two truths and an audit trail explaining neither. And somebody is accountable for the interface, including failure: a feed that stops for a week should raise an exception, not silently stop generating PMs.

On the single-system question, since it always comes up: one system covering everything is simpler and worth pursuing where it fits. It fits when the fleet is small relative to a larger estate already in a capable EAM, or when the fleet is the whole business and a fleet platform with real maintenance depth can carry it. It does not fit when you need both deep maintenance planning across a mixed estate and native fuel, driver-compliance and tracking, because no product I have worked with is strong at both. Then two systems with a clean domain split is the honest answer, and it works perfectly well. Two systems with no domain split does not.

The idea to walk away with

Fleet maintenance software is a data-flow problem wearing a feature-list costume. The features that matter, multiple meters, meter-or-calendar triggers, mobile inspection capture, external work orders, tyre and warranty tracking, certificate alerting, are widely available and not hard to configure. What separates fleets that run well from fleets that argue about reports sits upstream of all of it: whether meter readings arrive automatically and validated, whether the driver defect report lands as structured data, whether internal and external work post to the same ledger, and whether one system owns each data domain.

If you are configuring a CMMS for a fleet tomorrow, insist on two things first: the meter data object with validation rules and a staleness report, and the one-page system-of-record agreement. Neither is a feature you buy, and both determine whether the features you did buy produce numbers anyone can trust.

Final thoughts

The most common fleet software situation I encounter is not a poorly chosen product. It is a reasonable product asked to do a job nobody specified, alongside a second reasonable product doing an overlapping job nobody specified either, with the gap filled by a spreadsheet and somebody's memory. The fix starts with writing down who owns what, and it is free.

After that, work upstream to downstream. Get the register accurate with a permanent internal identifier. Get meter readings flowing automatically and validated, with the operator check as cross-check. Get the defect report in as structured data with a route to a work order. Then the schedules from the fleet PM guide will fire when they should, cost per kilometre will be defensible, and the compliance report will mean something. And confirm your own jurisdiction's statutory inspection and licensing requirements locally before configuring a single interval or expiry rule.

Related reading: Preventive maintenance for fleets and trucks, IoT fleet management integration, Maintenance management systems: core modules, Spare parts and MRO inventory in a CMMS, Warranty management in asset systems, CMMS integration with ERP, Mobile CMMS: field-ready apps.