Maintenance work order types classify each job by what triggered it and how it moves through the shop. The common set is preventive (scheduled service), corrective (a planned repair of a known defect), emergency (an unplanned breakdown needing immediate response), inspection (an assessment that produces information, not a repair), standing (a recurring blanket order for small routine work), and project (installs and improvements with a defined scope and budget). One field, six values, and it decides whether your maintenance data can answer any question at all.
Most plants have a type field in their system and treat it as a formality, something to pick from a dropdown and forget. That is a mistake. The type field is the axis every meaningful maintenance metric is built on: the proactive-versus-reactive ratio, cost by category, PM effectiveness, and the routing that sends an emergency straight to a technician while a project waits for approval. This guide covers each type, the difference between type and priority, and how to code the field so it earns its keep.
What are the main maintenance work order types?
Six types cover almost all maintenance work. They differ along two lines that matter: whether the work was planned (known and prepared in advance) and what triggered it.
Preventive (PM) work orders are scheduled service issued on a time or usage trigger, inspect, lubricate, adjust, replace, to catch wear before failure. They are the backbone of a PM schedule and should generate automatically from the schedule rather than being written by hand.
Corrective (CM) work orders repair a known defect. The crucial nuance: corrective work splits in two. A defect found during an inspection, with time to plan parts and schedule the fix, is planned corrective the good kind. The same defect discovered when the machine stops is reactive corrective the expensive kind. Same repair, very different cost, which is why corrective needs a planned flag alongside the type. The planned side is the subject of our corrective maintenance guide.
Emergency work orders respond to an unplanned breakdown that cannot wait, a down line, a safety hazard, a spill. They skip the normal queue and go straight to a technician. Emergencies are unavoidable in small numbers; a plant where they dominate the log is running reactively, whatever its PM schedule claims on paper.
Inspection work orders produce information, not repairs. A vibration route, an oil sample, a checklist walk, they find defects that become planned corrective jobs. Inspections are the engine that converts reactive corrective work into planned corrective work, which is why cutting them to save time is a false economy.
Standing (or blanket) work orders cover recurring small work that is not worth a fresh work order each time, routine housekeeping, minor running adjustments, jobs under a time threshold. They keep the system from drowning in five-minute tickets, but they are also where hours go to hide, so they need a labor cap and periodic review.
Project (or capital) work orders cover installs, relocations, and improvement work with a defined scope, budget, and often a separate approval path. Keeping project hours out of your routine maintenance numbers is essential; a big install booked as maintenance will wreck your cost-per-asset figures for the quarter.
Is work order type the same as priority?
No, and conflating them is the most common coding error. Type answers what kind of work is this; priority answers how soon must it happen. They are independent axes. A corrective job to replace a worn but functioning belt can be low priority. A PM on a critical asset can be high priority. An emergency is the one case where type and urgency are welded together, by definition it is urgent, but everywhere else the two fields move independently.
| Type | Planned? | Trigger | Example |
|---|---|---|---|
| Preventive (PM) | Yes | Time or usage interval | Quarterly gearbox inspection |
| Corrective, planned | Yes | Defect found on inspection | Replace bearing flagged by vibration route |
| Corrective, reactive | No | Defect found at failure | Replace bearing after it seized |
| Emergency | No | Unplanned breakdown / hazard | Down conveyor stopping the line |
| Inspection | Yes | Route or condition check | Monthly thermography sweep |
| Standing | Yes | Recurring small work | Weekly plant housekeeping round |
| Project | Yes | Approved scope | Install new palletizer |
Keep the fields separate in your system and you can slice work any way you need: all high-priority correctives, all reactive work regardless of urgency, all project hours to exclude from the maintenance budget. Collapse them into one field and every report becomes an argument.
Why does coding work order types matter?
Because the type field is the raw material for the metric that predicts everything else: the ratio of planned to unplanned work. The economics behind that ratio are well documented:
- High-performing maintenance organizations run roughly 85% planned work while reactive plants sit stuck at 40–50% and you can only compute that ratio if every work order is honestly coded as planned or reactive (Reliable Plant, Facts About Maintenance Wrench Time).
- Moving off a heavily reactive posture toward planned maintenance offers savings that can exceed 30–40% of maintenance cost (PNNL, O&M Best Practices: Maintenance Approaches), and honest type coding is how you prove you are actually making that shift rather than just claiming it.
- The technicians who do this work are getting scarcer: the U.S. Bureau of Labor Statistics projects 13% growth (2024–2034) and about 54,200 openings a year for industrial machinery mechanics and millwrights (BLS Occupational Outlook Handbook), so every reactive hour a clean type field helps you convert to planned is scarce capacity recovered.
Three things break when the coding is sloppy:
- The reactive ratio lies. If reactive corrective jobs get coded as plain corrective, or emergencies get quietly downgraded, your program looks healthier than it is and nobody fixes the real problem.
- Cost tracking blurs. Project hours booked as maintenance inflate your cost per asset; standing-order hours with no cap hide real labor. The type field is how you keep categories of spend from bleeding into each other.
- Workflow routing fails. Type is what tells the system to fast-track an emergency, hold a project for approval, and batch PMs into the weekly schedule. Without clean types, everything routes the same way, which means everything routes badly.
How do you set up a work order type scheme? 5 steps
A good scheme is small, unambiguous, and enforced at the point of entry. Build it like this.
- Keep the list short. Six or seven types cover almost everything. Every extra type is a coin-flip at data entry and a coding inconsistency later. If you cannot explain a type in one sentence, cut it.
- Add a planned flag separate from type. Because corrective work lives on both sides of the planned line, one boolean, was this prepared in advance?, does more for your reactive ratio than any number of type values. This single flag is the backbone of the whole scheme.
- Write one-line definitions and examples. Post them where work orders are opened. “Emergency = production is down or a safety hazard exists, right now” ends more coding arguments than a policy binder. Ambiguity at entry is what corrupts the data.
- Enforce it in the system, not by memory. Make type a required field, restrict who can code an emergency, and validate on close-out. A CMMS that requires and audits the type field beats a spreadsheet that trusts everyone to remember.
- Audit the mix monthly. Review the split of types and the planned ratio on your KPI dashboard. A sudden jump in emergencies or standing-order hours is usually a coding drift or a real reliability slide, either way you want to catch it in weeks, not at year-end.
How do work order types connect to the rest of maintenance?
Work order types are the vocabulary the rest of the maintenance system speaks. They record which maintenance strategy each asset is actually running, a run-to-failure asset shows only reactive correctives, a predictive asset shows inspections feeding planned correctives. They flow into planning and scheduling where planned types get prepared and loaded while emergencies break in. They determine what lands in the backlog and what counts toward schedule compliance. And they only stay clean if capture is easy at the machine: when technicians code and close work orders on a tablet at the point of work rather than reconstructing them on paper Friday afternoon, the type data stays honest. That shift, from paper logging to live capture, is what the CLS case study documents, and pulling the underlying work records into one place is the problem described on our platform overview. Coding is not bureaucracy; it is how a pile of finished jobs becomes a program you can steer, and it deserves a place on your reporting from day one.