What a maintenance system has to get right
Maintenance software is demonstrated on dashboards and lived on the four screens a technician sees. Those are the ones to evaluate.
Computerised maintenance management systems are sold on reporting: charts of compliance, cost against budget, planned versus reactive. Those reports matter to whoever signs the contract and they are not what determines whether the system works. For a product-side comparison related to understanding activity data collected by software, see employee PC activity tracking before deciding which data the operation actually needs.
What determines that is whether a technician standing in a plant room can see the job, record what they found, and close it in under a minute.
The asset record is the foundation
Everything else attaches to it. The system needs a hierarchy that matches how your estate is actually organised — site, building, floor, system, asset — and it needs to accommodate the granularity you chose rather than imposing its own. For a wider operational and compliance reference, consult CISA operational technology guidance.
Check that an asset can be moved, replaced or decommissioned without losing its history, because all three will happen. Systems that treat replacement as deleting and recreating destroy exactly the failure history you bought the system to accumulate.
Scheduling has to handle real patterns
Fixed calendar intervals are the easy case and every product does them. The cases that separate products are the ones estates actually contain:
- Intervals based on run hours or a meter reading rather than the calendar.
- Tasks that must not be moved because they are statutory, alongside tasks that can float.
- Seasonal constraints — this task must fall between August and October.
- Load levelling, so the system does not generate a month with triple the workload.
- Nested frequencies, where the annual service includes the quarterly tasks rather than duplicating them.
Ask how the product handles an annual task that subsumes the quarterly one. Products that generate both in the same week produce a schedule technicians learn to ignore.
Mobile is where the system succeeds or fails
The technician's view is the whole product from the perspective of the people generating the data. It needs to work offline in a basement, show the asset's recent history alongside the job, allow a photograph, and close a job in a few taps.
Evaluate this on the oldest phone on the team, in a plant room, with a technician who did not choose the product. If closing a job takes five minutes, the closing notes will be one word and the history you are paying to build will be worthless.
Getting data out
Before adopting anything, establish how you would leave. Can the asset register, job history, attached certificates and readings be exported in a usable format, by you, without a support request?
Maintenance history compounds in value over years, which makes it the data you are least willing to lose and therefore the strongest lock-in a vendor has. Test the export during the trial, for real, and look at what comes out — particularly whether attachments come with it or only their filenames.
Ignore the modules you will not staff
Products offer inventory management, procurement, condition monitoring, capital planning and energy analytics. Each is real capability and each needs someone to operate it.
A department of five will use scheduling, work orders, the asset register and mobile capture. Modules bought beyond that are configured once, populated partially, and become a source of misleading reports built on incomplete data — which is worse than not having them.