Published by
Throne of Profit EditorialReviewed by
William Hassell
Founder & Chief Editor, Throne of Profit
Every ticket that hits your queue looks roughly the same on arrival: a subject line, a client name, a few sentences of frustration. But they are not the same. One is a downed server bleeding a client's whole day; the next is a forgotten password. When both land in the same undifferentiated pile and get picked up in the order they arrived — or worse, in the order that shouts loudest — your best techs spend the morning resetting passwords while the outage waits its turn. Triage isn't about working faster; it's about deciding, in the first sixty seconds, what each ticket is worth and who should touch it — before anyone starts working.
Most MSPs don't have a triage problem because their techs are slow. They have it because there's no consistent front door. Tickets route by luck, priority is assigned by whoever's loudest, and senior engineers get pulled into work a first-line tech could clear in minutes. The chaos isn't volume — it's the absence of a rule that sorts the volume.
INBOUND TICKET
│
▼
[ TRIAGE GATE ] ── classify: impact × urgency
│
├─ P1 outage / many users ──▶ senior + escalate now
├─ P2 one user blocked ─────▶ dispatch queue, SLA clock
├─ P3 routine / request ────▶ first-line tech
└─ P4 low / scheduled ──────▶ batch or backlogOwner symptoms
Senior techs keep getting buried in password resets and printer tickets while real problems wait.
Which ticket gets worked next depends on who's yelling, not what's actually urgent.
Two clients with identical issues get wildly different response times depending on who grabbed the ticket.
Why this happens
The core issue is that classification never happens, so prioritization can't. When a ticket lands with no impact and urgency assigned, every tech who opens the queue has to guess — and guessing is slow, inconsistent, and biased toward whatever feels easy or whoever complained last. A few things compound it: there's no single owner of the queue, so tickets sit unassigned; priority is treated as the client's opinion rather than a business judgment; and skill routing is informal, so work flows to whoever happens to be free rather than whoever should do it. Without a gate at the front, the queue sorts itself by noise.
Common mistakes
Working tickets first-come, first-served, which treats an outage and a how-to question as equals.
Letting the client set the priority, so everything becomes "urgent" and the label stops meaning anything.
No skill-based routing, so senior engineers absorb tier-one work that never should have reached them.
Leaving the queue ownerless, so tickets go unclassified and unassigned until someone stumbles on them.
Confusing response with resolution, so a ticket gets acknowledged fast then stalls with no clock on it.
Business consequences
Bad triage is expensive in two directions at once. Your most costly labor — senior engineers — gets consumed by low-value work, so the margin on your managed contracts quietly erodes while the truly hard problems get slower attention. At the same time, clients experience a service that feels random: sometimes fast, sometimes forgotten, with no relationship between how bad their problem is and how quickly you respond. That inconsistency is what erodes retention, not the occasional tough outage. The owner who builds a real triage gate gets the opposite: urgent issues surface in minutes, routine work clears cheaply on the right people, and response time becomes predictable enough to defend in a client review.
How experienced operators think about it
They separate two decisions that amateurs blur together: how bad is this and who should touch it. Priority is a function of business impact times urgency — how many people are blocked, how much is at stake, how fast it's degrading — and it's set by the MSP, not the client's adjectives. Assignment is a separate question of matching the work to the lowest-cost person who can actually resolve it, escalating only when the work genuinely requires it. The queue has one owner whose job is to keep the front gate clean, so nothing sits unclassified. In their mind, the triage step is not overhead that delays real work — it is the work that makes all the rest efficient.
Practical actions
Define a priority scale everyone uses — three or four levels tied to concrete impact (users affected, business function down), not to how the client phrased it.
Put one owner on the queue. A dispatcher or lead classifies and routes every inbound ticket before techs self-select, so nothing is worked unsorted.
Route by skill tier, not availability. Send routine work to first-line techs by default; reserve senior time for what genuinely needs it, and make escalation a deliberate step.
Set a response clock per priority level and separate it from resolution, so a P1 gets eyes in minutes even if the fix takes hours.
Batch the low-priority work. Group scheduled and non-urgent tickets into set windows instead of letting them interrupt higher-value work all day.
Review misrouted tickets weekly. Every senior-tech password reset is a triage miss worth fixing at the gate, not one ticket at a time.
Questions every owner should ask
If two identical tickets arrived from two clients right now, would they get the same priority and the same response time?
How much senior-tech time last week went to work a first-line tech could have cleared?
Does anyone actually own the queue, or does it sort itself by whoever's loudest?
Frequently asked questions
Should we let clients set the priority on their own tickets?
No — let them describe the impact, but keep the priority decision yours. Clients naturally rate their own problem as urgent, so if the label is theirs, everything becomes a P1 and the scale stops sorting anything. Ask for the facts that drive priority — how many people are affected, what's stopped working, whether it's getting worse — then classify against a consistent scale. That way "high priority" means the same thing across every client and every ticket, which is what makes response times defensible.
Isn't a triage step just extra overhead that slows things down?
It feels like a delay only if you measure the first ticket instead of the whole queue. A sixty-second classification at the front end saves far more downstream: it stops senior techs from being interrupted by low-value work, keeps urgent issues from waiting behind trivial ones, and removes the guessing every tech otherwise does when they open an unsorted pile. The queues that feel chaotic are almost always the ones with no gate — the triage step is what buys back the speed everywhere else.
Related articles
Running a Profitable Managed IT Services Business — the pillar.
Where Your Technicians' Billable Hours Actually Go — the labor cost triage protects.
Balancing Project Work Against Recurring Managed Revenue — protecting managed capacity from interruption.
Why Jobs Take Longer Than You Quoted — the general overrun problem.
Where Time Leaks on a Typical Job — where hidden time goes.
Every business has more decisions than time
Whether you need help solving one problem, evaluating a major opportunity, or making a company-changing decision, Throne of Profit gives you consulting capacity on demand.
Purchase only the consulting capacity you need and use it across Weekly Focus, Strategic Focus, Financial Focus, and ThinkTank engagements.