When every request is marked critical, ticket priority levels stop distinguishing a single blocked user from an office outage. Set each level by business impact and verify claimed emergencies before dispatching work.
I'd start by defining P1 through P4 in writing, requiring phone verification for P1s, and limiting what email and the portal can submit. Agree the routes with clients and assign someone to answer or cover the phone. 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.
A free-form urgent flag lets the person submitting a ticket set its apparent priority. Add a verification step so the desk can assess the business impact against the agreed priority definitions.
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.
Make Verification a Rule, Not a Suggestion
In this intake model, a claimed P1 is phoned in for an L1 or dispatcher to assess. Email defaults to P3, and the portal offers choices up to P2. Confirm these routes with clients before changing the process.
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.
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.
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.
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.
Draft the priority matrix and test it with one client. Review how tickets were classified and whether the response matched the impact before rolling it out further.
mspoutpost.com/articles/ticket-priority-levels-keep-critical-tickets-verified
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.
