What Is a Work Order and What Should It Include?

A work order is a documented instruction to carry out a specific piece of maintenance: what needs fixing, on which asset, who's assigned, and by when. It's the record that turns a reported problem into tracked, assignable, billable work, and it carries a job from the moment someone logs it to the moment the fix is verified and closed. Every CMMS is built around it. But the document is only half the story.

Ask a coordinator "where's my job?" and watch what happens. They open the CMMS, then a WhatsApp thread, then their email, then they phone the contractor. The status on screen says Assigned. The truth is spread across four other places, and closing that gap is what this post is really about.

What a work order actually is

Every CMMS vendor will tell you a work order is a document that authorizes and records maintenance. That's true, and it's the easy half. A work order names a task, ties it to an asset and a location, assigns someone, sets a deadline, and holds the trail of what got done. Created, worked, closed. If that were the whole job, a spreadsheet would run maintenance.

Here's the position most definitions miss: a work order isn't the document. It's the coordination that happens between its statuses, and most of that coordination never touches the system the document lives in. The CMMS records that a job moved from Assigned to Resolved. It does not record the six phone calls, the chased acknowledgment, and the contractor who promised "tomorrow" three times that actually moved it there.

That split has a name in how modern FM systems are built. There are two rails. Your CMMS is the system of record, holding the states. Everything between those states is the system of work. A work order is really the second rail wearing the clothes of the first.

You see the split most clearly in a status query. When a facilities manager asks a coordinator for an update, the honest answer isn't in the CMMS field; it's reconstructed on the spot from a text thread, a half-remembered call, and a contractor's last email. The record says Assigned. The coordinator's head holds the real state. Multiply that across a portfolio and you understand why nobody fully trusts the dashboard, why SLAs surprise people, and why the same fault can get paid for twice. The document didn't fail. The work between the documents was never captured.

What should a work order include?

Ask ten teams for their work order template and you'll get ten layouts. But the fields themselves are stable across grocery retail, higher ed, and healthcare. What changes is who fills each one in and when, which is the part a template never shows you. A field that nobody owns is a field that stays empty.

Here's what belongs on a work order, plus the two questions that matter more than the field name: who captures it, and at which point in the job.

Two rows there do most of the damage when they get skipped. Problem and resolution codes turn a closed job into data you can trust for a repair-versus-replace call later; skip them and you're left with a paper trail that proves a job happened but not what was wrong with the asset. Verification is the other one, and it's worth its own section.

This is why a work order template is worth building even though the fields look obvious. A good template isn't a form; it's an assignment of responsibility. It says the requester owns the description, the coordinator owns the priority and the asset link, the technician owns the labor and the resolution code, and the verifier owns the sign-off. Get that ownership map right and the record fills itself as the job moves. Get it wrong and you end up with the thing every FM leader complains about: a CMMS full of jobs marked done with no record of what was actually wrong.

A few of these fields also carry legal weight, which surprises people. Once a work order states scope and price and gets signed off, it can function as an enforceable contract, not just an internal task. That's worth knowing before you treat the description and cost fields as busywork.

Reactive, planned, and inspection work orders

Work orders come in a few flavors, and the type sets everything downstream. A reactive work order chases a fault that already happened: a leaking valve, a dead compressor, a stuck door. A planned or preventive work order is scheduled ahead of failure, generated on a calendar or a meter reading, and it's the backbone of any PPM program. An inspection work order captures condition rather than fixing anything, and it often spawns reactive jobs when it finds a problem. There are corrective and emergency variants too, but the split that matters operationally is planned versus reactive, because reactive work is where the coordination cost hides.

Planned work is predictable, so it's cheap to coordinate: the asset, the task, and the schedule are all known before anyone starts. Reactive work is the opposite. Nobody knows the asset condition, the right trade, or the true urgency until someone investigates, which is exactly why the coordination tax falls almost entirely on reactive jobs. A work order template earns its keep most here, because reactive intake is where fields get skipped under time pressure.

The work order lifecycle, from created to closed

Strip away the vendor-specific labels and every work order runs the same lean lifecycle: Created → Assigned → Work In Progress (+ On Hold / Made Safe sub-states) → Resolved → Closed. Five states, two sub-states, and it maps cleanly onto MaintainX, Limble, Maximo, or a paper clipboard.

The states are the easy part. Any system can flip a status. The hard part is what the lifecycle diagram never draws: the work between those statuses, which lives in inboxes, phones, spreadsheets, and coordinators' heads. Created to Assigned means someone triaged the priority, matched the skill, and confirmed the contractor was covered and compliant. Assigned to Work In Progress means someone chased an acknowledgment, booked access, and got a named engineer to actually show up. None of that is a status. All of it is the job.

