When a Work Order System Is Enough, and When You Need a CMMS

A work order system can solve a lot. Someone reports a problem. The work gets assigned. A technician receives it. The repair gets done. The request gets closed. If that is substantially the operating problem, a straightforward work order system may be exactly what the organisation needs.

The threshold for a CMMS appears when closing the work is no longer enough, because the work has to remain connected to other things: the asset it happened to, the maintenance that should happen next, the parts it consumed, the failure it revealed, the meter reading it changed, the cost it created, the condition it exposed, or the follow-up work it generated.

That is a different information problem. So the useful question is not how many work orders you have.

What must still be true after the work order closes?

The short answer

A work order system may be enough when the primary need is to receive, assign, prioritise, track and close work.

A CMMS becomes more useful when individual work transactions need to participate in a persistent maintenance model containing assets, preventive maintenance, history, parts, labour, meters, failures, inspections, costs and other maintenance relationships. The conceptual difference between the two categories is covered separately on this site. This guide is about where the practical buying threshold sits for one operation.

The distinction is not absolute. Some products called work order systems contain substantial CMMS capability. Some products called CMMS are relatively simple. Do not buy from the label. Test the operating relationships.

Work orders are transactions

Consider a leaking sink in Building A. Someone reports it. Facilities creates work order WO-1048. It is assigned to a plumber. The plumber repairs the leak. WO-1048 closes.

REQUEST → ASSIGN → PERFORM → CLOSE

If the primary requirement is making sure requests do not disappear and people know who owns the work, this can be enough. Simplicity is not a defect. A simpler system can mean easier adoption, less configuration, less data administration, faster implementation, lower cost and less friction for technicians.

A work order system is not inadequate merely because it is simple. It is inadequate only when the operation needs relationships it cannot preserve.

The work order can be enough

Imagine a small organisation with straightforward facilities, mostly reactive requests, limited equipment-specific maintenance, little spare-parts management, few recurring PM programmes, no meaningful meter-based maintenance, limited failure analysis and modest reporting requirements.

Its important questions may be these.

What is open?
What is urgent?
Who has it?
How long has it been open?
Was it completed?
What did the technician say?

A good work order system may answer those questions perfectly well. A CMMS is not the right answer merely because it contains more functionality.

The threshold is not work-order volume

Advice of the form "once you reach a certain number of work orders per month, buy a CMMS" is common, and the evidence does not support a universal threshold.

A large service organisation might process substantial request volume with a relatively simple transaction model. A smaller maintenance operation might have relatively few work orders but need deep relationships among equipment, PM, meters, components, parts, failure history and condition.

Work-order count measures transaction volume. It does not measure maintenance complexity.

State College shows the threshold clearly

State College Area School District provides an unusually direct example of an organisation describing the moment a work order system stopped being enough.

In a January 2022 recommendation to its Board of School Directors, the district's Office of Physical Plant wrote that Physical Plant was using a Jira work order system that was an add-on to the technology department ticket system, and recommended moving to a CMMS.

The stated problem was not an inability to create work orders. The department wrote that it had no historical records on when equipment was worked on, what was completed, or any accountability for labour or parts.

Its stated goals for the new system describe the relationships it wanted the work to participate in.

Replace the current work order system with one that can tie work orders to assets
Enter all pertinent asset attributes, so information sits in one place and ordering parts becomes more efficient
Upload equipment operation and maintenance manuals so procedures and safety measures are accessible in the field
Set preventative maintenance schedules with succinct procedures
Manage a spare parts inventory with integration to assets and reordering capabilities
Track equipment lifecycle costs through labour and part inputs
Develop an asset work order database to reference past work
Automate service contract intervals

That is the transition this guide is about. The work order still matters. The change is that the work order now has to participate in a larger maintenance record.

The Closure Test

This is a CMMSBuyersGuide framework, not an industry standard. It is a practical test of how much information must survive and propagate after an individual work transaction is completed.

Take a representative work order. Close it. Then ask what must still matter tomorrow because this work happened.

