Picture a Monday where every client ticket arrives flagged urgent, and the techs spend the morning triaging instead of fixing. A single user can't open Outlook, so it's 'critical'. A password reset is 'critical'. A server is down, so that's 'critical' too. Your queue becomes a pile of emergencies, which means none of them are.
You fix this by making 'critical' rare and verified. Define P1 through P4 in writing, force phone-in verification for P1s, cap what email and portal can submit, and then hold clients and techs to the rule. It won't take a tooling overhaul. It takes a policy and a spine.
Your Queue Is a Mess Because 'Critical' Means Nothing
Say you have a client where every ticket is 'urgent'. Their employees email in with subject lines screaming about deadlines, and each one lands at the top of your board. Your techs have learned that 'urgent' is noise, so a real outage gets the same shrug as a font request.
The problem is a free-form urgent flag. It hands the priority decision to the person typing the ticket, and that person is not the one who has to drop everything to work it. My view: you take that decision back and put it behind a verification step. The question is what each priority actually means, and the answer is the next section.
Set Priorities That Survive Contact With Clients
Write the definitions down and make them concrete. Keep it to four levels, each one something a tech can recognize without a flowchart.
| Priority | Definition | How It's Flagged |
|---|---|---|
| P1 | Total outage or security incident | Must be phoned in |
| P2 | Partial outage or a VIP user blocked | Portal or phone |
| P3 | Standard work | Email or portal |
| P4 | Request or change | Email or portal |
Take a client where every email used to come in marked 'urgent'. An email about a single user being slow? That's P3, not P1. The network is down for the whole office? That's P1, and it arrives by phone, not by a flag on a message you'll read in twenty minutes.
Once the definitions are settled, the question is how you force verification so a real P1 can't hide in an email. That's the next section.
Make Verification a Rule, Not a Suggestion
A P1 gets phoned in for an L1 or dispatcher to judge. That's the whole point. The email default becomes P3. The portal caps at P2, with no free-form urgent flag, so clients pick from a short list instead of a blank box.
Here's how it plays out. Their admin tries to email in a P1 about a slow printer. The email is auto-assigned P3. An hour later the office network actually drops, and the admin calls. The L1 hears 'nobody can reach the server' and files the real P1. The slow printer waits its turn.
This only works when someone can actually answer the phone during business hours. If your shop has one tech and they're already on a call, a phoned-in P1 waits anyway, which is worse than an email triage. If that's your situation, you need a fallback, and we'll get to it. First, the harder question: how do you get clients and techs to accept the rule in the first place?
Hold Clients and Techs to the Rule Without Losing Friends
You communicate the rule in writing: a one-page policy that says what each priority means, how it gets flagged, and why you're doing this. The why matters. You're not trying to dodge their work. You're protecting their genuine emergencies, so a real outage gets a real response.
Then you back your techs. Management must back techs when clients complain about not getting 'critical' status. If a client calls your service manager and gets their ticket bumped anyway, the rule is dead. The client learned that complaining works, and your tech just learned their judgment doesn't count.
Track the frequency of P1s. If one client is calling in an outage every week, that's a pattern worth a conversation. It's either a real infrastructure problem or a definition problem, and you can't tell until you look at the trend. Send the one-page policy, and the office manager starts calling only when the network is truly down. The rule holds. But what happens when it doesn't?
When the Rule Breaks: What to Do Instead
The rule breaks under conditions you can name ahead of time. No one covers the phone during a thin shift, so P1s wait and escalate anyway. A client with real negotiating weight demands treatment outside the rule. Techs reclassify tickets upward under pressure from a loud voice. Or your contract promises response times that a verified P1 process can't meet.
When that happens, you don't abandon the system. You add a fallback. If coverage is thin, rotate a hot seat: one tech takes all incoming tickets for a half-day shift, handles what's quick, and escalates whatever they can't resolve in 30 minutes. That keeps same-day work moving without letting anyone mark everything urgent. Use this for evening shifts, where there's only one person on call.
Two other options work when you need to keep the visible priority controlled. Give clients a limited set of priority options in the portal, like 'time sensitive' instead of a free-form urgent flag. Or mark VIP contacts internally with an asterisk and auto-prioritize their tickets without telling clients, so the VIP's ticket lands at the top of the queue without starting a public arms race.
On Monday, draft your priority matrix and send it to one client as a test. Watch for a week. Then roll it out to the rest. It's a test, not a promise, so watch what actually happens with your clients and your techs before you commit to the rollout pace. Give it two weeks, and the word 'critical' starts meaning something again.
mspoutpost.com/articles/make-critical-mean-something-again
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