The sub-states are where honest teams live. On Hold with a reason code says a job is waiting on a part, an access window, or an approval, and it stops the SLA clock from lying. Made Safe is the one people forget: a temporary fix that removes the danger but isn't the permanent repair. Mark a job Made Safe and Resolved as if they're the same thing and you've quietly closed a fault that's still there, waiting to come back as a duplicate. The sub-states aren't bureaucracy. They're how you keep the record honest between the big transitions.

Price it out and the scale gets uncomfortable. Coordination runs thirty to forty minutes per reactive job once you count the triage, the chasing, and the write-up. A single mid-size site closing two hundred reactive work orders a month is burning close to three full working weeks on coordination alone, before a wrench turns. That's not technician time. That's the coordinator's, and it scales almost linearly with volume until outsourcing starts to look cheap. It's the mechanism behind why FM helpdesks become bottlenecks.

The void between Resolved and Closed

Watch where work orders actually die and it isn't in the middle. It's at the end. The void between Resolved and Closed — verification, reports, learning — is where today's systems track nothing.

Resolved means the technician says they're done. Closed should mean someone confirmed it. In practice, 80 to 90% of requesters never verify a completed job, and around 90% of contractor engineers skip the full CMMS process, so the service report gets chased days after the visit. The status reads Closed. Whether the fault is actually fixed stays a guess until it comes back.

The money angle sharpens it. A recall — a job that comes back because the first fix didn't hold — costs roughly what the original work order cost, and most maintenance contracts never recover that from the party responsible. So unverified closure isn't just messy data. It's paying twice for the same fault and calling it two separate jobs.

This is also where duplicate work orders breed. A job marked Resolved but never verified returns as a fresh complaint, gets logged again, and now one fault wears two work order numbers. In our interviews with multi-site FM leaders, duplicate logging ran around 5 to 10% at intake, and unverified closure is one reason why. Closing the loop, verified completion instead of claimed completion, is the difference between a record and a rumor. Our companion piece on closed-loop coordination goes deeper on the mechanics.

What is work order management?

Work order management is the practice of moving jobs through that lifecycle without letting them stall between states. Not the software, the practice. Good work order management gets measured at the seams: how fast a request is triaged, whether the right resource showed up first time, and whether the job that reads Closed was genuinely verified.

The metrics that actually tell you whether work order management is working all sit at those seams, not inside the states. Time-to-triage measures the Created-to-Assigned gap. First-time fix rate measures whether Assigned-to-Resolved was done right. Verification rate measures whether Resolved-to-Closed meant anything at all. A team can hit its SLA on paper and still be drowning, because SLA compliance usually gets measured at Resolved and the void after it goes unwatched.

Put it simply: the software manages states, and people still manage the work between them. Work order management is the name for that human labor, and it's the single biggest cost center hiding inside a maintenance operation that looks, on the dashboard, completely under control.

The trap is assuming the CMMS does this for you. It records the states beautifully. It does not do the work between them, so a person in a chair does, cross-referencing systems that don't talk, re-keying POs into finance by hand, chasing the report that proves a job is done. That's the manual middle, and it's why more teams now hand work order coordination to an AI helpdesk for facilities management rather than buy a bigger CMMS.

What it looks like when agents do the work between the states

Everything above holds whether or not you ever change a tool. But it points somewhere. At Heyfixit we put AI agents on that second rail, the system of work between a work order's statuses. The principle is simple: your work order states don't change; what changes is who does the work between them. The CMMS stays your record. The agents answer intake, triage the priority, chase the acknowledgment, verify the completion, and match the invoice, writing each step back to the work order as it happens.

The value lands where the manual middle used to sit. Coordination labor comes off human desks, completion gets verified instead of claimed, and the record is audit-ready because it was captured at source. One multi-site FM provider saved 60 staff-hours per week at 98% SLA compliance running exactly this.

Here's the honest boundary: we don't make the judgment calls. Agents assemble, compare, chase, and recommend; a human still approves the money, issues the quote, and owns every safety and liability decision. Judgment stays human, always. We're a coordination layer on top of the CMMS you already run, never a replacement for it. If the space between your work order statuses is where your team's week actually disappears, that's the part we take. See how the coordination layer works.

Cover image by Jeriden Villegas on Unsplash.

Vishak C Prakash

Co-Founder & CEO

Vishak spent six years as a digital transformation consultant to facilities management and real estate operators across the UK, Middle East, Canada, and Australia — working with teams at CBRE, Siemens UK, British Land, and Brookfield. He now runs Heyfixit, building AI agents for facilities management.

LinkedIn