Work Order Software for Maintenance Teams

Almost every maintenance system I have been asked to review has a work order module, and almost every one of them is used at about forty percent of its capability. Work orders get raised, work gets done, work orders get closed. What does not happen is the part that makes the record worth keeping: labour hours against the right asset, parts consumed, a failure code that says what was actually wrong, a meter reading, a photograph of the condition found, and a follow-up work order when the fix was temporary. Without those, you have an activity log. With them, you have the data that drives planning, budgeting, reliability improvement and every credible KPI you will ever be asked for. The difference is not the software. It is the lifecycle discipline wrapped around it.

The message up front: work order software is easy to buy and hard to operate well. The states people skip (screening, planning, review) are precisely the states that create the value, and the fields people leave blank at closure are precisely the fields your reporting depends on. Before you shortlist a platform, decide what a complete work order record must contain in your operation, then buy the tool that enforces it.

1. Why the work order is the unit of work

A work order is a single instruction to do a defined piece of work on a defined asset or location, with an owner, a priority, a planned scope and a record of what happened. That sounds obvious, but the implication is not: if the work order is the unit of work, then every number your organisation reports about maintenance is an aggregation of work order records. Maintenance cost per asset is the sum of labour and parts on its work orders. Schedule compliance is a count of work orders completed in window. Mean time to repair is the elapsed time between two timestamps on a work order. Backlog is the population of open work orders weighted by estimated hours.

This is why I push back hard when a client wants to "keep it simple" by letting technicians record work in a spreadsheet or by closing work orders with a single free-text comment. You are not simplifying the process, you are deleting the data layer that every downstream decision rests on. Six months later the same organisation asks why it cannot justify its maintenance budget or explain why the same chiller keeps failing, and the answer is in the two thousand work orders closed with the word "done".

If you are earlier in the journey and still working out how work orders sit inside the wider system, the complete CMMS buyer's introduction gives the overall frame, and core modules explained shows how work order management connects to assets, inventory, procurement and planning.

2. The work order lifecycle, state by state

Most platforms ship with a status list of five or six values. Most real operations need eight to eleven, because the states that get collapsed are the ones that carry the control. Here is the full lifecycle I would design for a mid-size to large maintenance operation, with an honest note on which states get skipped in practice and what that costs.

Look at the "commonly skipped" column and you can predict the symptoms an operation will have. Skip screening and you get duplicate work orders, wrong-trade dispatch and a priority distribution where everything is urgent. Skip planning and technicians arrive without parts, which is the single largest source of wasted wrench time I encounter. Collapse "ready or waiting" into a generic open status and your backlog stops telling you anything, because work genuinely blocked on a spare part looks identical to work nobody has touched. Skip review and failure coding quality collapses within a quarter, because nobody is checking.

3. What a well-formed work order contains

There is a difference between the fields a work order form offers and the fields a work order must carry to be useful. Below is the record I would define as complete for a maintenance operation that intends to do reliability analysis, cost accounting and compliance reporting from its own data. The right-hand column is the honest reason each item exists, because a field with no downstream consumer will not survive contact with a busy technician.

Two practical notes. First, do not make all of this mandatory on every work order type. A five-minute lamp replacement does not need a job plan or a permit reference, and forcing the full record on trivial work is how you teach technicians to enter rubbish to get past validation. Make the mandatory set conditional on work order type and priority. Second, failure coding deserves its own design effort rather than a free-text box; the Problem, Cause, Action structure in the failure codes pillar is the version I would implement, with short pick lists scoped per asset class.

4. Intake channels and the triage decision

Work orders enter the system from a handful of distinct sources, and each source needs a different amount of screening before it becomes an executable work order:

• Human requests from occupants, operators or tenants, via portal, app, email, phone or a walk-up to the help desk. Highest volume, lowest average quality, needs the most screening.
• Preventive maintenance generation from the PM scheduler on date or meter triggers. Pre-planned by definition, so it should arrive with a job plan, estimated hours and parts already attached.
• Inspection and round findings raised by technicians during routine work. Usually good quality because a technician wrote them, and often the most valuable source of early intervention.
• Condition and system alarms from BMS, SCADA or IoT sensors. Needs a threshold and de-bounce discipline, or the system floods with alarm-generated work orders nobody trusts.
• Projects, compliance and statutory programmes pushed in from a separate plan. Needs distinct work order types so it does not distort routine maintenance reporting.

