What is a predictive maintenance work order?

A predictive maintenance work order is a maintenance task triggered by real-time asset-condition data instead of a schedule or a breakdown. When a sensor reading crosses a set threshold (vibration, temperature, run-time, current, or pressure), the system opens a work order automatically and assigns it before the equipment quits.

Define the terms once, because they get mixed up constantly:

Think of predictive as the fifth work-order type. The full breakdown of work-order types names five common triggers: reactive (breakdown), preventive (calendar or meter), predictive (sensor or condition), inspection-driven (audit finding), and request-driven (a QR or user-submitted request).

Predictive is the only one where the machine, not a person and not a clock, opens the ticket.

The sensor-to-ticket loop is well documented. Per FTMaintenance, predictive maintenance uses sensors and specialized software to detect when machine faults develop. eMaint frames the same loop: sensors capture condition, data transmits to the CMMS, alert rules fire, and a work order is created and assigned. That last step, the assign-and-close part, is exactly where Xenia lives.

Workflow diagram, submission to resolution

Here is a predictive-maintenance work order from the moment the sensor trips to the moment the ticket closes with proof. The critical framing: step 1 happens outside Xenia on the sensor or CMMS platform. Xenia owns steps 2 through 6.

1. A sensor detects a condition breach. A vibration, temperature, run-time, current, or pressure sensor on the asset reads a value past its threshold. This detection and any forecasting happens on the sensor, IoT, or CMMS platform, not in Xenia.
2. The alert fires into Xenia. The condition alert lands in Xenia and opens a work order automatically. Asset tag, location, and category pre-populate from the alert payload, so nobody retypes what the sensor already knows.
3. Xenia assigns severity and auto-routes. The work order gets tagged by severity (low, medium, high, critical) and auto-routed by region, priority, and skill. A high-severity compressor alert routes to the area refrigeration tech and copies the DM.
4. The technician receives, diagnoses, and documents. The assignee gets the ticket with the sensor context attached. Follow-up questions and required photo capture record what was found and what was done, at the moment of work, not from memory the next morning.
5. The corrective action tracks to closure. The task carries an assignee, a deadline, and an escalation rule. If it is not closed by the deadline, it escalates up the chain, from tech to DM to Regional. Xenia's corrective action workflow is the same engine that closes breakdown tickets, so ops teams already know it.
6. The loop closes with photo-verified proof. Closure requires the completion evidence. The alert record and the closure record are the same record. That is the audit trail when the next inspection or the insurer asks whether the issue was addressed.

For a C-store DM running forecourts across a region, the value is not the alert. It is what happens after. A pump attendant or area tech submits and works the ticket, the request routes to the area tech by region and notifies the DM, and the fix is documented with a photo before the ticket can close. Nothing dies in a text thread at 11pm.

Compact version for quick reference: sensor threshold breach (external platform) to alert into Xenia to auto-created work order (asset and severity pre-filled) to auto-route by region, priority, and skill to technician documents with photo to corrective action to closure with escalation to photo-verified close.

Predictive vs. preventive: sensor-triggered vs. calendar-triggered

Preventive maintenance runs on a fixed schedule or usage interval (every 90 days, every 500 run-hours). Predictive maintenance runs only when live sensor data says failure is coming. Preventive is calendar-triggered. Predictive is condition-triggered.

The sourced definitions line up. MachineMetrics frames preventive as any work done on a regular schedule and predictive as work performed on an as-needed basis. IBM frames it the same way: preventive is time or interval based, predictive uses real-time condition data to intervene only when needed.

Predictive is also distinct from reactive, or run-to-failure maintenance, where you fix it after it breaks. For the calendar-triggered counterpart, see how to build a preventive maintenance cadence that does not over-service.

| Attribute | Reactive | Preventive | Predictive |
|---|---|---|---|
| Trigger | Breakdown, after failure | Calendar or meter interval | Sensor condition breach, before failure |
| Who opens the work order | A person, after it breaks | The schedule, on a set date | The sensor, on a threshold |
| Cost profile | Highest per event, unplanned | Moderate, can over-service | High upfront on sensors, lowest per failure |
| Best for | Low-value, non-critical assets | Predictable wear, low failure impact | Critical, high-downtime-cost assets |
| Xenia's role | Route and close the ticket | Schedule, route, and close | Receive the alert, route, and close |

Notice the last row. For every trigger type, Xenia's job is the same: the routing and closure layer. The only thing that changes across the row is what opens the ticket. Reactive work orders start with a person, preventive starts with a date, predictive starts with a sensor.

How does Xenia's approach differ from a full CMMS?

