Fleet Maintenance Software and Systems

Fleet maintenance is a different shape of problem from building or plant maintenance, and the difference is not cosmetic. A chiller sits still and ages on the calendar. A truck ages on the odometer, and it does so at a rate you do not control, because the rate is set by dispatch, by route, by load and by whoever happens to be driving it this week. That single fact, that the clock on a vehicle is a meter rather than a date, reshapes almost everything: how you build service schedules, what data you depend on, where the schedule silently drifts away from reality, and which system you should be running the whole thing in. This guide works through the maintenance half of fleet management the way I would work through it on an advisory engagement.

The message up front: vehicle maintenance is a meter-driven discipline resting on two fragile inputs, the odometer or hour feed and the driver defect report. Get those two right and a fairly ordinary system will run a good fleet programme. Get them wrong and no amount of software will save you, because every mileage-based schedule quietly stops firing and nobody notices for months. Choose the tool after you have decided how those two inputs will be captured and checked, not before.

1. Why vehicle maintenance is a meter problem, not a calendar problem

In a building portfolio, a preventive maintenance programme is essentially a calendar. The AHU filter change is monthly, the fire pump test is weekly, the statutory inspection is annual. Work is generated by dates, and dates are perfectly reliable data because they arrive whether or not anyone tells the system anything.

Vehicles do not work that way. A light van doing airport shuttle runs may cover in three months what a site pickup covers in two years. Servicing both on a calendar means one is serviced far too late and the other far too often. The manufacturer does not express intervals in months as the primary trigger either; the interval is stated in kilometres or engine hours, with a calendar limit as a backstop for vehicles that are barely used. So the primary trigger for vehicle work is a meter reading, and the calendar becomes the secondary, whichever-comes-first condition.

Three consequences follow, and they are the source of most of the practical difficulty in fleet maintenance.

• The schedule depends on a data feed you do not own. A date arrives by itself. An odometer reading has to be collected, from telematics, from a fuel transaction, from a driver, or from a technician at the workshop gate. If that collection breaks, the schedule does not throw an error. It simply stops advancing, which looks exactly like a vehicle that is not being driven.
• Due dates move. A building PM due on the 14th is due on the 14th. A vehicle service due at 60,000 km may be due in three weeks or in three days depending on how hard the vehicle is worked, and the answer changes daily. Your planning horizon is therefore a forecast, not a fact, and the system has to project a due date from recent consumption rate rather than state one.
• Drift is the normal state, not the exception. Vehicles get serviced late because they were on a job, or early because they happened to be at the workshop for something else. Either way the next interval has to be recalculated from what actually happened, not from the original plan. Systems that schedule from the plan rather than from the last completed service accumulate error until the whole programme is fiction.

The mechanics of meter-triggered work, floating versus fixed intervals, consumption-rate forecasting and whichever-comes-first logic, are the same in a fleet tool as in a maintenance system, and I have covered them in detail in the meter-based and usage-based PM guide. Read that alongside this one; this article assumes it rather than repeats it.

2. The service schedule model: OEM intervals, operating conditions and service tiers

A workable fleet service schedule is built in layers, and the common mistake is to stop after the first one.

Layer one is the manufacturer schedule. The OEM handbook gives intervals by distance or hours, usually with a normal-duty and a severe-duty column. This is the baseline, it is what warranty is judged against, and it is the thing you must be able to evidence you followed. Take it from the handbook for the specific variant and engine, not from a generic figure someone remembers, because intervals differ between model years and between engine options on the same badge.

Layer two is the operating-condition adjustment. The OEM normal-duty interval assumes something close to average use. A vehicle that idles for hours in heat, runs short trips that never bring the engine to temperature, operates on dust or unsealed roads, tows near maximum rating, or carries a permanently mounted body and equipment, is on severe duty whether or not anyone has said so. Severe duty usually means shorter oil and filter intervals and more frequent attention to air intake, cooling and brakes. In a Gulf fleet this is not a niche case; heat, dust and idling put a large share of vehicles on the severe column, and the common fault I see is that the fleet is scheduled on the normal column because that is what was entered on day one.

Layer three is the service tier structure. Rather than a long flat list of tasks at every visit, most mature fleets group work into A, B and C service levels, so that heavier work nests inside lighter work at defined multiples. The naming varies, and some operators use different letters or a numbered scheme, but the logic is consistent.

