Intelligent Maintenance Recommendations: AI Decision Support for CMMS

There is a moment in almost every predictive maintenance conversation where the technology has done its job and the human is left holding a problem. The model has flagged a pump. The vibration trend is real. The alert is credible. And then the planner sits there and asks the questions that actually matter: what work do I raise, what does it need, who do I send, and can I wait until the weekend or is this a today problem. Prediction stops at the alert. Everything after the alert is decision-making, and decision-making is where maintenance teams spend most of their time and where good AI can genuinely help. This guide is about that second half, the recommendation layer, and it is written the same way I would brief a client: confident about the maintenance side, which is my real domain, and measured about the AI side, separating what is deployed and proven from what is emerging and still needs a human hand on the wheel.

The message up front: intelligent maintenance recommendations are decision support, not decision automation. The best of them compress hours of planner research into seconds by pulling patterns out of your own work order history. The worst of them are confident suggestions built on dirty data that a good planner has to catch and override. The value is real, but it lives entirely on top of clean asset data, disciplined failure coding, and a human who still owns the decision. That last part is not a temporary limitation. It is the design.

1. From prediction to recommendation: the real decision-support gap

Predictive maintenance, done well, tells you that an asset is developing a fault and roughly how long you have before it fails. That is a genuine achievement and I have written about it at length in the predictive maintenance and failure prediction pillar. But sit with a maintenance planner for a day and you notice something: the prediction is the easy part of their world. The hard part is the twenty decisions that follow every alert and every work request, most of which have nothing to do with whether the asset is unhealthy and everything to do with how to respond efficiently.

When a work order lands on a planner's desk, they are quietly running a research task. What kind of job is this really. Has this asset done this before, and what fixed it last time. What parts will the technician need so they do not make three trips to the store. Who on the roster actually knows this equipment. Is there a permit involved. Can it wait for the planned window or does it bump the schedule. A skilled planner does this in their head in a few minutes, drawing on years of memory. A new planner does it slowly, or does not do it at all, and the technician turns up without the right part. The gap between prediction and action is not a technology gap. It is a knowledge-retrieval gap, and it is exactly the kind of gap that AI trained on your own history is well suited to close.

That is the honest framing of the recommendation layer. It is not intelligence in the science-fiction sense. It is your own maintenance history, made searchable and pattern-aware, surfaced at the moment of decision so the planner does not have to hold all of it in their head. Every recommendation in this guide, spare parts, technician, PM frequency, similar cases, is a variation on the same idea: take what your organisation already learned the hard way and put it in front of the person making the call, before they make it.

2. Recommending the maintenance action (what work to raise and why)

The first and most consequential recommendation is also the one where AI should be most cautious: what work should actually be raised. A condition alert says the asset is unhealthy. It does not say whether the right response is a lubrication top-up, a bearing replacement, a full overhaul, or simply increased monitoring for another two weeks. That translation, from symptom to work scope, is a reliability-engineering judgement, and it is where a recommendation engine can either genuinely help or confidently mislead.

Where it helps is by grounding the suggestion in what has worked before. If the failure signature on this asset class has historically been resolved by a specific corrective action recorded across dozens of past work orders, the system can surface that: "in similar cases on this pump family, the resolving action was bearing replacement in most instances, seal replacement in a minority." That is not the AI deciding what to do. It is the AI showing the planner the distribution of what actually fixed this before, with the counts, so a human can weigh it. Presented that way, with the evidence attached, it is a strong decision aid.

The mechanism that makes this trustworthy is disciplined failure coding. If your work orders carry a consistent Problem, Cause and Action structure, the history becomes a queryable record of symptom-to-remedy pairs, and recommendations become grounded rather than guessed. If your history is a pile of free-text comments like "fixed" and "ok now", there is nothing coherent for the system to learn from, and any recommendation it produces is theatre. This is why I keep returning to the failure codes pillar: it is the single most important prerequisite for every recommendation in this article, and it is unglamorous, manual, and non-negotiable.

The proven part of action recommendation today is retrieval and ranking: finding the relevant past cases and presenting the actions that resolved them, ordered by how well they match. The still-emerging part is anything that claims to reason about a novel failure it has never seen and prescribe a specific repair with confidence. Treat the first as a mature capability you can deploy. Treat the second as a research demo until it has proven itself on your own assets, because a wrong action recommendation does not just waste a trip, it can put a technician on the wrong repair for a safety-relevant asset.

