Most maintenance teams evaluating an AI predictive maintenance software are short on people, not data. The vibration route still has to be walked, the third-party report still takes a week, the threshold alarm still goes off, and someone still has to go out and check whether it means anything.
So the question buyers are asking isn't "which sensor has the best spec sheet?" It's this:
What should I require from a system when I can't add headcount, and where do I start?
The short answer: don't buy more alerts. Require evidence your team can act on, and agree up front on what a 90-day evaluation can realistically prove.
This guide covers the five capabilities to require, a pilot test for each, how to pick the assets to start with, and a 90-day plan with metrics you can defend to leadership.
Start with your highest-consequence problem, not a sensor count
Many pilots start with a number: "Let's put 30 sensors out and see what happens." That tests the vendor's installation process, not whether the system can solve the problem that's costing you money.
Start with the failure you most need to catch instead. Maintenance leaders we spoke with in recent evaluations kept coming back to the same idea: prove it on our equipment. One specialty materials producer wanted to detect rotor wear on a pelletizer before cut quality deteriorated. That's a specific failure mode with a specific consequence and a measurable quality signal. A metal castings manufacturer asked to keep the scope focused on its casting machines instead of spreading sensors across the plant.
To choose your pilot assets, rank candidates by:
- Consequence of failure. Downtime cost, safety exposure, quality loss, and how long a replacement or repair takes.
- Known failure modes. Can you name what typically goes wrong (bearing wear, misalignment, lubrication, looseness, cavitation)? If you can't name it, you can't judge whether the system caught it.
- Current blind spots. Assets that only get a monthly route, or that are hard or unsafe to reach, are where continuous monitoring earns its keep.
- Representative operating conditions. Include assets with variable speed, variable load, or intermittent duty. A system that only works on steady-state motors won't cover your whole plant.
- A named owner. Every pilot asset needs a person responsible for acting on findings. No owner, no proof.
A good pilot scope is usually a handful of critical asset groups with clearly stated failure modes, plus enough "ordinary" assets to test coverage and false-alarm behavior across operating conditions.
The 5 capabilities to require, and how to test each in a pilot
Sensor specs matter, but they don't tell you whether your team will get any time back. Each requirement below comes with a pilot test you can write into your evaluation agreement.
1. Multimodal coverage of the assets that actually matter
Why it matters: Buyers kept asking about sampling rates, battery life, connectivity, mounting, hazardous-area suitability, and whether monitoring holds up under changing loads. Behind all of those questions is a bigger one: will the system catch this failure, on this asset, early enough to act?
A single signal can’t answer that. Each sensing mode catches different failure modes at different stages of the same failure:
- Ultrasound picks up friction and lubrication problems early in the failure curve.
- Vibration shows mechanical faults like imbalance, misalignment, looseness and bearing wear.
- Temperature confirms that heat is building up as a problem gets worse.
- Electrical signals expose motor and load problems that the mechanical readings can miss.
Think of these as layers of protection. When the layers overlap, one signal’s blind spot is covered by another, and a fault confirmed by two signals is far more believable than an alert from one.
Signals are only half the story. What matters just as much is the model that interprets them. A model built on lab data or simulated faults can look sharp in a demo and still miss what failure looks like on a real production line. Ask what data the models learned from, and how many confirmed failures back them.
The basics still matter too. A system that reads well on a datasheet can still miss the asset in the back corner with no signal, or go quiet when a battery dies.
What to require:
- Visibility into sensor health: connectivity, battery status, and data gaps, all visible without anyone opening a support ticket
- Sampling and analysis suited to your equipment (low-speed, variable-speed, intermittent duty)
- Hazardous-area certification where you need it
- Reliable coverage under your real operating states, not just at full load
- Coverage beyond vibration: multimodal monitoring that combines vibration with ultrasound, temperature and electrical signals, so assets a single signal can’t read are still covered
Pilot test: Before kickoff, ask the vendor for confirmed-failure counts on the asset types in your pilot. During the pilot, track three things for every asset:
- Data completeness: the percentage of expected readings that actually arrived
- Sensor-fault visibility: how quickly your team can see that a sensor has a problem
- Alert quality: which signals triggered each alert, and whether a technician confirmed the fault on inspection
Field-check at least one asset in each operating condition.
2. Automated diagnosis, not just threshold alarms
Why it matters: An alert isn't a diagnosis. Several teams described the same pattern. A vibration or temperature threshold trips, the alarm shows no root cause, and a technician has to go verify it by hand. One food and ingredients manufacturer said their people still review data and create work orders manually after every alert. One building materials producer described monthly handheld routes, a week-long wait for third-party analysis, and false alarms that each needed a second look.
That isn't monitoring that saves labor. It moves the labor somewhere else.
This is where the “AI” in AI predictive maintenance software has to show up: in a diagnosis your technician can act on, not in the sales deck
What to require: Every actionable alert should contain:
- The affected component (e.g., "drive-end bearing," not "Motor 4")
- The evidence (the signal or pattern behind the call)
- Severity
- A recommended action
- A time-to-respond window
Pilot test: Score every alert during the pilot on those five elements. Then track how many findings were confirmed in the field when a technician inspected the asset.
3. A false-alarm rate you can live with
Why it matters: Nuisance alerts are the fastest way to kill adoption. Once technicians stop trusting the alerts, they stop responding, and the system becomes another dashboard nobody opens. This is what we call alert fatigue. One metals processor defined pilot success partly as limited nuisance alarms.
What to require:
- Baselines built per operating state, so normal load changes don't trigger alerts
- Adjustable criticality and sensitivity settings per asset
- A feedback loop: when your team marks an alert as confirmed or not confirmed, the system should learn from it, and you should be able to see that it did
Pilot test: Track the share of alerts confirmed in the field versus dismissed, and how much review time each alert takes. Agree on an acceptable nuisance-alert threshold before the pilot starts.
4. No added headcount and no IT project
Why it matters: "We don't have people for another dashboard." Lean teams described duplicate routes, manual analysis, and uncertainty about how an insight becomes an assigned maintenance task. If the system needs a new analyst, a network project, or a parallel workflow, it adds work.
What to require:
- Deployment that doesn't depend on plant IT infrastructure or a lengthy network approval
- A clear path from alert → inspection → work order in your CMMS (e.g., SAP PM, IBM Maximo, or your current system)
- Ownership and escalation rules built into the workflow, not left to a spreadsheet
- Post-repair validation: the system should show whether the signal returned to normal after the fix
Pilot test: Walk at least one finding through the full loop: alert, assignment, inspection, work order, repair, and post-repair confirmation. Measure the hands-on time your team spent on it, and compare it to how that finding would have been handled before.
5. Support and adoption you can measure
Why it matters: Installation isn't the same as adoption. Teams in live deployments described friction around trusting alerts, configuring criticality, seeing when baselines were retrained, and closing out feedback properly. A building products manufacturer framed its first 60-90 days as the window for the vendor to prove both performance and service before committing to a full year.
What to require:
- Training for the people who will own findings, not just the person who signed the contract
- Visibility into baselines and when the system retrains them
- Defined support response times, and expert analysts available to explain findings
- A named vendor contact accountable for the pilot
Pilot test: Log every support request and its time to resolution. At day 90, ask the technicians, not just the managers, whether they trust the alerts.
What 90 days can prove, and what it can't
Be careful with any pitch that promises full ROI in 90 days. Buyers are skeptical, and they're right to be.
The maintenance leader at the metal castings manufacturer put it plainly:
"I'm not sure that 90 days would be an effective window… But… in 90 days, I'd definitely like to see a baseline established."
A metals processor running a longer, six-month pilot still separated technical and service evaluation from full realized ROI. Success for them meant solving consequential problems, few nuisance alarms, responsive support, and a price-to-value case they could defend. They didn't expect fully realized savings inside the pilot window.
Separate what you can measure now from what takes longer:
No failure during the pilot doesn't automatically mean failure, or success. If nothing broke in 90 days, that doesn't show the system works or that it doesn't. Judge the pilot on the capabilities it demonstrated and how well the workflow performed, and write down which longer-term outcomes are still unproven.
A 90-day evaluation plan
Agree on acceptance criteria before day 1. Several evaluations we've seen named a 90-day timeframe without writing down what success meant. That's how a pilot ends with "it seemed fine" and no decision.
Build a business case leadership will believe
Leadership wants credible cost assumptions and documented impact. The quickest way to lose credibility is to blend what you observed with what you estimated.
Structure your proof-of-value scorecard in three clearly separated columns:
- Observed results. What happened: findings confirmed in the field, repairs made, time saved on routes or analysis, signal change after repair.
- Estimated avoided costs. What those findings would likely have cost if missed, based on your plant's downtime cost and repair history.
- Assumptions. Every number behind column 2, written out so finance can challenge it.
Also keep the scope tight. Buyers in our conversations pushed back when a pilot grew to cover problems they didn't have. Solve the problem you started with, then expand.
Required capabilities and metrics at a glance
Already have condition monitoring and still drowning in alerts?
If you're past the buying stage and your current system generates more noise than action, the problem usually isn't sensor coverage. It's the gap between an alert and a completed repair. Read The Alert-to-Action Problem to see where that gap opens and how to close it.
Go further: not all AI delivers action
Every vendor says "AI" now. Few can show how their AI turns a signal into a decision a technician can act on. Read Action vs. Noise: Why Not All AI in Manufacturing Delivers for the questions that separate real diagnostics from rebranded thresholds.
Who has done this?
These teams put the requirements above to the test on their own equipment.
Tate & Lyle: continuous monitoring catches what monthly PMs missed At its San Diego facility, Tate & Lyle ran monthly PMs and manual inspections and still had unexpected breakdowns. A single fermenter agitator failure could stop production for three to four days. After the team put continuous condition monitoring on more than 280 critical assets, early warnings replaced surprise failures, including a major unbalance on a dryer bearing. The results were 84 hours of downtime avoided and $446.9K in total savings. Read how the team moved from calendar-based PMs to condition-based decisions.
Cadillac Casting: a lean foundry team stops missing failures A 280,000 sq ft foundry with about 500 assets already had sensors, manual routes, and outside analysts, and failures still got missed. Shortly after installation, the platform flagged bearing wear and declining lubrication on a 200 HP motor. The team swapped the motor over a weekend, and the teardown confirmed a locked bearing. At go-live, a lubrication alert on a shakeout motor was fixed on the spot, and the team watched the asset's health status return to green.
Pirelli: from "sensors deployed" to a program that sticks Sensors connect over 4G/LTE, so there's no Wi-Fi or IT infrastructure to manage. Tractian helped define who owns the platform, trained key users, and held weekly alignment meetings. The result: a 98% alert check-in rate and 77 failures identified across the asset base.