• A service: the frequent, light visit. Oil and filter, fluid levels, lamps, tyres and pressures, visual underbody and brake check, wiper and washer, any quick-win defect items. Fast, cheap, keeps a pair of trained eyes on the vehicle regularly.
• B service: everything in A, plus air and fuel filters, brake measurement rather than a glance, suspension and steering inspection, drive belt, battery test, more thorough electrical and body checks.
• C service: everything in B, plus the long-interval items. Transmission and differential fluids, coolant, spark plugs or injector attention, timing components where due, and a genuinely detailed inspection. This is where a vehicle either earns another year or starts telling you it is time to think about replacement.

Layer four is statutory and regulatory work, which sits outside the OEM schedule entirely and is non-negotiable: periodic roadworthiness testing and registration renewal, tachograph or recorder checks where applicable, lifting-equipment and crane inspections on mounted plant, tail-lift and tank certifications, fire extinguisher and first-aid checks on passenger-carrying vehicles, and any operator-licence obligations. The important design point is that statutory work is date-driven even in a meter-driven fleet, and it must never be allowed to be missed because a mileage service was deferred. Keep statutory items on their own schedule with their own escalation, not bundled inside a service tier that might slip.

For the practical task content of vehicle and truck PM routines, the companion piece on preventive maintenance for fleets and trucks goes into the checklists themselves. What matters here is that your software can express all four layers at once, with whichever-comes-first logic between meter and date, and with nesting so that a C service closes out the A and B items rather than generating three overlapping work orders on the same day.

3. A service-schedule trigger table

This is the kind of trigger map I would expect to see documented and loaded into whichever system runs the fleet. The numbers are illustrative placeholders; take the actual intervals from your OEM handbooks and your regulator. What matters is the trigger type and the whichever-comes-first pairing.

Reading down the last column is instructive. The date-driven and event-driven rows survive a broken odometer feed. Every distance-driven row degrades, and the hour-meter row on plant fails outright because there is usually no sensible calendar backstop for a generator that may run 20 hours a month or 500. That asymmetry is why the next section matters as much as it does.

4. The odometer feed: the single point of failure nobody monitors

If I could change one thing about how fleet maintenance systems are set up, it would be this. The odometer feed is a production dependency of the same class as a payroll interface, and it is almost never treated as one.

The feed breaks in mundane ways. A telematics unit is unplugged during a workshop visit and not refitted. A device fails, or its SIM stops, or the vehicle sits in a basement with no signal for a month. The integration between the telematics platform and the maintenance system hits an authentication expiry and nobody is watching the error log. A vehicle is re-registered and the new record does not carry the device mapping, so readings land against a ghost asset. A replacement instrument cluster resets the displayed odometer and the feed now reports a number lower than the last recorded reading, which most systems either reject or, worse, accept.

What makes this dangerous is not the breakage, it is the silence. There is no alarm state for "no readings received", because no readings is indistinguishable from a parked vehicle. The schedule simply never becomes due. A vehicle can run 30,000 km past an oil service while the system shows it comfortably in date, and the first sign of trouble is an engine problem or a warranty claim that gets refused for want of service evidence.

The detection controls I would insist on, in order of value:

• A stale-meter report, run weekly, owned by a named person. Any active vehicle with no odometer or hour reading in the last seven days appears on it. Not a dashboard tile that someone might look at, a report that lands in an inbox and has to be cleared. This one control catches most of the failure modes above.
• Implausible-reading validation. Reject or quarantine readings that go backwards, that jump more than a plausible daily maximum for the vehicle class, or that arrive with a null value. Then review the quarantine, because a legitimate cluster replacement needs a deliberate meter-reset entry with an audit note, not a silent overwrite.
• A second, independent reading source. Fuel card transactions, toll records and the reading a technician takes at every workshop visit are all free cross-checks. Comparing the telematics odometer against the last workshop-captured reading catches device and mapping failures that a single source cannot reveal.
• Forced capture at every touchpoint. Make the odometer a mandatory field on work order closure, on fuel entry where you control it, and on any driver check-in. A fleet with strong manual capture survives a telematics outage; a fleet that depends solely on the integration does not.
• A reconciliation of active vehicles to reporting devices. Count the vehicles flagged active in the maintenance system, count the devices reporting into the telematics platform, and explain the difference. The gap is where your unscheduled vehicles are hiding.

The telematics hardware and data side of this, device types, what the CAN bus actually exposes, platform selection, belongs in its own discussion and I have kept it there: see GPS fleet tracking and telematics for that layer. The point for maintenance purposes is narrower. You need one trustworthy number per vehicle per day, you need to know when it stops arriving, and you need a manual fallback that works.

