Key points
- A request is an observation. A work order is a commitment.
- Anyone should be able to raise a request, with no training and ideally no account.
- Only maintenance creates work orders, after triage. That keeps the backlog made of real, planned work.
- Every request gets an answer, including a rejected one. People stop reporting when reports disappear.
Side by side
| Work request | Work order | |
|---|---|---|
| Who creates it | Anyone who notices a problem | The maintenance team |
| What it says | Something is wrong here | This job will be done, by this person, by this date |
| Detail | A description, a location, maybe a photo | Asset, priority, tasks, parts, assignee, schedule |
| Possible outcomes | Converted, merged or rejected with a reason | Completed and closed, or cancelled |
| Counts toward | Demand: how much is being reported | Workload, labour, parts and cost |
Why keep them separate
Some teams let everyone create work orders directly. It feels simpler, and for a team of three it can be. As the number of people reporting grows, it causes three problems:
- Duplicates. Five people report the same broken air conditioner and the backlog shows five jobs.
- Noise. Requests that are not maintenance at all, or are already planned, sit beside real work and hide it.
- Bad numbers. Work order counts, completion rates and backlog age stop meaning anything when anyone can add to them.
Separating the two keeps the front door wide open while the backlog stays clean: anyone can say something is wrong, and only a planned, assigned job becomes a work order.
Making requests easy to raise
The people who see faults first are rarely the people with a maintenance login. The easier a request is, the earlier you hear about a problem, and the cheaper it is to fix.
- Put a QR code on each asset or room. Scanning it should open a short form that already knows which asset it is about.
- Ask for three things only: what is wrong, where, and optionally a photo.
- Do not charge a licence per reporter. Every person you leave out is a fault you hear about later.
- Give the reporter a way to see what happened to their request.
A simple triage routine
- Review new requests at fixed times, at least twice a day, and immediately for anything marked as a safety issue.
- Link each request to the right asset. If the reporter could not name it, the triager picks it.
- Decide: convert to a work order, record it as a breakdown if the asset is down, merge with an open job, or reject.
- Always give a reason when rejecting, in words the reporter will understand.
- Watch the age of untriaged requests. A request waiting three days is a failure of the process, not of the reporter.
Frequently asked questions
Can a work request become a breakdown instead of a work order?
Yes. If the asset has stopped working, recording it as a breakdown starts the downtime clock and changes the asset's status, and the repair work order follows from there.
Should people need an account to submit a work request?
Ideally not. A QR code or a public request page lets anyone report a problem in under a minute. Requiring a login is the most common reason faults go unreported.
Who should triage work requests?
A maintenance planner or supervisor who knows the assets and can assign work. On small teams this is often the maintenance manager.