3. Suggesting the right spare parts (BOM history, failure-to-part links)

If there is one recommendation that pays for itself fastest and carries the least risk, it is spare parts. The failure mode here is mundane and expensive: a technician is dispatched to a job, arrives, diagnoses the problem, and discovers they did not bring the part. Now there is a second trip, a return to the store, possibly an order and a wait, and an asset down longer than it needed to be. Multiply that across a large maintenance operation and the wasted time is enormous. Parts recommendation attacks exactly this waste, and it does it with data almost every organisation already holds.

There are two solid sources the system draws on. The first is the bill of materials, the engineered list of what components an asset is built from. If the asset is a specific pump model and the fault is bearing-related, the BOM narrows the candidate parts to the bearings that actually belong to that pump, with the correct part numbers, rather than a generic guess. The second, and often more powerful, source is failure-to-part history: across all past work orders of this type on this asset class, which parts were actually consumed. That empirical link, this symptom historically needed these parts, is frequently more accurate than the theoretical BOM because it reflects what technicians really replace, including the seals, gaskets and consumables that always go along with the headline component.

Combine the two and a parts recommendation becomes genuinely useful: for this job on this asset, past cases most often consumed this bearing, this seal kit, and this quantity of lubricant, and here is current stock on hand for each. A planner can stage the kit before the technician leaves. This is a mature, low-risk capability. The parts list is a suggestion the planner reviews, wrong suggestions cost a few minutes of review rather than a safety incident, and every completed job feeds the history that makes the next suggestion sharper.

The practitioner's insight: parts recommendation is the best place to start with maintenance AI, not because it is the most impressive, but because it is the safest and the most measurable. The data exists, the risk of a wrong suggestion is low, and the benefit, fewer wasted trips and shorter downtime, shows up in numbers the operation already tracks. Start where the risk is low and the return is countable, and earn the credibility to do the harder things later.

4. Suggesting the right technician (skills, certifications, past success)

Assigning the right person to a job is a scheduling decision that good planners make on instinct and that becomes hard the moment the operation is large enough that no single person knows the whole workforce. The instinct blends several factors: does this technician have the skills for this equipment, do they hold the certifications the job legally requires, are they available in the needed window, are they in the right zone or building, and have they done this kind of work successfully before. AI can support this by making those factors explicit and matchable instead of leaving them in a supervisor's memory.

The proven, low-controversy version of technician recommendation is competency and compliance matching. If the job is on high-voltage switchgear and requires a specific certification, the system should only surface technicians who actually hold that certification and whose certification is current. That is not artificial intelligence in any deep sense, it is a filter against a skills matrix, but it is exactly the kind of check that gets missed when a supervisor is assigning fifty jobs before shift start, and getting it wrong on a safety-critical or permit-controlled task is a serious matter. A system that simply refuses to suggest an uncertified technician for a certified task is providing real, dependable value.

The more nuanced layer, ranking available qualified technicians by past success on similar work, is useful but needs a lighter touch. If the history shows that certain technicians resolve a given fault type on the first visit more often, or complete this asset class faster with fewer callbacks, that is genuine signal worth surfacing to a planner. But it has to be handled carefully. Past success data is easily skewed: a technician who takes the hard jobs will show worse raw numbers, and a metric used to rank people can quietly become a metric used to judge them. My guidance is to keep this firmly as a suggestion to a human supervisor who knows the context, never as an automated assignment, and to treat "past success" as one input among several rather than a performance verdict. The right technician is a decision a supervisor should own, with the data serving them, not replacing them.

5. Optimizing PM frequency (right-sizing preventive schedules with evidence)

Preventive maintenance schedules have a tendency to be set once, at commissioning, based on a manufacturer's conservative recommendation or a copied template, and then never revisited. Over years this produces two opposite errors sitting side by side in the same program: assets that are over-maintained, touched far more often than their condition warrants, wasting labour and sometimes inducing failures through unnecessary intrusive work, and assets that are under-maintained, failing between intervals because the schedule never matched their real duty. Right-sizing PM frequency is one of the highest-value things a maintenance organisation can do, and it is an area where evidence-driven recommendations shine because the question is fundamentally statistical.