5. Driver defect reporting and walkaround checks

Fleets spend heavily on sensors and then underuse the best condition-monitoring instrument they own, which is the person who drives the vehicle every day. A driver notices a pull to one side, a new noise on braking, a warning lamp, a soft pedal, a cracked lens, a slow tyre, long before any threshold-based analytic does. The daily walkaround check and the defect report are the primary condition input in a fleet, and in many operations they are also a legal obligation rather than good practice.

The system design part is straightforward. Move the check off paper into a mobile form. Structure it by area so it cannot be skimmed in ten seconds. Require a photograph for any defect raised. Let a defect create a work order directly against the vehicle, with a severity that distinguishes "roadworthy, fix at next service" from "do not move this vehicle". Record the nil-defect declaration too, because an absent record is not evidence of a check.

The hard part is not the form, it is the reporting culture, and this is where most implementations quietly fail. Drivers learn very quickly whether reporting a defect helps them or costs them. If a reported defect means the vehicle is taken off them, their run is disrupted, and they get questioned about whether they caused it, they will stop reporting. The checks keep getting submitted, all nil defect, beautifully compliant, and completely worthless. I have seen fleets with a 99 percent check completion rate and a defect-raise rate so low it was arithmetically impossible to be true.

What changes the culture, in my experience, is visible closure and the absence of blame. Tell the driver what happened to the defect they raised. Fix the small things fast, because a wiper blade replaced within a day teaches more about the system than any briefing. Separate defect reporting entirely from damage and accident attribution, so reporting a fault is never the first step in a disciplinary conversation. And watch the raise rate as a health metric in the other direction from the obvious one: a low defect rate on an ageing fleet is a warning sign, not an achievement. If your oldest vehicles raise the fewest defects, the reporting has broken, not the fleet improved.

6. Work orders, repair history and vehicle identity

Everything else in this article ends up as a work order against a vehicle, and the value of the whole system comes from the repair history that accumulates there. Cost per kilometre, replacement timing, warranty recovery, recurring-fault detection and supplier performance all read from that history. Which makes the integrity of vehicle identity the quiet foundation of the entire programme, and it is muddled more often than not.

A vehicle carries several identifiers and they change at different rates. The VIN or chassis number is permanent and unique and nobody uses it in conversation. The registration or plate number is what everyone actually uses, and it changes, on transfer between emirates or states, on re-registration, on plate reassignment. The internal fleet number is what the operations team says on the radio, and it gets reused when a vehicle is disposed of and a new one takes its slot. The asset or equipment number is what finance depreciates.

The failure pattern is predictable. History is keyed on registration, the vehicle is re-registered, and the record splits into two partial histories. Or the fleet number is recycled, and a new van inherits five years of an old van's repairs, which makes its cost per kilometre look catastrophic and its warranty position incoherent. Either way the analysis you built the system for is now wrong, and nobody trusts the numbers.

The rule I would apply without exception: the permanent unique key is the VIN or chassis number, and every other identifier is an attribute of that record with a validity period. Registration changes are recorded as a change of attribute on the same asset, never as a new asset. Fleet numbers are never reused within the retention period of the history, and if operational practice insists on reusing them, they must be treated as a label with dates rather than a key. Get this settled during data preparation, because retrofitting identity onto three years of split history is slow, manual and rarely done properly.

On work order structure itself, fleet work splits cleanly into scheduled service, defect rectification, accident and damage repair, tyre work, statutory inspection and modification or fit-out. Those categories should be distinguishable in reporting from the first day, because the mix tells you what kind of fleet you are running. A fleet where damage repair dominates has a driving problem, not a maintenance problem, and no service schedule will fix it. The general structure of work order types applies here in the same way it does in any maintenance system, and the guide to running fleet and vehicle maintenance in a CMMS covers how that maps onto a maintenance platform rather than a fleet-specific one.

7. In-house workshop, outsourced garage or dealer

Where the work is physically done shapes what the software has to do, and most fleets of any size use all three routes at once rather than choosing one.

The in-house workshop is the most demanding on the system. You need labour booking against jobs, technician time and productivity, bay or ramp scheduling, parts issue from your own store, work order costing that separates labour from parts, and a job card the technician can actually complete on a tablet with oily hands. This is where weak fleet tools show their limits fastest, because running a workshop is closer to running a maintenance department than to running a tracking platform.