Triage is the decision that turns a request into a work order, and there are only four legitimate outcomes: convert to a work order with type, trade and priority set; merge into an existing work order as a duplicate; redirect because it belongs to another function such as IT, security or projects; or reject with a reason the requester can see. The channels and requester experience are a subject in their own right, and I would treat them separately: the requester-facing side is covered in maintenance request and work request portals, and the rules-based side, routing and auto-assignment, in automating work order intake and triage. The classification scheme itself, the work order types and how many you should have, is in work order types in a CMMS.

5. Priority and SLA assignment

Priority is the field most consistently abused in maintenance software, because requesters set it and requesters are not neutral. Left to self-service, the distribution collapses toward urgent and the field becomes noise. Two design decisions fix this.

First, derive priority rather than letting anyone type it in. The defensible calculation is a matrix of asset criticality against the severity of the reported condition, so a minor fault on a critical asset and a total failure on a non-critical asset can be ranked against each other with a rule rather than an opinion. Publish the matrix. When someone argues about a priority, you are arguing about inputs to a known rule, not about who is more important.

Second, separate response time from completion time, and make the completion target conditional on whether parts are available. A four-hour response with a twenty-four-hour fix target is achievable. A twenty-four-hour fix target on a pump needing a six-week lead-time seal is a target you will miss for reasons nobody in the workshop controls, and missing targets for uncontrollable reasons is how SLA reporting loses credibility. The full design, priority bands, clock rules, exclusions and escalation, is in the SLA matrix design pillar.

6. Planning and scheduling are two different jobs

This is the distinction that most separates operations that run well from operations that run hot, and it is worth stating plainly.

Planning answers what and how. It is asset-facing and time-independent: what is the scope, what steps, which trades, how many hours, which parts, which tools, which permits, what safety controls, what drawings. A planner turns a vague request into an executable package of work. Crucially, planning happens before the work order is schedulable, and a work order that is not planned is not ready to schedule no matter how urgent it feels.

Scheduling answers when and who. It is calendar-facing and capacity-constrained: given the planned hours by trade, the available crew capacity this week, the asset access windows, the shutdown calendar and the priority ranking, what work goes into which day. A scheduler does not define scope; a scheduler allocates capacity against scope already defined.

When one person does both under time pressure, planning is the half that gets dropped, because scheduling has a visible daily deadline and planning does not. The symptom is unmistakable: technicians dispatched to jobs where they discover the scope on arrival, return to the store for parts, and finish half of what was on the list. The fix is organisational rather than technical. Protect planning capacity, insist that work orders reach a planned state before they enter the schedule, and measure the proportion of scheduled work that was planned first. I would aim for a substantial majority of routine work planned before scheduling, accepting that genuine emergencies bypass the queue by design.

Do not measure this with utilisation alone. Schedule compliance, the proportion of work completed in the window it was scheduled for, is the honest measure of whether planning and scheduling are working together, and the schedule compliance pillar covers how to calculate it without gaming it.

7. Assignment models: individual, crew, pool, self-assign

How a work order reaches a pair of hands is a design choice with real consequences for accountability and for how much supervisor time gets consumed. Four models, and where each belongs:

• Individual assignment: a named technician owns the work order. Clearest accountability, best for skilled or high-risk work, and the model statutory and permit-controlled work should always use. The cost is supervisor time, because someone has to make every assignment decision, and a single absence strands the queue.
• Crew assignment: a multi-person crew holds the work order with a lead responsible for closure. Correct for work that genuinely needs more than one person, but you must still capture labour hours per person or your cost data is wrong and your utilisation reporting is fiction.
• Pool or queue assignment: work orders land in a trade or zone queue and the supervisor or dispatcher pulls from it. Scales well in high-volume reactive environments such as large campuses. The failure mode is orphaned work: items nobody picks up because no individual owns them, which is why a pool needs an ageing alert as a hard requirement.
• Self-assign: technicians claim work from a visible queue on a mobile device. Fast, reduces dispatcher load, and works genuinely well with mature, trusted teams. It also produces cherry-picking of the quick, convenient jobs unless you constrain what is claimable, and it is unsuitable where competency or permit authorisation must be verified before assignment.

Most operations of any size need a blend: individual assignment for skilled and permitted work, pool for high-volume reactive, self-assign for a bounded set of routine tasks, crew for planned multi-trade jobs. What matters is that the model is deliberate and that every work order, under every model, has a single identifiable accountable party at all times. A work order with no owner is a work order that ages silently.

8. Mobile execution and the offline question

Completion quality is decided at the point of execution, which means it is decided on whatever device the technician has in their hand. If the record has to be written up later at a desk, from memory, at the end of a shift, you will get thin data no matter how well the form is designed. Capture must happen where and when the work happens.

