See wear coming, order the part before the line stops.
Service Intelligence tracks each component's run-hours against its expected life, so you know which parts are near replacement and link that straight to your stock: what to order, and when, before the next planned stop. Rules-based on run-hours and replacement history, no black box.
Same foundation as Fleet Performance · built on run-hours from telemetry · your service team reviews and decides.
See it in action.
A wear-part forecast and spare-part view, running on sample data. The same layout runs on your fleet's actual run-hours.
This is one example view, on synthetic data. On the same governed foundation we shape it to your components, your stock locations and your roles, so a different layout is a configuration, not a rebuild.
You're looking at one view of it.
Everything here runs on the same governed data foundation. Build the views you need now, and the ones you need later, on top of it.
Fleet Performance
OEE, alarms and uptime for your team
Customer Service Portal
White-label, for your customers
Service Intelligence
Wear parts, stock & reorder
Your own view
Shaped to your KPIs, no rebuild
Built once, shaped to you. Because every view runs on one governed foundation, a different view, or a new one next year, is a configuration, not a rebuild.
From run-hours to a part on the shelf.
At a glance: what Service Intelligence does, and how it turns wear into planned aftermarket work instead of breakdowns.
Component life on run-hours
Every wear part's actual run-hours, tracked against its expected lifetime, so you see which components are near the end before they fail.
AI sharpens the estimate
On top of the spec, an optional Activate layer learns from how similar components actually wear in your fleet, and proposes an adjusted remaining life with its reasoning. Your engineer accepts or corrects, and every replacement makes it sharper.
Inventory linked to the forecast
The forecast checks against your stock levels and flags shortfalls: what to order, how many, and by when, so the part is on the shelf for the next planned stop.
Aftermarket you can plan
Parts demand and replacement work mapped across the coming weeks, so service visits and orders are scheduled instead of scrambled, and your aftermarket becomes predictable.
Alarm root-cause across the fleet
Which alarms recur, on which machines, and what sits behind them. Patterns over the whole fleet tell you where to fix the cause, not just clear the symptom.
Diagnostic cockpit for engineers
One remote view per machine: live state, recent alarms, fault sequence and component health, so your engineers diagnose before they drive, and arrive with the right part.
Three deterministic inputs. No black box.
The replacement window is calculated, not predicted. Rules over run-hours, not a machine-learning guess.
One data foundation, two uses. The run-hours that drive your Fleet Performance dashboards also open the replacement window here.
Track run-hours
Actual run-hours per component come from machine telemetry on the foundation you already run, mapped to the right part on the right machine.
Compare to expected life
Run-hours are compared against the component's expected lifetime, from manufacturer specs and your own historical replacement intervals. When it nears the threshold, a replacement window opens.
Plan the order and the visit
The window is checked against your stock, and your aftermarket lead decides on order timing and the service slot, before the next planned stop.
Expected life is an average with spread; use varies with load, product and environment. Run-hours is the first layer; the engineer always decides.
The people behind the forecast.
StriData was built by industrial data practitioners who got tired of two things: dashboards no one acts on, and machine data that stays stuck in the gateway. We work where operational reality meets business outcomes, one foot in IT and one on the floor.
For wear and aftermarket we are deliberately honest: we count run-hours against expected life, we do not promise to predict the exact moment of failure. The engineer stays in control.
“A part that runs 1,847 of 2,000 hours is a planning decision, not a crystal ball. We give you the number, you make the call.”
Questions machine builders ask us.
What if this view isn't exactly what we need?
That's the point. What you see is one example. Because it runs on a governed data foundation, a different view is a configuration, not a rebuild: we reshape the components, thresholds, stock locations and layout to your reality without touching the plumbing underneath. The modules show what's possible; your version is shaped in the Quick Scan.
Is this predictive maintenance with machine learning?
The base is rules-based, not a black box: a replacement window calculated from three deterministic inputs, actual run-hours from telemetry, your historical replacement intervals, and manufacturer-specified expected lifetime. On top of that, an optional Activate layer uses AI to learn from how similar components actually wear in your fleet and proposes an adjusted remaining life with its reasoning. It is a proposal, never an automatic decision: your engineer accepts or corrects it, and the model learns from each replacement. So you get a solid rules-based floor, with AI sharpening the estimate where it helps, always human-validated.
Where does "expected life" come from, and how reliable is it?
From manufacturer specifications combined with your own replacement history on the same component across the fleet. It is an average with spread: real life varies with load, product and environment. Run-hours is a strong first layer; load and cycle data can be added later to refine it. We are clear that it is a planning signal, not a guarantee.
Does it order parts automatically?
No. It proposes what to order, how many and by when. Your aftermarket lead reviews and places the order through your own system. We surface the decision; we do not take it for you, and we do not own your stock or invoicing.
Does it connect to our inventory or ERP?
It reads stock levels to compare them against the forecast, and links out to your purchasing or ERP for the actual order. The depth of that integration is a scoping choice: from a read-only stock view with manual ordering, up to a deeper link, depending on what your systems allow.
What data do we need to make this work?
Run-hours per machine from telemetry, a mapping of components to machines, your replacement history where available, and current stock levels for the relevant parts. Most of this sits on the same Fleet Performance foundation; the Quick Scan establishes what is present and what is missing.