One valid answer is: nothing beyond the completed ticket. The other possible answers are the interesting ones.

Asset history changed
Parts inventory changed
Labour and cost history changed
A meter reading changed
Failure history changed
Equipment condition changed
Another work order has to be created
PM strategy should be reviewed
Warranty evidence changed
Downtime accumulated
Repair or replace evidence changed

If closure ends the information problem, a work order system may be enough. If closure creates or changes maintenance context, evaluate the broader maintenance model.

Transaction state is not maintenance state

A work order has transaction state, for example new, assigned, in progress, complete, closed. Those states describe the work transaction.

An asset can have maintenance state as well: operating, unavailable, awaiting a part, recurring failure, PM due, inspection failed, follow-up required, under observation. These are illustrations, not a universal status list; every operation names its own.

The distinction matters because closing a work order can end the transaction while changing the maintenance state of something else.

The work can be closed while the maintenance problem remains open.

The State Transition Test

Another CMMSBuyersGuide framework. For any completed work, ask three questions in order.

Step	Question	Example
Before	What was true before the work?	P-104 operating with abnormal vibration
Event	What maintenance event occurred?	Technician inspects P-104
After	What is now true because of the work?	Bearing replacement required

The inspection work order may be complete. The maintenance consequence is not.

Completion is a workflow state. Consequence is an operational state.

San Francisco Unified shows how quickly the questions escalate

In April 2026, San Francisco Unified School District issued a request for information titled Operations – Work Order System, RFI SFUSD-PD-FY26#84. It sought information from contractors to develop a work order management system to track assets and associated maintenance.

The capabilities it described already went beyond routing and closing tickets.

Technicians using mobile devices in the field to log hours, look up information and take photos
Keeping track of expenses, including labour and materials
Uploading pre-existing asset identifiers from spreadsheet format
Work order management: assigning tasks and status updates to individual assets
Importing assets and maintenance history from the legacy solution
Compatibility with asset management software that includes system-level data for useful life and estimated replacement cost
Linking asset replacement, upgrade and procurement with associated capital projects

The district's public solicitation listing then shows a request for proposals titled Computerized Maintenance Management System, RFP SFUSD-PD-FY27#86, posted in August 2026.

The district has not published a statement connecting the two documents, and none should be assumed. What the chronology shows is narrower and still useful: within the same year, one buyer publicly explored a work order system whose requirements were increasingly asset-centred, and subsequently posted a CMMS procurement.

The label can lag behind the operating requirement.

A work order attached to an asset is only the beginning

The opposite mistake is just as easy. Adding an asset field does not by itself create a useful maintenance model. WO-1048 with asset P-104 is a useful connection. The question is what that connection makes possible.

Can P-104 now show its past work, open work, PM, failure history, parts, meters, downtime, condition and costs? If not, asset tracking may be little more than a lookup field.

The important question is not whether a work order can name an asset. It is what the asset can learn from the work order.

The Memory Test

Take P-104 and ask a vendor to show everything the system knows about this pump because of work performed during the last three years.

Do not let the demonstration begin with a work-order search. Begin at the asset and ask to see completed work, open work, PM, failures and findings, labour, materials, readings, costs, attachments and follow-up work. Require only the categories the organisation actually needs.

The test reveals whether the system holds searchable tickets or persistent maintenance memory.

Work order history is not automatically asset history

Work order history is a list of completed work transactions. Asset history is the accumulated maintenance story of a maintained object, which may need to combine corrective work, PM, inspections, readings, failures, parts, component changes, condition, downtime and cost. The way work orders move through a maintenance system determines how much of that story actually accumulates.

A folder full of completed work orders is not necessarily a coherent maintenance history.

Relationship Load

A CMMSBuyersGuide framework introduced here. Relationship load is the number and importance of maintenance relationships that must remain intact around a work event. It is not a score, and a higher load is not better.

REQUEST ↔ WORK ↔ ASSIGNEE