What matters in a mobile work order app, in the order I would weight it: the work order list filtered to what is mine and due; the full job plan and asset history visible on the device; labour time capture that is a button rather than a form; parts issue from the device; failure coding by pick list, not free text; camera capture attached directly to the work order; readings entry; and a raise-follow-up action that takes two taps. Offline capability is not optional in plant rooms, basements, tunnels, lift shafts and remote sites, and offline means genuinely queueing and syncing changes, not showing a cached read-only view. The detail, including the honest limits of offline sync and conflict handling, is in the mobile CMMS pillar.

One integration point deserves naming here. Where permit to work applies, the mobile work order must show permit status and must refuse to allow work to start without a valid permit, not merely record a permit number as a text field. That linkage is covered in the permit to work integration pillar, and it is one of the few places I would treat a technical control as non-negotiable rather than a matter of preference.

9. Completion quality: the ten minutes that decide everything

If I could change one behaviour across the operations I have worked with, it would be this: treat the last ten minutes of a job as part of the job. Completion is where the entire value of the work order record is created or lost.

A defensible completion capture, which you can lift as a checklist:

Item eight is the one that gets skipped most and costs most. A temporary repair that is never followed up is a known defect the organisation has quietly forgotten, and it will reappear as an emergency at the least convenient moment. Make raising a follow-up work order a single action from the completing work order, with the asset, location and history carried across automatically. If raising a follow-up takes more effort than not raising one, it will not get raised.

10. The review gate, and why it cannot be skipped

Between work complete and closed there should be a review state where a supervisor or planner checks the record. Not the workmanship, which is a separate quality question, but the record: is the failure coding plausible, are the labour hours present and credible, were parts booked, is there a follow-up where the narrative implies one, is the asset correct.

This gate is almost always the first thing cut when the operation is busy, and the consequence is predictable. Data quality is not self-sustaining. If nobody ever looks at failure codes, technicians correctly conclude that nobody uses them and start selecting the first value in the list. Within a quarter your coding distribution is meaningless and the reliability analysis you built the whole design for is impossible.

A realistic review discipline, given that nobody has capacity to review everything: review every work order above a cost or hours threshold, every work order on a critical asset, every safety-related or permitted job, and a random sample of the rest, say one in twenty. Give feedback to the individual, not to the room. Report coding completeness as a named metric with an owner. Reviewed volume matters less than the fact that everyone knows review happens.

11. The reporting that only works if the above is captured

It is worth being blunt about the dependency chain, because the reporting requests arrive long before anyone has invested in the capture discipline that makes them answerable.

• Backlog in hours, aged by priority: needs estimated hours at planning and honest status values. Backlog as a count of open work orders is close to useless, because twenty lamp changes and twenty pump overhauls are not the same problem.
• Planned versus reactive ratio: needs disciplined work order types. This is the single best indicator of whether an operation is in control of its workload.
• Schedule compliance: needs a scheduled window and a completion timestamp, and a rule about what rescheduling does to the measure.
• Mean time to repair and availability: needs downtime start and end captured at the asset, which almost nobody does consistently without enforcement.
• Maintenance cost per asset: needs labour hours and parts booked to the correct asset, every time. One wrong asset reference silently corrupts two asset histories.
• Repeat failure and bad-actor analysis: needs failure coding at a consistent granularity. This is the payoff item, and it is impossible without coding discipline.
• SLA performance: needs priority set at screening and clock rules everyone has agreed, including what pauses the clock.

The wider metric set, how these roll into a management dashboard and which of them are worth incentivising, is in the FM KPI framework pillar. What I would stress here is the direction of causation. You do not fix reporting by buying a better reporting tool. You fix reporting by fixing the fields at source, and that work happens in states two, four and eleven of the lifecycle table above.

12. Real work order software versus a ticketing tool with a maintenance label

A great many products are sold as work order software that are, underneath, generic ticketing systems with the word "asset" added to a custom field. They demo beautifully, because a demo is mostly about creating a request and closing it, which is exactly the part a ticketing tool does well. The gaps appear at month six. The distinguishing capabilities I would test in any evaluation:

