Equipment condition tracking software helps facilities teams record how assets are performing, identify deterioration and decide what should happen next. Its value lies in connecting inspections, defects, work orders, costs and decisions, not merely creating a digital asset list. A good system helps teams distinguish an ageing but serviceable asset from a critical asset requiring intervention, while making the evidence, owner and next action clear.
What problem does condition tracking solve?
What should a condition record contain?
How do condition and criticality work together?
Which tracking method fits the estate?
How should work orders and PPM contribute?
When is specialist software worthwhile?
How should condition tracking be implemented?
Which mistakes make condition data unreliable?
The real problem is rarely that an FM team has no asset information. More often, it has plenty of information but cannot turn it into a confident answer when somebody asks whether an asset should be repaired, monitored, refurbished, or replaced.
The installation date may sit in the asset register, service visits in a contractor portal, invoices in finance, photographs on an engineer’s phone, and the most useful detail in the memory of someone currently working at another site. The spreadsheet exists, obviously. It has also developed six colour codes, two versions of amber and a column called “notes 2”, which is how mature information systems announce themselves.
Equipment condition tracking brings those fragments into a repeatable process. It records the asset’s current state, the evidence supporting that assessment, how its condition is changing and what action follows. This supports maintenance prioritisation, lifecycle planning, budget decisions and contractor accountability.
That is different from inventory control. An asset register answers, “What do we have and where is it?” Condition tracking answers, “How is it behaving, what is getting worse, what matters most, and what are we going to do about it?”
For most estates, condition data comes from planned inspections, reactive jobs, test results, controls data, user reports, and engineering judgement. Some assets may stream readings continuously, but many will be assessed periodically. The right frequency depends on criticality, likely failure mode, legal duties, manufacturer guidance and the practical cost of collecting the information.
A useful condition record should explain the assessment well enough for another competent person to understand it and act.
At minimum, the record should connect three kinds of information:
The record also needs history. An asset that has remained in the same condition for three years is different from one that has fallen in six months while repair costs rise. Software should retain previous assessments rather than overwrite the latest score; otherwise deterioration disappears precisely when the history becomes useful.
Service notes, or evidence, must be specific. “Falling condition” tells the next person almost nothing. “Drive-end bearing noise has increased since the previous inspection; temperature remains within normal range; inspect within four weeks” gives them something to work with. The contractor update “all sorted” remains popular, but it is not condition data.
Condition should not set priority on its own. Priority comes from combining condition with criticality and the consequence of failure.
Criticality describes how much the organisation depends on an asset and what happens if it becomes unavailable. Relevant consequences may include compliance, operational shutdown, service interruption, damage to other equipment, loss of environmental control, customer impact and recovery time.
A poor decorative light fitting and a poor pump supporting a critical process may both receive the same condition status, but only one is likely to occupy the morning meeting.
This prevents teams from spending disproportionate effort on assets that look untidy but have little consequence, while ignoring healthy-looking critical equipment that still requires contingency or redundancy.
Criticality should also reflect site context. The same boiler model may be less critical in a building with duty-and-standby capacity and highly critical where there is no alternative heat source.
Some teams capture criticality as a formal asset attribute; others maintain it as operational understanding that informs response decisions. Either works - what matters is that condition alone isn't driving urgency.
For capital planning, physical condition should be separated from functional suitability. An asset may be physically sound but lack capacity, controls compatibility, energy performance, or parts support. Replacing it can still be sensible.
The right method usually combines periodic human assessment with selected automated monitoring. Sensor coverage everywhere is neither necessary nor automatically useful; it can produce a very modern pile of readings without clarifying who should act.
| Method | Where it tends to fit | Main limitation |
|---|---|---|
| Spreadsheet or inspection form | Small, stable asset populations with one clear owner. | Version control and cross-site visibility deteriorate as users multiply. |
| CAFM or CMMS | Estates connecting inspections, work orders, documents, costs, and ownership. | Value depends on workflow design and disciplined completion data. |
| BMS or controls data | Systems where alarms and operating trends reveal performance changes. | Alarms may show symptoms without establishing diagnosis or action. |
| Specialist sensors | Selected assets with detectable failure patterns and a clear business case. | Hardware, thresholds, false alerts, and response ownership require management. |
| Specialist monitoring service | High-value equipment requiring vibration, lubricant, or thermal analysis. | Reports can become detached from work management. |
Condition-based maintenance adjusts work using evidence about an asset’s present state. Predictive maintenance goes further by using trends or models to estimate a future failure or performance change. They are related but not interchangeable.
Start with the failure mode. If deterioration can be detected early, the warning provides enough time to respond, and the consequence justifies the cost, closer monitoring may be valuable. If failure is random or the asset can be replaced quickly at low consequence, a sensor may simply provide an expensive way to discover it has stopped.
Use existing information before buying hardware. Reactive work frequency, repeated alarm codes, engineer observations, energy consumption and parts use may already reveal deterioration. The first improvement is often connecting information the estate already pays to collect.
Every meaningful interaction with an asset should improve its record. Planned maintenance provides repeatable inspection points, while reactive work reveals failure behaviour and operational disruption. Together, they create a stronger picture than either source alone.
A completed work order should capture the fault found, work undertaken, parts used, readings if necessary, residual defects, condition changes and follow-on recommendations. Where further action is required, completion should expose remedial actions rather than burying the recommendation in an attachment.
Engineers need quick, asset-specific prompts in the field, not a generic twenty-question form for every job. Mandatory fields should be limited to information that genuinely affects control or reporting. A perfect form that nobody completes is merely graphic design.
Condition evidence may justify adjusting maintenance activity where competent people approve the change. It should not be used casually to defer statutory examinations, mandatory tests, warranty conditions or other fixed obligations.
Reactive history should distinguish separate visits from separate failures. Three work orders may represent one unresolved fault, three unrelated defects, or a contractor returning twice with the correct part. Without that distinction, failure counts become misleading.
Contractors should follow the same condition definitions and evidence standards as internal teams. Specify required completion information, evidence formats, and turnaround times in the workflow and contract. A portal alone does not create accountability. It simply gives “paperwork to follow” a password.
Specialist software becomes worthwhile when the cost of fragmented information and inconsistent decisions exceeds the effort of operating a controlled system. Estate size matters, but complexity matters more.
A spreadsheet may remain reasonable for a small asset population managed by one experienced team. Buying a platform before defining the process can replace a familiar spreadsheet with a more expensive screen containing the same doubtful information.
The case for CAFM or CMMS functionality becomes stronger when:
A maintenance-led operation may find a CMMS sufficient when asset work and technician execution are the main concerns. A CAFM platform becomes more relevant where maintenance sits alongside compliance, contractors, helpdesk demand, approvals and multi-site reporting. Category labels overlap, so actual workflows, users, integrations and governance are more useful buying criteria than the badge on the website.
Implementation should begin with a limited group of important assets and a defined decision process. Assessing every maintainable item at once usually creates a backlog of unverified records before the team understands what information it needs.
Agree whether condition information will support maintenance prioritisation, capital planning, contractor management, risk review, or several purposes. If nobody can explain which decision a field supports, it probably should not be mandatory.
Begin with one site, system, or group of critical assets. Confirm asset identities and locations before collecting detailed condition data. The asset register always becomes fascinating when something breaks, which is a poor time to discover that three pumps share the same description.
Define the condition scale, minimum evidence, and follow-on process. Decide who can change ratings, who reviews high-priority findings, and how disagreements are resolved.
Test the process with the person standing in front of the asset. Identification, rating, notes, photographs, and next action should be quick to record.
Compare assessor ratings, confirm that recommendations become owned work, and review whether managers can use the outputs. Improve the process before scaling it.
Assign responsibility for data standards, supplier compliance, exception reviews and periodic quality checks. Condition data will decay if everyone contributes, but nobody owns it.
Reports earn their place when they show action taken, data quality, and change over time - a colour distribution alone tells you very little
Dashboards that matter most for condition tracking sit across maintenance performance, asset management, compliance and cost reporting:
Reports should be interactive. You should be able to drill from a high-level trend into the individual work orders, assets, or costs driving it - meaning condition reporting becomes a diagnostic tool, not a static summary for a slide deck.
Avoid claiming condition tracking has reduced failures unless the baseline and asset population support the conclusion. Reactive work may initially rise because inspections are finding issues that were previously invisible. That can indicate better control rather than worse performance.
Return on investment may include avoided disruption, more planned purchasing, fewer duplicate inspections, faster information retrieval, and stronger capital justification. Separate verified savings from avoided-cost estimates. Finance teams appreciate this, largely because they have met optimistic software business cases before.
Treating age as condition. Older equipment can remain serviceable, while newer equipment can perform poorly because of duty, environment, or maintenance.
Recording a value without evidence. A rating needs an observation, measurement or defensible professional assessment.
Ignoring criticality. Condition alone directs attention towards the most visibly degraded asset, not necessarily the most important one.
Collecting data without a follow-on workflow. A remedial action with no owner or priority is a warning label attached to an administrative delay.
Overwriting history. If previous assessments disappear, the team cannot see deterioration or test whether intervention worked.
Making field forms too demanding. Excessive mandatory data encourages copying, vague entries, and retrospective completion.
Buying sensors before defining the response. An alert needs a threshold, recipient, decision rule and action path.
Treating software as the owner. Systems can schedule, connect, prompt and report. They cannot define the organisation’s risk appetite or secure a capital budget.
Equipment condition tracking works when it turns observations into defensible action. Start with a small set of important assets, define condition in plain English, preserve evidence and history, and make every material finding lead to an owner and a date.
Software can make this easier across sites, suppliers, and maintenance workflows, but it cannot rescue an undefined rating scale or a process nobody trusts. At expansive, our view is simple: the useful condition record is the one that helps an FM team decide what to do next, explain why, and prove that it happened.
Before evaluating a platform, take one genuine asset problem into the demo and follow it from inspection to completed action and reporting. That journey will tell you more than a long feature checklist ever will.