The evidence the system reasons over is your own history. For a given PM task on a given asset class, how often did the preventive inspection actually find something that needed action, and how often did it find nothing. If a monthly inspection has come back clean for two years straight, that is strong evidence the interval is too tight and could be extended. Conversely, if failures keep occurring shortly before scheduled PMs, the interval is too loose and should be tightened, or the task itself is not catching the developing fault. This is the same time-versus-meter-versus-condition logic I lay out in the preventive maintenance strategies pillar, and AI does not replace that logic, it applies it at scale across thousands of PM tasks that no human has time to review individually.

What makes this a recommendation rather than an automation is that interval changes have consequences a model cannot fully see. Extending a PM interval on a safety-critical or statutory asset is not a decision you make because the finds-rate looks low, because some inspections are legally mandated at a fixed frequency regardless of what the data says, and some rare failure modes are exactly the ones that a clean run of inspections should not lull you into ignoring. The right pattern is for the system to flag candidates, "these forty PM tasks show a pattern suggesting the interval could be reviewed," and hand a ranked, evidence-backed list to a reliability engineer who applies the judgement about which are safe to change and which are protected by regulation or criticality. Criticality is central here, and the asset criticality classification pillar is the frame that decides how much evidence you should demand before touching an interval.

6. Finding similar historical cases (case-based reasoning from work order history)

Underneath most of the recommendations in this guide is one quietly powerful technique: finding similar past cases. Human experts reason this way naturally. An experienced engineer confronted with a new problem does not calculate from first principles, they think "this reminds me of the compressor we had trouble with in 2019," retrieve what happened, and adapt it. This is case-based reasoning, and it is one of the oldest and most robust ideas in applied AI precisely because it mirrors how skilled practitioners actually think. Applied to maintenance, it means: given the current situation, find the most similar situations in the work order history and show what was done and how it turned out.

The reason this matters so much is that it is how institutional knowledge survives people leaving. When a senior technician retires after twenty years, a large part of what walks out the door is their memory of past cases, the tacit "we tried that and it did not work, what fixed it was this." A case-retrieval system does not fully replace that judgement, but it does preserve the raw material of it. A new technician facing an unfamiliar fault can be shown the ten most similar past jobs, what the diagnosis turned out to be, what parts were used, and how long it took. That is the difference between starting from nothing and starting from your organisation's accumulated experience.

Technically, this is where the newer language-model tooling is genuinely earning its place, because much of the useful detail in maintenance history lives in free-text notes that older keyword search handled poorly. Retrieval over both the structured fields and the narrative text lets a system find cases that are similar in substance even when they do not share exact keywords. This is the same retrieval-grounded approach I describe in the enterprise knowledge assistant and RAG pillar, applied to work order history rather than documents. The important discipline, and I will keep hammering it, is that the system should show the actual retrieved cases with links back to the source work orders, so the human can read the real record and judge relevance, rather than trusting a summary that may have smoothed over the detail that mattered.

7. Maintenance optimization across the whole portfolio

Everything so far has been about a single job or a single asset. The recommendation layer becomes strategically interesting when it steps up to the whole portfolio and starts reasoning about maintenance as a system with finite resources. A maintenance operation is a constant balancing act: a fixed crew, a fixed budget, a finite parts inventory, and far more work than can be done at once. The optimisation question is which work to do, in what order, with which resources, to get the most reliability for the least cost. Humans do this with experience and spreadsheets. AI can support it by handling the combinatorial scale that overwhelms both.

Consider the concrete decisions where portfolio-level recommendations help. Scheduling and sequencing: if three jobs are due in the same building this week, grouping them into one visit saves travel and access setup, and a system can spot those clustering opportunities across thousands of open work orders faster than a planner scanning a list. Resource levelling: smoothing the workload so crews are neither idle nor overwhelmed week to week. Parts and inventory: recommending stock levels informed by predicted demand from upcoming and likely work, so critical spares are on the shelf without tying up capital in slow-moving stock. Priority arbitration: when everything cannot be done, ranking by asset criticality and consequence so the scarce hours go to the assets whose failure hurts most.