The outsourced garage inverts the problem. You are not managing labour, you are managing authorisation and invoices. The system needs to raise a job to a supplier, hold an estimate, apply an approval limit so that a job above a threshold needs a sign-off before work starts, receive the completed work with a third-party invoice attached, and let someone reconcile invoice against estimate against what was authorised. Without that chain, the fleet pays for whatever the garage says it did, and the repair history is whatever the invoice narrative happened to mention.

The dealer matters for vehicles in warranty and for work requiring proprietary diagnostics. The requirement here is documentary. You need the dealer service record, with the odometer reading and the date, captured against the vehicle in your system, because that is the evidence chain a warranty claim will be judged on. A dealer invoice sitting in a finance folder is not maintenance history.

Third-party invoice capture deserves a specific mention because it is the weakest link in most fleet implementations. External work arrives as a PDF or a paper invoice with a free-text description, and unless someone codes it to the right vehicle, the right work category and the right cost element, the cost data is polluted and the repair history has a hole in it. The pattern that works is to require a system-generated job reference on every external job before the supplier starts, so the invoice arrives with a reference that matches an authorised job. Chasing the coding afterwards never keeps up.

8. Parts, tyres and consumables

Fleet parts have a different profile from plant spares. Volumes are higher, unit values are lower, the catalogue is dominated by consumables and service kits, and much of it is vehicle-model-specific, which means a mixed fleet carries a much wider range than a standardised one. The practical consequences: model standardisation is a maintenance decision as much as a procurement one, service kits should be defined per model and issued as a kit rather than as fifteen lines, and a small van stock for mobile technicians needs to be tracked as a location rather than written off on issue.

None of the underlying inventory discipline is fleet-specific. Minimum and maximum levels, reorder points, cycle counting, issue against work order, and the difference between a stocked item and a direct-purchase item all behave as they do anywhere else, and the spare parts and MRO inventory guide covers that ground. What I would add for fleets is that the parts module is the most common reason a fleet outgrows its fleet tool, so if you hold real stock, evaluate it as a stores system and not as a parts list.

Tyres are their own discipline, and in a truck or bus fleet they are a large enough cost line to deserve dedicated management rather than a consumable code. A tyre is not a part issued and forgotten; it is an asset with a position, a life and a history of its own.

• Position-level records. Tyres are managed by axle and wheel position, not by vehicle. A tyre moves between positions on rotation, moves between vehicles, and comes off for retreading and back on again. Without position-level tracking you cannot investigate why the front left on a particular route wears twice as fast as its pair.
• Tread depth as a meter. Recording depth at each check turns tyres into a condition-monitored item with a forecastable replacement point, which is what lets you plan tyre spend rather than react to it.
• Cost per kilometre per tyre, and by brand. This is the number that settles purchasing arguments. A cheaper casing that lasts two thirds as long and cannot be retreaded is not cheaper. You can only demonstrate that with position-level life data.
• Retread and casing management where you run it, including casing count, retread cycles used and scrap reasons.
• Pressure discipline, because under-inflation is the dominant cause of premature wear and of failures at speed, and it is the cheapest thing on this list to get right.

Most general-purpose fleet tools handle tyres as a basic consumable with an optional position field. Dedicated tyre management is usually either a specialist module, a separate system provided by the tyre supplier, or a spreadsheet. Decide deliberately which of those you are choosing, because defaulting into the spreadsheet is what usually happens.

9. Warranty and recall tracking

Warranty is the most reliably under-recovered money in fleet maintenance, and the reason is almost always evidence rather than entitlement. A claim needs the vehicle in its warranty window on distance and date, a documented service history showing the OEM schedule was followed at the right intervals with approved parts and fluids, and a repair record that links the failure to a covered component. Fleets lose claims because the service was done a few thousand kilometres late, or because the record of it sits with a garage rather than in the system, or because nobody knew the component was still covered.

What the system needs to do is modest and specific. Hold the warranty start date and the distance and time limits per vehicle, and separately for major components and for any extended or supplier warranty that runs on a different clock. Flag at work order creation that this vehicle or component is potentially in warranty, before the repair is authorised, because a warranty check after the invoice is paid is an argument rather than a claim. Track raised claims through to recovery, so unpaid claims are visible rather than forgotten. And keep the full service evidence chain against the vehicle, including dealer and garage records, because that is the part fleets consistently fail to produce. The general mechanics of warranty registration, claim workflow and recovery tracking are in the warranty management in asset systems guide.

