A production line goes down at 9 a.m. and a manager marks the ticket Urgent. By noon there are six more Urgent tickets: a flickering hallway light, a request to move a desk, a dripping faucet in a break room. Your two technicians now have seven emergencies and no way to tell which one actually stops work. That’s the situation a real priority scheme is built to prevent, and the trick is building one people will actually follow.
Why “everything is urgent” breaks down
When a work order system lets anyone flag anything as top priority, top priority stops meaning anything. The label inflates. People figure out that the only reliable way to get attention is to mark their request critical, so before long they all do. Within a few weeks half your queue is “high priority” and your technicians are back to using gut feel, which is the exact thing the priority field was supposed to fix.
The cost here isn’t just confusion, it’s misallocated labor. When a desk move and a down compressor carry the same flag, a technician working the queue top to bottom might spend the morning on the desk while the compressor waits and the line stays down. Nobody chose that outcome. The system just never distinguished between the two.
A priority scheme that works needs three things: a small number of levels, written criteria for each, and clear rules about who gets to set them. Miss any one of those and the scheme decays back into “everything is urgent.”
The five-level scheme
Five levels is enough to draw real distinctions without drowning people in choices. With fewer than four you can’t separate a true emergency from a serious-but-not-immediate problem. With more than six, nobody remembers the difference between level 4 and level 5.
This is a scheme that holds up across most facilities and maintenance operations:
Level 1 — Emergency. A safety hazard, an environmental release, or a failure that stops production or core operations right now. A gas leak. A walk-in freezer down with product inside. A fire door that won’t latch. The question to ask is whether something or someone is being harmed, or core work is stopped, while the ticket sits. If so, it’s an emergency. Work starts immediately and other work gets dropped to make room.
Level 2 — High. A failure that will turn into an emergency soon, or one that significantly degrades operations without fully stopping them. One of two parallel pumps has failed, so you’re still running but you’ve lost your redundancy. A walk-in cooler is drifting warm but still in range. Ask whether there’s a real risk of escalation, or a meaningful hit to output or safety margin, if this waits more than a day.
Level 3 — Medium. A genuine problem that needs fixing but isn’t degrading operations or safety today. A conference room HVAC that’s uncomfortable. A backup unit that’s down while the primary runs fine. Most corrective work lands here. It’s the default for “yes, this is broken, no, it isn’t on fire.”
Level 4 — Low. Minor issues, cosmetic problems, and convenience requests. A scuffed wall. A door that sticks. A flickering light in a low-traffic corner. These are real and worth doing. They just don’t compete for the schedule when anything above them is open.
Level 5 — Scheduled. Planned work with a fixed date that isn’t reactive at all: preventive maintenance, a quarterly inspection, a planned upgrade. These don’t get triaged against the reactive queue, because they already have a slot. The distinction matters in both directions. A PM due next Tuesday shouldn’t be jostling for position against a broken cooler, and a broken cooler shouldn’t be allowed to quietly cannibalize the PM schedule either.
The criteria that make levels objective
Most priority schemes drift because the levels are defined by feeling. “High means really important” isn’t a definition, it’s a vibe. Tighten the criteria to observable conditions and the drift slows down a lot.
Two questions do most of the work. First, what’s the impact if this isn’t fixed? Score it as safety, operational, or cosmetic. Safety impact pushes a ticket up hard. Operational impact, meaning does this stop or degrade core work, is the main axis you’re sorting on. Cosmetic-only impact caps a ticket at Low no matter who’s asking. Second, how fast is it getting worse? A stable problem can usually wait. A problem that’s actively degrading, a leak getting bigger or a bearing getting louder or a temperature drifting out of range, climbs a level, because waiting changes the answer.
Plot those two axes against each other and you’ve got a priority matrix. High impact plus fast degradation lands in Emergency, low impact plus stable condition lands in Low. The point of writing it down isn’t the matrix on the wall. It’s that two different people, looking at the same problem, land on the same level. That consistency is what keeps the scheme honest. For the broader habits that make work orders reliable, our work order best practices guide covers the rest of the pipeline.
Who sets the priority
This is the part most teams get wrong, and it’s the part that decides whether the scheme survives contact with reality.
The person who submits a request is the worst possible judge of its priority. Not out of bad faith, but because they only see their own problem. To whoever’s stuck in the warm office, the warm office is the most important thing happening anywhere, and they will sincerely mark it Urgent. So keep the rule simple: requesters describe the problem; they don’t set the priority.
Priority gets set at intake by someone with the whole queue in view, a maintenance coordinator or a supervisor or a lead technician. That person reads the request, applies the criteria, and assigns a level. They can see the down compressor and the warm office at the same time, which makes them the only one positioned to rank the two against each other.
Two adjustments make this work in practice. Give one or two senior people the authority to call a true Emergency without waiting on the coordinator, because a real gas leak shouldn’t sit in an intake queue. And review the priority distribution monthly. If 40% of your tickets are coming in as Emergency or High, your criteria are too loose and the scheme is already drifting back toward “everything is urgent.”
Attaching SLAs to each level
A priority level is a promise about how fast you’ll respond. Without a time attached, “High” is just a word. Put a clock on it and the word becomes a commitment you can measure and, occasionally, miss.
Two different clocks matter here: response time, how long until someone acknowledges and starts, and resolution time, how long until it’s actually fixed. Set both per level, and set them to numbers you can really hit. An SLA you miss constantly is worse than no SLA at all, because it teaches everyone the targets are fiction.
A reasonable starting point, to be tuned to your staffing:
- Emergency — respond within 15 minutes, resolve within 4 hours.
- High — respond within 2 hours, resolve within 24 hours.
- Medium — respond within 1 business day, resolve within 3 to 5 business days.
- Low — respond within 3 business days, resolve as capacity allows.
- Scheduled — governed by the planned date, not a reactive clock.
Track resolution against these targets and you get a real read on whether the scheme works. If you’re routinely blowing the Emergency SLA, you’ve either got too many false emergencies or you’re genuinely understaffed for your load, and the data tells you which. Mean time to repair, broken out by priority level, is the single most useful number to watch. It shows whether your highest-priority work is actually moving faster than the rest, which is the whole point of triage.
But what about the genuinely ambiguous ticket?
Some tickets don’t fit the matrix cleanly, and pretending they do is how a scheme loses credibility. A motor is making a new noise but still running. Is that High, because a bearing might be failing, or Medium, because nothing’s actually broken yet?
When impact is uncertain but plausibly serious, the move is to price in the uncertainty, round up one level, and attach a fast diagnostic step instead of a full repair. Send someone to listen to the motor today, a 20-minute look that settles the ambiguity, rather than either scrambling a full emergency rebuild or letting it sit for a week. The diagnostic itself can carry the higher priority, and the repair that follows gets re-triaged once you actually know what you’re dealing with. The goal was never to guess right the first time. It’s to keep a maybe-serious problem from hiding in the Medium pile until it turns into a definitely-serious one.
Making it stick
A priority scheme is only as good as the consistency behind it. The framework here gives you the structure: five levels, written criteria, intake-set priority, SLAs per level. But it lives or dies on whether the same rules actually get applied every day by every person at intake.
That’s where the system you run it in starts to matter. In TeamWork, priority is a structured field on every work order, so you can filter the queue by level, attach response and resolution targets, and report on whether your highest-priority work is closing faster than the rest. The work order management view turns the framework on this page into a queue your technicians can work top to bottom with some confidence.
If you want to put a real triage framework in front of your team and watch the priority data instead of guessing at it, a 30-day free trial at teamworkcmms.com gives you enough time to run a full month of tickets through it and find where your criteria need tightening.