This is real, and elements of it are well established in mature scheduling and planning tools. But I want to be honest about the limits, because portfolio optimisation is where the gap between a clean model and a messy operation is widest. An optimiser produces a mathematically efficient plan based on the constraints it was given, and real maintenance is full of constraints that never make it into the model: the access permit that takes three days, the one technician who is the only person the client trusts on a particular system, the operational reality that you cannot take two redundant pumps down in the same window. A plan that is optimal on paper and impossible in practice erodes trust fast. The productive use is optimisation as a proposal that a planner adjusts against reality, not a schedule handed down as final.

8. Decision support versus decision automation (why the human stays in the loop)

This is the section the whole article has been building toward, and it is the distinction that separates maintenance AI that works from maintenance AI that gets switched off after a bad quarter. Decision support means the system does the research and presents options with evidence, and a human decides. Decision automation means the system decides and acts on its own. For the maintenance recommendations in this guide, support is the right design, and automation is mostly a mistake, and I want to explain why rather than just assert it.

The first reason is consequence asymmetry. Maintenance decisions touch physical equipment, safety, and continuity of operations. A wrong parts suggestion costs a review. A wrong autonomous decision to defer maintenance on a critical asset, or to send an under-qualified technician to a permit job, can cause real harm. When the downside of an error is measured in safety incidents and unplanned outages rather than a few wasted minutes, the correct place to put the human is between the recommendation and the action, every time. This is not caution for its own sake, it is proportionate to what maintenance actually controls.

The second reason is that these systems reason over your history, and your history is imperfect. Recommendations reflect the data they were trained on, including its gaps, its biases, and the cases nobody bothered to record. A human planner carries context the data does not: they know the pump was rebuilt last month even though the record is not updated yet, they know this client, they know the rare failure mode that only bit them once and never got coded properly. That context is exactly what stops a plausible-but-wrong recommendation from becoming a wrong action. Remove the human and you remove the correction layer that catches the model's confident mistakes.

The honest caution: the danger with a good recommendation engine is not that it is wrong, it is that it is usually right. A system that gives sound suggestions ninety-five percent of the time trains its users to stop checking, and then the five percent where it is confidently wrong slips through because nobody is looking anymore. Automation bias is a documented human tendency, and it is strongest precisely when the tool is good. Keeping the human genuinely in the loop, not rubber-stamping, is a discipline you have to design for and reinforce, not something that happens by default. The better the recommendations get, the harder you have to work to keep people actually reviewing them.

None of this is an argument against the technology. It is an argument for deploying it as what it is: a fast, tireless research assistant that surfaces your own knowledge at the moment of decision, and a human who still owns the call. That division of labour, machine retrieves and ranks, human judges and decides, is where the value is real and the risk is controlled. It also happens to be the model that maintenance teams accept, because it respects rather than replaces the expertise they have spent careers building.

9. The data foundation these recommendations depend on (clean history, failure codes)

Every recommendation described here is only as good as the data underneath it, and this is the part that determines success or failure long before any AI tool is selected. I have watched organisations invest in sophisticated recommendation capability and get nothing back, not because the technology failed, but because it was fed a maintenance history that could not support intelligent suggestions. Clean data is not a nice-to-have that improves the results at the margin. It is the precondition without which the whole layer produces confident noise.

The specific foundations that matter, roughly in order of importance:

• Consistent failure coding: a disciplined Problem-Cause-Action structure applied uniformly is what turns work order history into learnable symptom-to-remedy pairs. Without it, action and case recommendations have nothing coherent to learn from. This is the single highest-leverage data investment, and it is entirely a matter of process discipline, not technology.
• Accurate asset register and hierarchy: recommendations depend on knowing what an asset is, what class it belongs to, and how it relates to others. If assets are duplicated, misclassified, or missing their model information, the system cannot find genuinely similar cases or map the right BOM.
• Reliable parts and BOM data: parts recommendations need part numbers that are correct and consumption that is actually recorded against work orders. If technicians take parts without booking them to the job, the failure-to-part history is fiction.
• A maintained skills and certification matrix: technician recommendations are only as trustworthy as the record of who is qualified and current. An out-of-date certification record is worse than none, because it looks authoritative while being wrong.
• Captured outcomes: whether the intervention actually worked, whether the asset failed again soon after, whether the job was done in one visit. Outcomes are what let the system learn what good looks like. Most organisations record what was done far better than they record whether it worked.