Recalls are a related but distinct obligation. A safety recall applies to VIN ranges, arrives from the manufacturer or a regulator rather than from your own schedule, and has a compliance dimension that goes beyond cost. Manufacturers and safety regulators publish recall information, and in the United States the NHTSA maintains VIN-level recall lookup, with equivalent authorities elsewhere; commercial operators should also check what their national road transport authority requires. Practically, you want a periodic check of your VIN list against open recalls, a way to record which vehicles are affected and which have been rectified, and an ability to show that quickly if an incident ever puts the question to you. This is the sort of task that gets done diligently for six months and then stops, so assign it to a role and put it on a schedule rather than relying on someone remembering.

10. Cost per kilometre, downtime and replacement decisions

The output that justifies the whole system to a finance director is cost per kilometre, or cost per hour for plant. It is a simple ratio and it is almost always calculated badly, because the numerator is incomplete.

A defensible maintenance cost per kilometre includes in-house labour at a loaded rate rather than nothing, parts at actual issue cost, external invoices coded to the vehicle, tyres, and consumables. Fuel is usually reported alongside rather than inside it, because fuel is driven by driving behaviour and route as much as by vehicle condition. Depreciation, finance, insurance and licensing belong in total cost of ownership rather than in maintenance cost per kilometre, and mixing them makes the maintenance trend unreadable. Whichever definition you adopt, write it down and keep it stable, because a cost per kilometre that changes definition between years tells you nothing.

Downtime and vehicle-off-road tracking is the other half of the picture and it is more often missing than present. A vehicle off road is a vehicle not earning, and on a tight fleet it means a hired replacement or a missed run. What you want recorded is the time the vehicle became unavailable, the time it returned to service, and the reason, split at minimum into scheduled service, defect and breakdown, accident and damage, awaiting parts, and awaiting authorisation. The reason split is the useful part. A fleet with substantial VOR hours in awaiting-parts has a stores problem. A fleet with substantial hours in awaiting-authorisation has a process problem, and that one is free to fix. The mechanics of backlog and downtime measurement are covered in the meter-based PM guide only in passing; the discipline itself is the same as in any maintenance operation.

Together, cost per kilometre and downtime drive the replacement decision. The honest version of that decision looks at the trend rather than a threshold: maintenance cost per kilometre rising year on year, unscheduled events increasing in frequency, downtime hours climbing, residual value falling faster than the maintenance saving from keeping the vehicle. The economic replacement point is where the rising cost of ownership crosses the cost of the replacement vehicle amortised over its expected life. Most fleets I have looked at do not have the data to place that crossing point with any confidence, which is not a modelling failure but a history-quality failure. Three years of clean, correctly attributed repair history against a stable vehicle identity is worth more here than any optimisation tool.

11. Mixed fleets: plant, generators, trailers and when a CMMS is the answer

Very few fleets are only vehicles. Alongside the cars, vans and trucks sit trailers, tippers and tankers, mounted cranes and tail lifts, generators, compressors, welders, pumps, forklifts and other yard plant, and sometimes fixed workshop equipment as well. These behave differently in ways that matter for system selection.

• Trailers have no odometer and no engine. They accumulate wear through use and time, they are inspected rather than serviced on a distance schedule, and they are coupled to different tractors, which means usage is attributed to the wrong unit unless you track coupling. Many fleet tools handle trailers as second-class records.
• Generators and compressors run on hours, not distance, and the hour meter is often read manually. A fleet tool built around odometers handles this awkwardly; a maintenance system built around meters handles it natively.
• Mounted equipment has its own regulatory regime. A crane on a truck is a lifting appliance with inspection and certification obligations independent of the vehicle, and it may have a different owner, a different inspector and a different renewal cycle.
• Yard and workshop plant is plant. It has a location, a hierarchy position, spares, and no registration number at all.

This is where the choice of platform stops being a preference. If your asset base is overwhelmingly road vehicles with a handful of trailers, a fleet tool is the natural fit and the vehicle-specific features earn their place. If vehicles are one asset class among several, sitting beside plant, generators and fixed equipment in a single maintenance operation with one workshop and one parts store, then a CMMS with proper meter-based PM is usually the better answer, because it gives you one asset register, one work order process, one stores system and one set of numbers, instead of a fleet tool and a maintenance system that have to be reconciled. If you are early in that decision, the introduction to what a CMMS is and the CMMS versus EAM comparison set out where each tier stops. The broader question of which category of fleet platform to buy, and how to run the selection, is the subject of the fleet management software buyer's guide, and I will not duplicate it here.

