Lesson 7 of 10 · 9 min
Organizing work requests and work orders
Written by Melek Mehrez, founder of FreeMaint · Last reviewed October 11, 2026
Lesson objective
By the end of this lesson, you can design the flow from request to work order to closure, write priority rules that everyone applies the same way, and list what technicians record when they close a job.
A request is a signal: someone noticed a problem. A work order is a commitment: maintenance has decided to act, with a person, a priority and a deadline. Mixing the two is how a CMMS fills up with jobs nobody has assessed, while real emergencies wait in the same queue.
This lesson designs the path between them: who can report, who decides, how urgency is judged and what must be written down when the job is done. It is also the part of the project that technicians and requesters feel most directly.
Requests and work orders: two steps, not one
| Aspect | Request | Work order |
|---|---|---|
| Created by | Anyone who notices a problem: operator, cleaner, supervisor | Maintenance, or the system from a preventive plan |
| Content | What is wrong, where, and since when | What will be done, by whom, with what priority and by when |
| Next step | Review: approved, merged with another, or declined | Scheduled, carried out, then closed with a record |
The review between the two is short but essential. It removes duplicates (three people reporting the same leak), turns vague signals into clear jobs, and lets the planner group work by area or by planned stop. On a small site, the maintenance manager reviews requests twice a day; on a large one, a planner does it.
Priorities that everyone applies the same way
Priority decides what gets done first. It only works if everyone judges urgency the same way, so write the criteria down, with an example for each level, and keep the number of levels small.
| Priority | Criterion | Target response |
|---|---|---|
| Critical | Safety or environmental risk, or production stopped | Immediately, even if a job in progress must be interrupted |
| High | Production slowed or quality at risk; failure likely soon | Within the day |
| Medium | Equipment degraded, a workaround is available | Within the week, as planned work |
| Low | Comfort, appearance, improvement | When capacity allows |
Target times depend on your site: a hospital and a warehouse will not set the same ones. What matters is that they are written down, known to requesters, and reviewed when they are no longer met.
Reporting by QR code and closing with a record
The easier it is to report, the earlier problems arrive. A QR code stuck on each machine lets an operator report from a phone in seconds: the asset is identified without typing, and a photo shows the problem better than a long description.
Closure is the other end of the flow. A work order closed with “done” teaches nothing; one closed with a few facts feeds the indicators in lesson 10. Ask technicians to record, at a minimum:
- What was found and done, in one short sentence.
- The cause, when it is known, chosen from a short list.
- The time spent and, for a breakdown, how long the machine was stopped.
- The spare parts used.
- A photo, when it helps the next person.
Keep this list short and the same for everyone. Five facts recorded every time are worth more than twenty fields filled in once in a while.
Example
The flow at the packaging plant
The plant sticks a QR code on each of its 40 assets. Operators report from their phones; the maintenance manager reviews requests at 7:30 a.m. and 1:30 p.m., merges duplicates and turns the rest into work orders, with a priority taken from the written table.
The production supervisor agrees to the criteria in one meeting: “critical” means safety, environment or a stopped line. In the first month after go-live, critical work orders fall from about a third to fewer than one in ten, and the backlog becomes readable.
At closure, technicians record the cause, the downtime, the time spent and the parts on their phones. Six weeks after go-live, the causes show that half of the filler stops come from one worn guide rail, a pattern nobody had seen on the whiteboard.
Four common mistakes
- Letting requesters create work orders directly, with no review.
- Priorities without written criteria, so that everything becomes urgent.
- Closing jobs with “done” and nothing else.
- Never telling requesters what happened to their request.
In FreeMaint
Included in Core (free)Requests, work orders and QR codes in FreeMaint
In FreeMaint, anyone can report a problem from Requests, from an asset's page with Report a problem, or by scanning the asset's QR code. Someone without an account can send a request with a photo and follow it through a tracking link. An approved request becomes a work order that keeps the asset, the photos and a link back to the request. Work orders have four priority levels, from Low to Critical, and when a job is completed, FreeMaint shows which elements of the record are still missing.
Read the documentationTemplate for this lesson
Request-to-work-order flow sheet
Excel (.xlsx), blank, printable
Key takeaways
- A request is a signal; a work order is a decision to act, made after review.
- Write priority criteria with examples, and keep the number of levels small.
- Make reporting easy, for example with a QR code on each machine.
- Close every job with the same short record: what was done, cause, time spent (and downtime for a breakdown), parts, and a photo when useful.
Exercise in FreeMaint
Do it in your own FreeMaint workspace, then check it here. Optional: the exercises of lessons 5, 7 and 8 add “with hands-on practice” to your certificate.
Complete a work order
Create a work order and take it to Completed, or complete one assigned to you. A work order in the recycle bin does not count.
Check your understanding
A few quick questions. Nothing is recorded.