A maintenance request form is easy to build and easy to overwhelm. Within a month of going live it is receiving "the light in the second floor corridor is flickering" and "water is coming through the ceiling above the server room" through the same channel, in the same font, in the order they happened to be typed. The form is working exactly as designed. The problem is that nothing between the submission and the technician decides which of those two gets looked at first.
Triage is that missing step, and most of it is a design problem in the form rather than a staffing problem in the workshop. What follows covers how to set priority so it means something, which fields let a coordinator sort a request without making a phone call, where requests actually go missing, and the point at which a maintenance management system starts to be worth its per user price.
Priority is assigned, not requested
Every maintenance request form eventually gets a priority dropdown, and every priority dropdown filled in by the requester skews high. This is not dishonesty. The person reporting a problem is experiencing it, and their experience of it is genuinely urgent.
Keep the field, and change what it means. Treated as a statement about the issue, a requester selected priority is noise. Treated as a statement about the requester, it is useful: it tells the coordinator how disrupted that person feels, which matters for how the reply is worded even when the work waits.
What actually sets priority is impact, and impact is composed of four things the requester cannot be expected to weigh.
Safety. Anything involving electricity, gas, water near power, fire systems, blocked exits or a trip hazard in a public route outranks everything else on the list regardless of how minor the repair is.
Whether the space still works. A meeting room with one dead light is usable. A meeting room with no lights is not. The question is not how broken the thing is but whether the space or the equipment can still do its job.
Whether it is getting worse. A leak spreads, a crack widens, a bearing that is whining will seize. Damage that progresses moves up the queue because waiting changes the cost of the repair, not just the inconvenience.
How many people it affects. One desk or one floor. Shared infrastructure outranks individual inconvenience even when the individual complaint is louder.
Those four are worth writing down where the coordinator can see them, because a priority scale that lives in one person's judgement produces different answers on different days, and inconsistency is what makes requesters stop trusting the queue and start walking down to the workshop instead.
A scale that survives a real week
Four levels is the practical maximum. Five gets argued about and three forces too much into the middle.
| Level | What it means | Typical response target |
|---|---|---|
| Emergency | Safety risk, or the site cannot operate | Same day, and somebody is told by phone rather than by email |
| Urgent | The space or equipment is unusable, or damage is spreading | Within one to two working days |
| Routine | Works with a workaround, no risk, not spreading | Within the week, batched with other work in the same area |
| Scheduled | Improvement, cosmetic, or something to fold into planned work | Named date or a planned maintenance window |
The response targets in that table are placeholders. The numbers that matter are the ones the team can actually hit, published to requesters, and reviewed against what happened. A target nobody meets is worse than no target, because it converts every request into a complaint about a broken promise.
Two rules keep the scale honest. The first is that emergencies bypass the form. If something is flooding, a form submission is the wrong channel and the form itself should say so, with the phone number next to it. The second is that a request is allowed to change level in one direction based on evidence: an unattended routine job that has now caused damage becomes urgent, and a request never becomes urgent because the requester sent a third email.
Fields that let someone triage without a phone call
The test for any field is whether the answer changes the decision. Under triage, that means whether the answer changes the priority, the trade, or the route to the site.
Location, from a controlled list. Free text location is the single biggest time sink in maintenance intake, because "the kitchen" is four places in a building with four kitchens. A dropdown of buildings, then floors, then rooms, produces answers that can be sorted and grouped. Grouping matters more than it sounds: three routine jobs in the same corridor are one visit.
Asset or equipment, where there is one. If the site has asset tags, ask for the tag. A tag turns a request into a history, and history is what tells you the pump has been repaired four times this year.
What has stopped working, in the requester's words. Not a diagnosis. A description. The requester is a witness, not a technician, and asking them to categorise the fault produces confidently wrong categories.
A photo. For maintenance intake, photo upload does more than any other field on the form. It resolves the ambiguity in the description, it shows the model plate, and it frequently shows the coordinator that the request is not what the words suggested. A form that cannot accept an image pushes that image into a separate message that arrives detached from the request.
Access. Whether the space is occupied, when it can be entered, whether a key or permission is needed, and who to contact on arrival. This is the field most often left off, and it is the reason for a large share of wasted trips.
Whether it is getting worse. A single yes or no question, and one of the few things the requester can judge accurately.
How to reach the requester, with the email address validated as it is typed.
One field to resist: a free text box asking what the requester thinks the fix is. It reads as consultative and it creates expectations about work that may not be the right work.
The handoff is where requests go missing
Three failures account for almost everything that goes wrong after submission, and none of them are about the form.
The notification goes to a person. One coordinator receives the email. On their leave, or during a busy afternoon, the request is invisible to everyone else. From the outside this looks identical to a request being worked on, which is why it stays invisible for so long.
The queue has no owners. Everyone can see it, so nobody is responsible for any single item. Two people open the same request and each assumes the other has it. The symptom is a job that gets done twice or not at all.
The status is set once. A field reading "in progress" that has read "in progress" for eleven days is worse than an empty field, because it creates confidence that nothing is wrong.
The requester sees none of this. What they see is silence, and silence produces the two behaviours that damage the queue most: the same problem submitted three times through three channels, and the next problem reported in person to whoever is nearest. Both are rational responses to a system that does not acknowledge receipt.
An automatic acknowledgement is the cheapest fix available. It needs the reference number, a copy of what they submitted, the priority it was given, and what happens next. Stating the assigned priority back to the requester is the part usually left out and the part that prevents the most follow up, because it replaces an unanswered question with a decision they can query if they disagree.
What to measure once it is running
Two numbers are enough to tell whether triage is working.
The first is the gap between submission and assignment. Not completion, assignment. If requests are sitting unowned for two days before anyone looks at them, no amount of scheduling discipline downstream will help, and the fix is a rota for who watches the queue rather than more technicians.
The second is the slowest tenth of requests. Averages in maintenance intake are reassuring and useless, because the median is dominated by the easy jobs. Sort a month of requests by time to first response and look only at the worst ten percent. If that tail is five or ten times the median, the problem is routing: some requests are falling into a gap and sitting there until someone stumbles over them. If the entire distribution is slow, the problem is capacity, and tooling changes will not touch it.
One more number is worth watching if the data is there: how many requests are duplicates of an existing open request. That figure is a direct measure of whether requesters believe the queue is alive.
Where a form ends and maintenance software begins
The honest comparison is not features against features. It is what the work looks like against what each option charges for.
| Form plus a shared mailbox | Form tool with response management | CMMS or maintenance platform | |
|---|---|---|---|
| Owner per request | By convention | Field on the record | Assignment, with rules |
| Status visible to the team | Manual or none | Stages on the record | Work order states |
| Reply from the same screen as the request | No | Yes | Varies |
| Asset history | No | No | Yes |
| Planned and preventive maintenance | No | No | Yes |
| Parts and inventory | No | No | Yes |
| Technician mobile app | No | No | Yes |
| Typical pricing basis | Included with email | Per person | Per user who manages or closes work |
| Published entry price | Effectively zero | Often free for one person | UpKeep Essential at 24 dollars per user per month; Limble does not publish prices |
| Mid tier | Not applicable | Varies | UpKeep Premium at 55 dollars per user per month |
| Upper tiers | Not applicable | Varies | UpKeep Professional and Enterprise are quote only; FMX is quote only |
Two details in that table matter more than the headline prices. The first is that the requester side of maintenance software is usually cheap or free while the management side is not. Limble lists unlimited work requesters on its Standard plan and publishes no prices at all, using a calculator instead. FMX prices on the number of users and the number of features enabled, and gives public K to 12 schools pricing based on student enrolment with unlimited users. The second is that the feature people most expect to find, a public portal where requesters submit and track their own requests, is not always in the entry tier: UpKeep lists an external request portal in its Professional plan, which is quote only.
That is the gap worth being deliberate about. A team whose actual problem is that requests arrive without an owner, a status and an acknowledgement is being asked to buy asset registers, parts inventory and preventive maintenance scheduling to get those three things. If the assets are genuinely being managed, that purchase is correct. If the workshop is four people, a building, and a whiteboard that works, intake that carries an owner and a stage without a full asset management platform is the smaller answer, and per person pricing with unlimited submissions means a seasonal spike in requests does not change the bill.
What to change first
Replace the free text location field with a dropdown of buildings and rooms, and add the assigned priority to the automatic acknowledgement so requesters can see the decision instead of guessing at it. Those two changes remove most of the phone calls in both directions within a fortnight. If what remains is that nobody can tell who owns an arriving request, move intake to a tool where the owner and the reply sit on the same screen as the request, such as Halict.
Q1. What should a maintenance request form include?
Location from a controlled list rather than free text, the asset tag where one exists, a description of what stopped working in the requester's own words, a photo upload, access details including whether a key or permission is needed, whether the problem is getting worse, and validated contact details. Priority can be asked for, as long as it is treated as information about the requester rather than a decision.
Q2. Should requesters be able to set the priority themselves?
Yes, as a signal, and no, as a decision. Requester selected urgency skews high because everyone reporting a problem is experiencing it. Priority should be assigned against written criteria covering safety, whether the space still functions, whether damage is spreading, and how many people are affected.
Q3. How many priority levels should a maintenance queue have?
Four works: emergency, urgent, routine and scheduled. Three forces too much into the middle and five creates arguments about the boundary. Whatever the levels, publish the response target for each one and only publish targets the team can actually meet.
Q4. Is a form and a shared mailbox enough for maintenance requests?
It is enough while one person owns every request from arrival to completion. Once two or more people share the queue, requests need a visible owner and a status, because a shared mailbox without assignment reliably produces duplicated work and dropped jobs. A full maintenance platform becomes worth its per user price when assets, spare parts and preventive schedules are being managed rather than just requests.
Q5. How do you stop the same problem being reported three times?
Send an automatic acknowledgement that includes the reference, a copy of the submission, the priority assigned and what happens next. Duplicate reports are almost always a response to silence rather than impatience, and stating the priority back to the requester replaces the unanswered question that drives the second and third report.