12. Build, fleet tool or CMMS: a decision table

The three routes are a spreadsheet or in-house build, a fleet-specific platform, and a CMMS or EAM with meter-based PM configured for vehicles. This is how I would frame the comparison for a maintenance manager.

Two observations from applying this in practice. First, the spreadsheet route is not automatically wrong at small scale, but it fails specifically on meter-based scheduling and on history, which are the two things this article says matter most, so its ceiling is lower than it looks. Second, the choice between a fleet tool and a CMMS is decided less by the vehicles than by the workshop. No in-house workshop and no parts store, the fleet tool usually wins. A real workshop with technicians, bays and stock, and the maintenance platform usually wins, with vehicle-specific gaps filled by configuration or by a telematics integration.

13. Integration: telematics in, cost out

A fleet maintenance system has two integrations that genuinely matter and a long tail that usually does not.

Inbound from telematics, for the meter feed. What you actually need is small: vehicle identifier, odometer or engine hours, reading timestamp. Fault codes and idling data are useful additions but they are not the dependency. Design this as a daily scheduled pull or push with an error log somebody reads, idempotent so a replay does not create duplicate readings, with validation on the reading before it is accepted, and with an explicit monitoring signal for absence of data rather than only for errors. A one-way feed is correct here; nothing needs to travel back the other way.

Outbound to finance, for cost. Work order costs, parts issues and external invoices need to reach the general ledger and the asset register with the right cost centre, cost element and vehicle reference. The decision to make early is where purchasing lives. If external repairs are procured through the ERP, then the maintenance system raises the requirement and the ERP owns the purchase order and the invoice, and the maintenance system needs the actual cost back to complete the history. If purchasing lives in the maintenance system, the ERP needs the financial postings. Either is workable; having both, with neither authoritative, is the failure I see most often, and it produces two cost-per-kilometre numbers that never agree.

The tail includes fuel card imports, which are worth doing mainly because they give you a second odometer source, HR or driver records, insurance and claims systems, and hire-vehicle systems. Useful, none of them critical. Build the meter feed and the cost interface properly first, and treat the rest as later phases.

Two things to insist on in any integration design. Map on the permanent vehicle key, the VIN or chassis, not on the registration, for exactly the identity reasons set out earlier. And keep a manual fallback for the meter reading, so a telematics outage or a contract change degrades the programme rather than stopping it. For the vehicle-standards and roadworthiness context that frames much of the statutory side, the relevant national authority is the reference point; in the United States that is the FMCSA for commercial vehicle inspection and maintenance obligations, with local equivalents elsewhere, and your own regulator's requirements should be written into the schedule rather than left to memory.

The idea to walk away with

Fleet maintenance is not a harder version of building maintenance, it is a differently shaped one. The trigger is a meter rather than a date, which means the programme rests on a data feed that can fail silently, and on a human reporting culture that can fail just as silently. Everything else, the service tiers, the workshop model, the tyre discipline, the warranty evidence, the cost per kilometre, is built on those two foundations and degrades quietly when either gives way.

So the practical advice is narrow. Before you select a platform, decide how the odometer and hour readings will be captured, from which sources, with what validation, and who will be told when they stop arriving. Decide how a driver defect becomes a work order and what the driver sees happen next. Fix the vehicle identity key on the VIN. Then choose the tool, and choose it on the strength of the areas that match how your work is actually done, workshop and parts if the work is in-house, authorisation and invoice capture if it is outsourced.

Final thoughts

The fleets that run well are rarely the ones with the most sophisticated software. They are the ones where a named person clears a stale-meter report every week, where a driver who reports a soft brake pedal sees it fixed and hears about it, where every external invoice carries a job reference raised before the work started, and where the repair history has been keyed on something that does not change. None of that is a feature you can buy. It is the operating discipline that makes the features worth having.

If you take one action from this guide, run the stale-meter check. Pull every active vehicle and its last odometer or hour reading, sort by date, and look at the bottom of the list. In most fleets I have reviewed, there are vehicles on that list that have not reported in weeks, with mileage-based services that the system believes are comfortably in date. Finding them costs an afternoon. Not finding them costs an engine.

Related reading: Fleet management software: a buyer's guide, GPS fleet tracking and telematics, Meter-based and usage-based PM in a CMMS, CMMS for fleet and vehicle maintenance, Preventive maintenance for fleets and trucks, Spare parts and MRO inventory in a CMMS, Warranty management in asset systems, CMMS vs EAM: when you outgrow a CMMS.