That is a low relationship load. A moderate one adds place and equipment.

REQUEST ↔ WORK ↔ LOCATION ↔ ASSET ↔ TECHNICIAN

A higher one puts the asset at the centre of a maintenance model.

ASSET ↔ PM ↔ WORK ↔ LABOUR ↔ PARTS ↔ METER ↔ FAILURE ↔ FOLLOW-UP ↔ HISTORY

The point is that the software has to preserve the relationships the operation depends on, and no more.

Complexity lives in the relationships, not in the number of tickets.

Preventive maintenance changes the problem

A work order system can generate recurring work. The deeper question is what the recurrence needs to know. Earlier research on this site set out how preventive maintenance behaviour differs between a repeating task and a maintained PM rule: triggers, anchors, incomplete prior cycles, out-of-service equipment, meters, findings and corrective follow-up.

So ask which requirement the operation actually has: create this work every month, or maintain the recurring maintenance policy for this specific asset and preserve what each occurrence teaches us. The second is a deeper maintenance-management requirement.

The Recurrence Test

Create a PM for P-104 during the demonstration, then run it through five ordinary complications.

Complete it late
Leave the next occurrence incomplete
Take P-104 out of service
Discover a defect during the PM
Return P-104 to service

Then ask what happened to future PM, to follow-up work and to asset history. This distinguishes a repeating ticket from a maintained PM relationship.

Parts create another threshold

Suppose WO-1048 consumes bearing B-17. If all the organisation needs is a technician note saying a bearing was used, a simple work order handles it. But completion may need to reduce stock, attribute the bearing to P-104, add material cost, trigger reorder and preserve consumption history. At that point the work event has changed inventory state and asset cost, which is where maintenance inventory management becomes part of the buying decision.

When work consumes a managed resource, closure may need to update more than the ticket.

The Part Test

Start with five bearings in stock. P-104 work consumes two. Ask the vendor to demonstrate the work-order issue, the remaining quantity, the asset and material history, the work cost and the reorder behaviour if that matters to you.

A buyer learns more from that than from asking whether the product has inventory management.

Meters create state

Suppose P-104 receives maintenance every 2,000 operating hours. A meter reading is then not merely a note on a ticket. It may change the PM forecast, the due state and the generation of work.

Ask directly: does the reading simply live inside the ticket, or does it change the maintenance state of the asset? That is another threshold.

Findings create future work

A technician completes an inspection and finds abnormal bearing wear. The inspection is finished. Maintenance now has a new obligation.

Ask whether the finding can become controlled corrective work, linked to the asset, linked to the originating inspection, prioritised, and visible until it is resolved.

A maintenance system has to manage not only work that exists, but work discovered by other work.

Work creates work

This site has previously described how work generates further work in a maintenance operation. The chain matters more than any single link.

REQUEST → WORK → FINDING → FOLLOW-UP WORK → NEW FINDING OR RESOLUTION

A transaction system can manage each ticket individually. The maintenance question is whether the relationship among them survives.

The Follow-Up Test

During WO-1048 the technician finds a cracked coupling. Close the original work appropriately, then ask where the cracked coupling problem now lives.

If the answer is that it is in the notes of a closed ticket, ask how the organisation knows it still requires action. Systems solve this in several valid ways. The buyer is testing whether the consequence continues, not prescribing a workflow.

Cost can become history

A work order can capture an $800 repair cost. The maintenance decision eventually asks something different: how much has P-104 cost us over the last three years? That requires individual transactions to accumulate meaningfully against the asset. State College specifically wanted to track equipment lifecycle costs through labour and part inputs.

A transaction has a cost. An asset develops a cost history.

Volume is the wrong shortcut

Suppose Organisation A processes 2,000 simple service requests a month, each concerning a location, a problem, an assignee and a completion. Organisation B processes 150 maintenance work orders a month, each of which may interact with equipment, PM, meters, parts, failures, condition and downtime.

Organisation B can have lower transaction volume and greater maintenance-information complexity. These numbers are illustrations, not benchmarks.