A full CMMS can ingest sensor data, run condition rules, and in some cases model failure. Xenia does not run that analytics layer. Xenia is the frontline layer that turns the alert into an assigned, photo-verified, escalating work order and closes the loop. Many operators run both: the CMMS or sensor platform detects, and Xenia routes and resolves.

Here is the honest read on the analytics vendors. Limble connects IoT sensors through an open API and a Monnit sensor partnership, and automatically creates a predefined task or alert whenever a critical event happens, such as a motor starting to fail.

That IoT sensor integration sits on Limble's Enterprise plan on a custom quote. UpKeep positions its CMMS to support both simple PM scheduling and predictive IoT-connected maintenance.

Tractian and eMaint lead with condition-monitoring hardware plus software as an integrated PdM stack. Those vendors sell the prediction. That is real, and it is not what Xenia claims to do. If you want the deeper head-to-head, see Xenia vs. Limble and the roundup of predictive maintenance software.

| Capability | Full CMMS (Limble, UpKeep, Tractian) | Xenia |
|---|---|---|
| Generate the sensor alert or run analytics | Yes (ingest, threshold rules, some ML) | No, receives the alert |
| Vibration, thermal, or oil analysis | Yes | No |
| Parts inventory, depreciation, vendor invoicing | Yes | No |
| Auto-create work order from an inbound alert | Yes | Yes |
| Auto-route by region, priority, and skill | Varies | Yes |
| Photo-verified closure with deadline escalation | Varies | Yes, core strength |
| Audits, daily ops, and team comms in one app | No | Yes |
| Pricing model | Sensor and IoT often Enterprise-tier gated | Flat per-location |

The plain-English split: a CMMS is the right tool if you are a facilities engineer running deep parts inventory and asset-lifecycle tracking across a portfolio. Xenia is the right tool if you are a multi-unit ops director who needs work orders, audits, daily ops, and comms in one app.

Some customers run both. Refuel did exactly that: it kept its Service Channel integration and added Xenia for frontline ops rather than ripping either out.

On cost, Xenia charges a flat per-location rate rather than gating IoT behind an enterprise tier, so a 60-store chain is not penalized on user count as it grows. For the definitional groundwork, see what a CMMS is.

Where do operators see results?

Operators see results in three places: less unplanned downtime, faster time-to-dispatch once an alert fires, and a closed-loop audit trail proving the issue was handled. The analytics platform predicts. Xenia is where the prediction becomes a resolved ticket instead of a missed email.

The honest sensor-integration proof point is H&S Energy, a C-store operator running continuous Bluetooth and LoRaWAN sensor deployment across 360-plus stores. The sensors watch the coolers around the clock.

When a reading drifts, the alert becomes a routed, photo-verified work order in Xenia rather than a phone call at 11pm. That is the pattern: the hardware does the watching, Xenia does the resolving.

For the routing-speed side of the equation, Power Market went live across 360 locations with QR-based work-request deployment and reports 40% faster task resolution. That is a routing-and-closure number, not a downtime-forecast number. It measures how fast a ticket moves once it exists, which is the exact slice of the problem Xenia owns.

The market context justifies the whole trigger type. Deloitte reports that predictive maintenance can cut maintenance planning time by 20 to 50 percent, raise equipment uptime by 10 to 20 percent, and lower overall maintenance costs by 5 to 10 percent, against an estimated $50 billion a year that unplanned downtime costs industrial manufacturers. Read those numbers honestly.

Xenia does not produce those percentages by itself. The sensor platform earns the downtime reduction. Xenia earns the part where the alert actually turns into a completed repair with proof attached.

Track two operator KPIs to see the effect: mean time between failure (MTBF) and mean time to repair (MTTR). Predictive triggers push MTBF up by catching faults early. A tight routing-and-closure loop pushes MTTR down by getting the right tech on the ticket fast. For the full metric set, see the guide to maintenance KPIs and work-order metrics, the broader work orders hub, and how this plays out for convenience store operations.

How to route a predictive-maintenance alert to a work order in Xenia

In Xenia, you connect the sensor or CMMS alert to a work-order rule, map the asset and severity, set the routing path, and define the closure requirements. Xenia does not generate the reading. It acts on it. Here is the setup, start to finish:

The temperature case is where this crosses into food safety. A Bluetooth thermometer logging a walk-in cooler that drifts out of range is an early condition signal. In Xenia, cooler and hot-hold temps log automatically and the platform auto-alerts on out-of-range readings.

One drifting reading can trigger two things at once: a food-safety corrective action for the product and an equipment work order for the failing compressor. Be clear on the boundary, though. Xenia auto-logs the temp and fires the alert. It does not forecast the compressor's remaining life.