• A real asset register with hierarchy, not a free-text field or a flat list. Work order history must roll up from component to equipment to system to location, or you can never analyse at the level where decisions are made.
• Job plans and task libraries reusable across work orders, with steps, trades, estimated hours and parts lists attached, and version control when a plan changes.
• A PM generator that creates work orders on date and meter triggers, handles seasonal and floating schedules, and does not stack duplicates when work is late.
• Inventory integration where parts reserve at planning and issue at execution, adjusting stock and posting cost. A parts text box is not inventory integration.
• Labour and cost accounting at craft rates, with estimate versus actual, so a work order carries a real cost and not just a duration.
• Structured failure coding with pick lists scoped by asset class, enforced conditionally by work order type.
• Meter readings and condition data stored as a time series against the asset, capable of triggering work.
• Permit, isolation and safety controls linked to the work order as a blocking control, not documentation.
• Offline mobile execution with queued write-back, not a cached read-only view.

Test these with your own data and your own worst-case work order, not with the vendor's demo dataset. Enterprise platforms such as IBM Maximo, SAP PM, Hexagon EAM, Infor EAM and Planon carry all of the above as standard, at the cost of significant configuration effort and licence spend. The mid-market tools, MaintainX, Limble, Fiix, UpKeep, eMaint, vary considerably: some have genuine asset hierarchy, job plans and inventory integration, and some have a strong mobile experience over a thin data model. Neither tier is the right answer generically. The question is whether the product's data model supports the record you defined in section three, and that is a question only your own field-by-field walkthrough answers. For structuring the shortlist itself, see the CMMS buyer shortlist pillar.

For the management-system framing that sits above the tool choice, the asset management standard family published by ISO is the usual reference point, and for maintenance task content and frequencies in a building services context, SFG20 remains the most widely used library in the UK and Gulf markets. Both are worth knowing before you design job plans from scratch.

13. The honest list of what goes wrong

Work order systems fail in a small number of consistent ways, and none of them are software defects. In rough order of how often I encounter them:

• Rubber-stamped closure. Work orders closed in bulk at month end to clear the backlog, with labour hours estimated retrospectively and coding filled with the default value. This is the most corrosive of all failures, because it produces data that looks complete and is wrong, which is worse than data that is obviously missing.
• Missing or meaningless failure codes. Either the field is optional and blank, or the list is so long that everyone picks "other", or so short that everything is "general fault". Both outcomes destroy reliability analysis, and both are design failures rather than technician failures.
• No follow-up work order raised. Temporary repairs closed as complete. The defect is now invisible and will return as an emergency.
• Backlog with no ageing discipline. Nobody reviews the open population, so work orders from eighteen months ago sit alongside this week's, the total grows, and the number stops being used for decisions. A backlog nobody trusts is a backlog nobody manages.
• Priority inflation. Everything urgent, so nothing is. Usually a consequence of letting requesters set priority with no screening state.
• Labour not captured. Hours recorded at shift level rather than work order level, so no work order has a true cost and estimate accuracy can never improve.
• Wrong asset selected. Technicians pick the nearest plausible asset from a badly structured list, corrupting two histories at once.
• On-hold as a parking lot. Work parked with no reason and no expected resumption date, invisible to the ageing report.
• Planning capacity quietly absorbed into scheduling. The planner becomes a dispatcher, planning stops, wrench time falls, and nobody connects the two events.

The common thread is that all nine are consequences of an absent or unenforced process state, not of a missing feature. Which is encouraging, because it means the fix is available to maintenance leadership without a procurement cycle.

The idea to walk away with

The work order is a data record that happens to also instruct a person. Treat it only as an instruction and you get work done and learn nothing. Treat it as both, and every reliability improvement, every budget defence and every credible KPI becomes available from your own history.

The states that create that value, screening, planning and review, are the three that get cut first under pressure, and they are cut because their benefit is deferred while their cost is immediate. Protecting them is a leadership decision rather than a software capability. The tool can enforce what you decided; it cannot decide for you.

Final thoughts

If you are evaluating work order software, do the work in this order: define your lifecycle states and who owns each transition; define the complete work order record field by field with a named downstream consumer for every field; decide what is mandatory by work order type rather than universally; then evaluate products against that definition with your own data. Teams that do this in that sequence get a system that fits the operation. Teams that buy first and design the process around the product's defaults spend the next two years working around decisions a vendor made for a different business.

And if you already have a system that is under-delivering, resist the instinct to replace it. In the large majority of the reviews I have done, the platform was capable and the lifecycle discipline was not. Reinstating the screening state, protecting planning capacity, designing a usable failure code list and running a real review gate will do more for your data in one quarter than a migration will do in two years, at a small fraction of the cost and disruption.

Related reading: Work order types in a CMMS, Automating work order intake and triage, Failure codes: Problem, Cause, Action, SLA matrix design for FM operations, Mobile CMMS: field-ready maintenance apps, FM KPI framework.