Volume tells you how busy the workflow is. Relationship load tells you how much maintenance context the workflow must preserve.

Company size is also a weak shortcut

Small business means work order system, and enterprise means CMMS, are both unreliable rules. A small operation with critical equipment can need substantial maintenance depth. A large organisation can have a narrow workflow that needs only request tracking.

System depth should follow the maintenance model, not the employee count.

The Fragmentation Test

A work order system can appear sufficient because the other maintenance relationships are being maintained somewhere else. Ask where each of these lives today.

Assets
PM schedules
Parts
Meters
Inspection results
Maintenance history
Warranties
Procedures

A common answer: work orders in one system, assets in a spreadsheet, PM in a calendar, parts in another spreadsheet, manuals in shared folders, meter readings on paper. Then ask the real question — is the work order system sufficient, or are people manually supplying the missing maintenance model around it?

A simple system can appear sufficient when the organisation is doing the integration by hand.

The Hidden System

A CMMSBuyersGuide framework. The hidden system is the collection of informal tools and human memory required to supply maintenance relationships the primary software does not preserve.

WORK ORDER SYSTEM + SPREADSHEETS + CALENDARS + SHARED DRIVES + WHITEBOARDS + EMAIL + PAPER + TECHNICIAN MEMORY

Manual processes are not a failing. They may work well at the right scale and complexity. The question is how much operational dependency exists outside the official system, and whether that dependency is stable.

The Absence Test

One of the strongest questions a buyer can ask internally: if our most experienced maintenance person were unavailable for six months, what important maintenance context would disappear with them?

Which pump keeps failing
Which spare fits
Why a PM interval was changed
Which vendor rebuilt the motor
Where the manual is
Which work is waiting on a part
What temporary repair is still in place

Not all knowledge belongs in software. But recurring operational dependence on memory can reveal missing system structure.

The goal is not to remove human knowledge. It is to stop critical maintenance state from existing only in someone's head.

Lake County describes a connected unit

Lake County's CMMS procurement describes the system as intended to assist with managing assets, work orders, inventory and other workflows for the Public Works wastewater and water systems.

The significance is not the feature list. It is that the buyer describes the procurement unit as a connected maintenance environment rather than work order processing on its own.

Wicomico County shows what operating depth looks like in use

Wicomico County Public Schools' 2026 Comprehensive Maintenance Plan describes the CMMS its Operations and Maintenance teams use. The asset function maintains data on all physical plant assets and associated work order history. Work scheduling covers planning and scheduling of routine and preventive maintenance and programme checks and inspections. Inventories cover orders, quantities and controls on supplies, tools and equipment. The plan describes decentralised web-based control and analysis of the maintenance data with report generation in real time, and states that 100 percent of preventative maintenance work orders are automatically generated.

The plan is also candid about how far the asset inventory has progressed: it reports that 20 percent of major building systems and components are tagged and entered in the CMMS inventory, a ten percent increase over the previous year, with a 30 percent goal for the following year, and notes that the work is being done by internal staff to avoid the cost of contracting it out.

Do not buy complexity you will not maintain

A CMMS introduces additional records, and those records require governance. Someone has to maintain the asset registry, PM rules, inventory, meters, procedures, failure codes, statuses and user roles. That is ongoing work, and it belongs in the planning side of the operation rather than being assumed away. A work order system with excellent adoption can be more valuable than an elaborate CMMS full of stale data.

Do not buy maintenance memory you are unwilling to maintain.

Relationship Value vs Administration Burden

A CMMSBuyersGuide framework. For every additional relationship, ask what decision or workflow improves if the relationship is preserved, and what data someone has to create and maintain for it to stay true.

Relationship	Value	Burden
Asset ↔ work history	Repeat-failure visibility	Accurate asset identification on every work order
Parts ↔ work	Stock and cost visibility	Parts catalogue and issue discipline
Meter ↔ PM	Usage-based maintenance	Reliable meter capture

