The work order: what it holds

The work order is the unit everything else in a CMMS revolves around: it’s where cost, equipment history, indicators, and proof of what was done all come from. That’s why it’s worth looking at what it holds and why.

Almost every field exists because someone ran into a problem they couldn’t solve without it.

Where it comes from

A work order can have three origins, and it’s worth having the system tell them apart, because they get analyzed separately afterward:

From an incident, when someone has reported something. The order keeps that origin, so you can always trace back from the work done to the report that triggered it.

From a preventive plan, generated automatically from a schedule or when a counter’s threshold is exceeded.

From an accepted quote, which generates the order without having to rewrite anything.

What identifies the work

Client, address, system, and the machine affected. Plus the project or job site, if the work belongs to one.

Having the asset linked isn’t an administrative detail: it’s what makes this order part of that specific equipment’s history instead of a general list. Without that link, in two years you won’t be able to answer how much it has cost to maintain that machine.

The times

Three fields that look redundant and aren’t:

Target time, what it should take according to the work order template. Estimated time, what was projected when planning. Deviation, the difference from the actual time.

Actual time is measured with a stopwatch inside the order itself from the app, not estimated at the end of the day. Remembered hours always come out lower than reality.

Deviation is the field that gives the most information over the medium term: when a type of job systematically deviates, it’s almost always because it’s being quoted below what it actually costs.

There’s also a response time, which is what gets measured when there are committed deadlines.

What happened

Cause of downtime, when the equipment was stopped. This is what lets you later analyze why something keeps recurring.

Resolved or not. It seems obvious, and it’s the field that distinguishes a closed order from an abandoned one.

Pending material and needs a return visit. Two different states, and both useful: without them, those jobs live in a notebook and the client remembers before we do.

Warranty. Whether the work is covered. Together with the warranty expiration on the asset record, this is what prevents paying for repairs on equipment that was still covered.

What gets consumed

Material is consumed directly from the order, against the warehouse and with its batch when it has one. It’s not a later entry: on closing, stock has gone down and the job’s cost has gone up.

And the hours logged, per technician, which is what later allows calculating cost per intervention, per equipment, and per client.

What gets checked

If the order has a work order template attached, the technician fills in the checklist with its fields and values. On preventive jobs, the app won’t let you close it until it’s complete.

Fields with a minimum and maximum value turn the check into a measurement: a reading outside range is logged as an anomaly on the spot, and that anomaly can turn into a new incident.

What closes it

Photos, before and after. Client signature captured on screen, with geolocation if enabled. And the final status, which can carry its own associated email to notify without anyone having to write it.

That set — measured times, material, checks, photos, and signature — is what turns the order into proof rather than a note. Legal maintenance rests exactly on this, together with document management and its dates.

The statuses, which are the vocabulary

Statuses aren’t imposed: they’re defined. And each one can carry its own maximum time, its associated email, its visibility to the client, and the don’t notify flag.

Defining five clear statuses with agreed meaning is an hour-long conversation that avoids months of ambiguity about what “in progress” means.

What you can answer afterward

With orders closed this way, reports can answer:

• How much it costs to maintain each piece of equipment, adding up hours and material.
• How long it takes to respond and resolve, by priority.
• What proportion of hours is preventive versus corrective.
• Which jobs deviate from the projected time.
• What percentage of the annual plan has actually been executed.

None of those questions has an answer if the order is closed with just “done.”

What the order connects to the rest

An order doesn’t live in isolation: it’s the point where almost all the system’s data intersect, which is why the fields that link it matter as much as the ones that describe it.

With the asset, which receives the intervention in its history and accumulates its cost.

With the warehouse, which deducts what was consumed and updates stock in the same action.

With the technician, whose logged hours feed workload distribution and cost per client.

With the incident that originated it, so you can measure how much it cost to handle a report, not just how long it took.

With the preventive plan that generated it, so you can know what percentage of the plan has actually been executed.

With the ERP, to which it travels closed, with its hours and material.

That’s the underlying reason it’s worth not treating the order as a simple form: every link left unfilled is a question that won’t have an answer two years from now.

The most expensive mistake when configuring them

Asking for fields nobody is going to look at. Multiplied across every order in the year, each useless field adds up to a lot of time and a fair amount of resistance from the team.

The rule: every field you ask for has to come back to someone as something useful. If it doesn’t, drop it.

If you want to see a full work order with your own data, you can request a demo.