A business case is more persuasive when it commits to specific numbers that can be checked afterward. Four metrics carry most of the value.
The headline metric and the hardest to estimate honestly. Prediction reduces unplanned downtime by converting some failures into planned interventions, but only for assets that are instrumented and that fail in ways the model can detect.
Be specific about which assets. A claim that AI will reduce downtime across the whole plant is not credible. A claim that it will address the six assets responsible for most of last year's unplanned hours is. Our overview of downtime costs provides context for valuing these hours.
The most reliable saving and the most frequently overlooked. Fixed intervals over-service assets in light duty, and moving those assets to condition-based intervals removes work that was never needed.
This one is attractive in a business case because it is measurable in advance. You know how many PM hours you spend and on which assets. If condition data shows a subset could safely move to longer intervals, the saving can be calculated rather than projected. See AI maintenance scheduling.
A useful directional indicator, though slower to move and noisier than the two above. It matters to the case mainly as evidence that reliability is genuinely improving rather than that failures are being reclassified.
Better failure prediction allows lower safety stock on predictable items and better staging on planned work. The saving is real but usually smaller than expected, and it takes longer to realize because inventory policy changes slowly.
This is the step most often skipped and the one that determines whether anyone believes the result afterward.
Before deployment, record unplanned downtime hours by asset, PM labor hours by asset class, emergency work as a percentage of total, parts spend, and failure counts on the assets you intend to model. Twelve months is ideal, and six is workable.
A baseline assembled after go-live, from memory or from partial records, will not withstand scrutiny from a finance team, and it invites the suspicion that the numbers were chosen to suit the conclusion.
Vendor case studies describe the results of their most successful customers, usually those with good data and committed sponsorship. Your first year will not look like that.
Build three scenarios. A conservative case assuming modest improvement on a limited asset set, a mid case, and the vendor's projection labeled clearly as the vendor's projection. Present the conservative case as the basis for the decision. If it does not justify the investment on its own, the project is not ready.
Most implementations see meaningful returns in the second year rather than the first, because the first year is spent on data cleanup, baseline establishment, and building trust in the output. A case promising first-year payback usually either overstates the benefit or understates the implementation effort.
A useful framing for a finance conversation: year one is an investment in data foundation with partial returns, year two is where the operating saving appears, and year three is where expansion compounds it. This is more defensible than a flat annual projection and matches how these deployments actually behave.
Software licensing is generally the smaller part of the total. The items below are real, routinely excluded from proposals, and frequently larger than the subscription.
Data cleanup. Asset hierarchy correction, failure code standardization, and historical record remediation. This is internal labor, often several months of someone's time, and it is unavoidable. See is your maintenance data AI-ready.
Sensor hardware and installation. For prediction on assets not currently instrumented, installation typically costs more than the sensors, particularly where it requires downtime or electrical work.
Integration. Connecting the platform to ERP, inventory, and production systems. Where these are older or heavily customized, this becomes the dominant line item.
Training and change management. Technicians recording data differently, planners working from recommendations, supervisors defending schedules that move. Underfunding this is the most common reason otherwise sound deployments fail to deliver.
Ongoing model oversight. Someone reviewing predictions, correcting errors, and maintaining trust in the system. This is a permanent allocation of time rather than a project cost.
The learning period. For several months the system produces output that is not yet reliable while the team continues working as before. That parallel running is a real cost and belongs in the case.
Worth anticipating, because a sceptical CFO will raise it.
Pilots run on selected assets, usually the best instrumented and most problematic, where improvement is easiest to demonstrate. They receive attention that routine operations do not, from vendor engineers and an interested internal team. And they benefit from the fact that people behave differently when they know they are being measured.
None of this makes pilot results dishonest. It does mean that extrapolating pilot performance across an entire asset base overstates what follows. A defensible case discounts pilot results when projecting at scale and says explicitly that it has done so.
The strongest business case for AI in maintenance is usually not the dramatic one. It is a specific, conservative case built on a measured baseline, covering a defined set of assets, with implementation costs stated honestly and a payback horizon in the second year.
That case is more likely to be approved, because it is more likely to be believed, and considerably more likely to be met. Cases built on vendor benchmark figures tend to be approved once and then remembered unfavorably.
Establish the baseline before you buy anything. Everything else in the case depends on it.
It varies enough by asset base, data quality, and starting maturity that any single figure should be treated sceptically. Teams moving from reactive maintenance with poor records see the largest gains, mostly from basic discipline rather than from AI. Teams with mature preventive programmes see smaller but more predictable gains, usually concentrated in reduced over-maintenance. Build your own estimate from your own baseline rather than adopting a published figure.
Most implementations see meaningful returns in the second year. The first year is largely consumed by data cleanup, baseline establishment, and building enough confidence in the output for the team to act on it. Proposals promising first-year payback are usually counting the conventional CMMS benefits, which do arrive quickly, rather than the AI layer specifically.
Data cleanup and change management, consistently. Both are internal labor rather than vendor line items, which is precisely why they are missing from proposals. Sensor installation is the third, since fitting instrumentation to existing assets often costs more than the sensors and may require downtime.
Record a baseline before deployment covering unplanned downtime by asset, PM labor hours, emergency work percentage, parts spend, and failure counts. Measure the same items afterward on the same assets. Without a pre-deployment baseline, any claimed improvement is an assertion, and finance teams treat it accordingly.
It depends on asset criticality rather than headcount. A small team running equipment where a single failure causes expensive downtime can justify prediction on those specific assets. A small team maintaining many inexpensive, quickly repaired assets usually gets more value from disciplined preventive maintenance and a well-used CMMS.
AI Maintenance Management
Is Your Maintenance Data AI-Ready? A Practical Assessment
¿Cuáles son las estadísticas y los datos más interesantes sobre el costo real del tiempo de inactividad?
MÁS DE 4000 EMPRESAS CONFÍAN EN LA GESTIÓN DE OPERACIONES DE ACTIVOS
Los datos de sus activos y equipos no pertenecen a un silo. UpKeep simplifica ver dónde se encuentra todo, todo en un solo lugar. Eso significa menos conjeturas y más tiempo para concentrarse en lo que importa.

![[Review Badge] Gartner Peer Insights (Dark)](https://www.datocms-assets.com/38028/1673900494-gartner-logo-dark.png?auto=compress&fm=webp&w=336)