The right CMMS scope preserves relationships whose operational value exceeds their administrative burden.

When a work order system is probably enough

There is no score here, and no organisation must stay where it is. But a work order system may well be enough when most of the following hold.

Request, assignment and closure is the main problem
Locations matter more than equipment identity
Recurring work is simple
Equipment history has limited decision value
Parts do not need formal maintenance integration
Meter-based maintenance is unnecessary
Findings rarely create controlled follow-up work
Reporting is primarily workload and status
Supporting spreadsheets and manual tools are manageable and trustworthy

When to evaluate a CMMS

Evaluate maintenance depth when several of these relationships matter to decisions you actually make. Where equipment identity and history are central, the questions in the equipment maintenance software guide apply as well.

Work ↔ asset
Asset ↔ history
Asset ↔ PM
PM ↔ meter
Work ↔ labour
Work ↔ parts
Finding ↔ follow-up
Failure ↔ asset
Inspection ↔ condition
Work ↔ downtime
Work ↔ cost
Asset ↔ procedure or manual
Asset ↔ warranty

Do not count features. Map the relationships your maintenance operation cannot afford to lose.

The Maintenance Relationship Map

A CMMSBuyersGuide framework for doing that mapping on paper before any demonstration. Put the asset in the centre and draw only the relationships your operation depends on.

ASSET ↔ WORK · PM · PARTS · LABOUR · METER · FAILURE · INSPECTION · CONDITION · COST · DOCUMENT · WARRANTY

Work carries its own relationships in turn: to the request that started it, the technician who performed it, the parts it consumed, the findings it produced and the follow-up work it generated.

WORK ↔ REQUEST · TECHNICIAN · PART · FINDING · FOLLOW-UP

No buyer needs every relationship. Circle the ones the operation cannot lose.

Your required CMMS is the smallest system that can preserve the relationships you circle.

The Minimum Sufficient Maintenance Model

A CMMSBuyersGuide framework, and the point this guide builds towards. The minimum sufficient maintenance model is the smallest set of persistent maintenance records and relationships needed to operate without losing information that materially affects future maintenance decisions.

For one organisation that may be:

REQUEST ↔ WORK ↔ LOCATION

For another it may be:

ASSET ↔ WORK ↔ PM ↔ PARTS ↔ METER ↔ FAILURE ↔ HISTORY

For a third, where repair-or-replace, renewal and capital decisions depend on the same records, the longer decision chain described in the EAM software guide may be required beyond that.

The goal is not to graduate from work orders to CMMS. The goal is to build no more maintenance system than the operation needs, and no less.

A six-step buyer exercise

Take ten recent work orders that are representative of your operation.
Close them on paper. Assume each one is complete.
Ask what changed. Asset? Inventory? PM? Meter? Condition? Cost? Future work?
Ask where that change lives today. Work order system? Spreadsheet? Another system? Someone's memory? Nowhere?
Identify the relationships that appear repeatedly across the ten.
Demo those relationships. Make vendors run your real scenarios, not their standard tour.

That turns category selection into an exercise about your operating model.

The final demo

Give a vendor P-104 and one continuous scenario rather than a feature list. If it helps, compare the sequence with how work is normally tracked end to end.

A requester reports abnormal noise.
Work is created.
A technician is assigned.
The technician inspects P-104.
A meter reading is captured.
The technician uses bearing B-17.
A cracked coupling is discovered.
The original repair is completed.
Corrective follow-up is created.
Inventory changes.
Asset history changes.
PM timing is reviewed.

That is the threshold test. It is the same discipline applied to the work order itself, turned around to look at the asset.

Final perspective

A work order system and a CMMS are not two rungs on a universal software ladder. A work order system solves an important problem: control the work. A CMMS becomes useful when controlling individual work is no longer enough, because maintenance depends on preserving relationships among work, assets, recurrence, resources and history.

The threshold is not the number of employees, buildings, technicians or tickets. It is the maintenance context that must survive the transaction.