Condition monitoring → work orders

Your sensor flagged it. Who opened the work order?

The vibration trend crossed its limit on Tuesday. Someone saw it on a dashboard. Someone mentioned it in the morning meeting. By Friday the bearing had failed, and the alert was still sitting there, acknowledged and unowned.

If that scenario feels familiar, the problem probably wasn't the sensor. The reading was right. The limit was right. Someone even noticed. What failed was the hand-off between "we know about this" and "someone is responsible for doing something about it, by a date, and will record what they found."

This article is for maintenance managers, reliability engineers and planners who already have some form of condition monitoring, inspections or audits producing findings, and who suspect that a share of those findings never turn into planned work. We'll look at where the hand-off breaks, a simple way to audit it on your own site this week, and what a disciplined alert-to-work-order flow looks like when a human stays in control of every decision.

Detection is rarely the weak link

Plants spend a lot of effort on detection: vibration routes, oil analysis, thermography, online sensors, operator rounds, failure-mode reviews. Each one produces findings. But a finding on its own changes nothing on the floor. It only matters when it becomes a decision, and in most maintenance organisations the vehicle for a decision is the work order.

Between the finding and the work order there are several small steps, and each one is a place where things quietly drop:

• Notify. The alert reaches a screen or inbox. Does it reach a person who can act on it?
• Qualify. Is it real, a sensor fault, or a known condition already being watched?
• Triage. Create work now, watch with a review date, gather more data, or decline with a reason?
• Plan. Parts, labour, permits, a window in the schedule.
• Execute and close. Was the work done, and was the as-found condition recorded?

Every one of those steps can be "sort of" done. An alert can be acknowledged without being triaged. A finding can be discussed without being assigned. A work order can be closed without saying what was found. None of these show up as a failure until the asset fails.

Why acknowledged is not the same as owned

Most monitoring tools let someone acknowledge an alarm. That is useful: it stops the same alert nagging everyone. But acknowledgement records that a person saw something. It doesn't record what they decided, who now owns it, or when it will be looked at again.

Ownership needs three things on the record:

1. A disposition. Every finding should end in one traceable outcome: a work request or order, a watch with a review date, a request for further diagnostics, or a documented no-action with a reason. "We'll keep an eye on it" is not a disposition unless it has a date and a name.
2. A named owner. A person, not a team mailbox or a shift.
3. A closure with evidence. What was found when someone opened it up, so the next alert on that asset can be judged against history.

Findings also come from more places than sensors. A failure-mode review flags a weak point. An inspection notes a cracked bund. An audit raises an action. These are often worse off than sensor alerts, because they live in a spreadsheet, a PDF report or someone's notebook, with no system that will nag anyone at all.

Should alerts create work orders automatically?

It is tempting to fix the gap by wiring every out-of-limit reading straight into a new work order. In practice, most reliability practitioners advise against it. Raw alerts include sensor faults, duplicates, transient spikes and conditions already being managed. Auto-creating work orders from all of them floods the backlog, and a flooded backlog is ignored just as reliably as an unowned alert.

The more robust pattern is: an alert opens a request with the evidence attached, and a planner or reliability engineer decides what it becomes. The decision is fast, it is recorded, and nothing disappears silently. Automation does the gathering and the chasing. A person does the judging.

What a disciplined alert-to-work-order flow looks like

You don't need new sensors to close this gap. You need a consistent path for findings, wherever they come from:

1. One intake. Sensor alerts, inspection findings and review actions land in the same queue, against the asset they concern.
2. Evidence travels with the finding. The trend, the photo, the reading, the inspector's note. The planner should not have to go hunting.
3. Three-way triage. Create work, watch with a review date, or decline with a reason. Each choice is recorded with a name and timestamp.
4. Watches come back. A "watch" is only safe if the review date actually resurfaces the item to its owner.
5. Close-out captures as-found. The technician records what was actually found, so the original finding can be confirmed or corrected.
6. Review the register. In the weekly or monthly reliability meeting, look at findings without a disposition, not just open work orders.

That last point matters. Most backlog reviews look at work orders that exist. The dangerous items are the findings that never became one.

Where Oxmaint AI fits

Oxmaint AI works alongside the CMMS or EAM you already run. It is not a replacement for your condition monitoring, and it doesn't claim to know better than your planners.

What we're building (Preview): a finding, whether from a condition alert, an inspection or a review action, becomes a draft work request with the evidence attached. A planner decides to create, watch or decline it, and that decision is recorded. Watches resurface on their review date. Nothing quietly disappears, and a person still reviews and signs every record.

The aim is to make the hand-off boring and visible: every finding has a disposition, every disposition has a name, and every closed job says what was found.

Questions to ask any tool you evaluate

Whether you look at Oxmaint AI or anything else, these questions separate a real alert-to-work-order flow from a dashboard with notifications:

• Can findings from inspections and reviews enter the same queue as sensor alerts?
• Does the planner see the evidence without leaving the request?
• Is "watch" a first-class outcome with a review date, or just a status nobody revisits?
• Is every decision recorded with who made it and why?
• Does it work with your existing CMMS or EAM, or does it ask you to move?
• Does a human approve each work order, or does the system create them on its own?

If the answer to the last question is "the system decides", ask how it handles sensor faults and duplicates, and who cleans up the backlog afterwards.

Start with your own findings

The quickest way to see whether you have a hand-off gap is the ten-findings exercise above. If you find more "no" answers than you expected, you're not alone, and you don't need a large project to fix it. You need one intake, a three-way triage with a name on every decision, and a close-out that records what was found.

If you'd like to test that flow on your own findings list, read on below. You stay in control of every work order.