The uncomfortable message I deliver in most assessments is that the data work comes first, it is unglamorous, and there is no shortcut around it. An organisation tempted to buy the recommendation engine before fixing the failure coding is putting the reward before the work, and the reward will not materialise. The good news, and it is genuine good news, is that the data foundation pays off regardless of AI. Clean failure codes, an accurate asset register and captured outcomes make a maintenance operation run better on their own. The recommendation layer is best understood as one more reason to do the data discipline you should be doing anyway, and a compounding return on it once it is in place.

10. Where recommendations help and where they mislead (honest)

Let me close the substance of the guide with the balanced ledger I would give a client deciding where to invest, because the honest answer is that these capabilities are strong in some places and weak in others, and knowing which is which is the whole skill. Pretending it is uniformly transformative is how you set up the disappointment.

Where recommendations genuinely help, today, with proven capability:

• Parts staging: high value, low risk, data usually available. The clearest place to start and the easiest to measure.
• Certification and competency filtering: preventing under-qualified assignment to controlled work is dependable and safety-relevant, and it is essentially a reliable filter rather than a speculative model.
• Similar-case retrieval: surfacing relevant past jobs preserves institutional knowledge and accelerates diagnosis, especially for less experienced staff, as long as the real cases are shown for the human to judge.
• PM interval candidates: flagging schedules that the finds-rate suggests are mistuned, for engineering review, is a strong use of history at a scale humans cannot match manually.

Where recommendations mislead, or need much more caution:

• Prescribing repairs for novel failures: retrieval of past cases is solid, but anything claiming to reason out a fix for a fault it has never seen should be treated as unproven on your assets until it demonstrates otherwise.
• Ranking people by past success: useful signal, easily distorted, and prone to becoming a performance judgement it was never meant to be. Keep it as one input to a human supervisor.
• Portfolio optimisation as final answer: mathematically optimal plans routinely collide with real constraints the model never saw. Use it as a proposal, not a decree.
• Anything built on poor data: a recommendation engine on dirty history does not fail loudly, it fails quietly, producing plausible suggestions that are subtly wrong, which is the most dangerous failure mode of all because it is the hardest to catch.

The pattern across that ledger is consistent. Recommendations are strong when they retrieve and rank facts from clean data and hand them to a human. They are weak when they are asked to reason beyond their data or to decide without a human, and they are actively dangerous when the data beneath them is bad and the confidence on top of them is high. Deploy them where they are strong, guard against where they are weak, and never let good performance talk you into removing the human. For a picture of how these pieces come together in a working utilities context, the AI copilot for utilities CMMS pillar walks through the assistant pattern end to end.

Final thoughts

The step beyond predicting failures is recommending what to do about them, and it is a step worth taking, because prediction that does not change the next action is just a more expensive way to be surprised. The recommendation layer, at its best, does something quietly valuable: it takes what your organisation already learned through years of work orders, parts consumed, technicians dispatched and inspections completed, and puts it in front of the person making the decision, at the moment they make it. That is not magic and it is not intelligence in the grand sense. It is your own history, made retrievable and pattern-aware, serving a human who still holds the judgement.

Everything that makes it work is within a maintenance leader's control rather than a vendor's roadmap. Clean the failure coding. Fix the asset register. Capture whether interventions actually worked. Start with the low-risk, high-value recommendations like parts staging and certification filtering, prove the value in numbers the operation already tracks, and earn the credibility to attempt the harder things. And keep the human in the loop deliberately, not because the technology is immature, but because maintenance decisions touch safety and continuity, and the human is the correction layer that catches the confident mistake. Do that, and intelligent recommendations become what they should be: a tireless research assistant that makes good planners faster and helps new ones become good, without ever pretending to be the one who decides.

Related reading: Predictive maintenance and failure prediction, AI copilot for utilities CMMS, Preventive maintenance strategies, Asset criticality classification, Enterprise knowledge assistant and RAG.