What MSP Ticket Triage Really Costs, and Why the Vendor Math Is Wrong

The number every vendor computes for you

You run a managed service provider and your level one queue is the thing that keeps you up. Somebody has to read every ticket, decide what it is, decide who gets it, and set a priority before an engineer touches it. That somebody is usually your best dispatcher or your most patient junior tech, and either way it is a person you would rather have doing something else.

So you search for what that work costs per technician per week, and page one answers in unison. Minutes per ticket, times tickets per day, times a loaded hourly rate. Then a product that removes the minutes.

The figures cluster tightly because they are derived the same way. Mizo, an AI triage vendor, puts the manual read-and-route step at two to four minutes for a clear ticket and five to ten for an ambiguous one. At 75 to 100 tickets a day that becomes three to five hours of daily triage labour, and at a 25 dollar hourly rate for a level one tech, roughly 500 dollars a week or 26,000 dollars a year. A UK vendor, DaemonLayer, runs the same arithmetic in pounds: 800 tickets a month at four minutes each is 53 hours, just over a thousand pounds a month before misrouting and interruption, and a fully loaded eight to fourteen pounds per ticket once those are counted.

Those are not dishonest numbers. We have sat in dispatch rooms and watched tickets take about that long. The problem is the sentence that follows them in every one of those articles, which is that a tool priced at five to 25 dollars per technician per month will remove the cost.

Look at the gap between those two figures. A problem described as 26,000 dollars a year per tech, solved for 300 dollars a year per tech. When a stated cost is eighty times the stated remedy, the cost is doing marketing work, not accounting work. Somebody has inflated the problem, or the remedy does not solve the problem as described. In our experience it is the second one, and the reason is buried in an assumption nobody writes down.

The assumption is that the tickets are real

Every triage cost model treats ticket volume as a fixed input. Tickets arrive at a rate, each one costs minutes, therefore the minutes are the cost. It is the same shape as the exception-handling math we wrote about in manufacturing exception handling: count the items, price the item, buy something that handles items faster.

That model is correct only if every ticket in the queue is a legitimate request that deserved to exist. In the MSPs we have looked at closely, it is not. A large share of the week's triage load is self-inflicted, and it comes from a short list of causes the owner could already name if asked.

Untuned RMM alerts. Your remote monitoring platform ships with default thresholds, and for most shops nobody has revisited them since onboarding. The result is a stream of disk-space warnings on servers with 30 percent free, service-restart notices for services that restart themselves, and offline alerts for laptops that are simply closed. Every one of those lands in the queue and gets triaged by a human. RMM vendors themselves advertise 90 percent alert-noise reduction from tuning, which is another way of saying that nine in ten alerts in an untuned environment are noise. That is not a triage problem. It is a configuration debt that triage is paying interest on.

Password resets that exist because a client declined single sign-on. The industry benchmark, cited by Gartner and HDI and repeated by every identity vendor since, is that password resets make up somewhere between 20 and 50 percent of help desk volume, at a fully loaded cost of around 70 dollars per reset. Most MSPs have at least one client who was quoted SSO or self-service reset, said no, and now generates a fifth of that client's tickets from a decision made in a budget meeting two years ago. Automating the triage of those tickets gets each one to the right tech faster. It does not make the next one not arrive.

Repeat tickets from endpoints that should have been reimaged. Every service desk has a handful of machines that appear in the queue weekly. The same three laptops, the same aging print server, the same workstation with the driver conflict nobody wants to spend a Saturday on. Each visit is a legitimate ticket by the PSA's definition. Collectively they are one ticket, unresolved, counted many times.

Add those three together and it is common for a third to a half of the weekly triage load to trace back to causes the MSP already knows about. That is the number the vendor arithmetic cannot see, because the vendor is selling the minutes and has no interest in whether the ticket deserved them.

Why automating this makes it worse, not better

The obvious objection is that faster triage of a junk ticket still saves the minutes, so what is the harm. There are two.

The first is that it removes the pain that would have forced the fix. A dispatcher drowning in RMM noise complains, and eventually somebody spends an afternoon on thresholds. An AI triage tool that silently routes 200 noise alerts a day to the right queue makes the noise invisible to management and permanent in the environment. You have automated the symptom and protected the cause. This is the same trap we described in when AI is the wrong answer to an operations problem, and MSPs are unusually exposed to it because the tooling is cheap and the pain is visible.

The second is that triage is not where the expensive minutes are. Triage is the two to four minutes at the front. Resolution is the 20, 40 or 90 minutes after. A junk ticket that is triaged perfectly still consumes an engineer's resolution time, plus the context-switch cost that DaemonLayer is right to insist on counting. Mizo's own figure is that 15 to 25 percent of manually triaged tickets get reassigned at least once, adding an average of 47 minutes each. Reassignments are disproportionately the ambiguous tickets, and the ambiguous tickets are disproportionately the noise. The tool improves routing accuracy on tickets whose correct routing is the recycling bin.

Which is to say: buy a faster route to the same wall and you arrive at the wall faster. That is the whole joke, and it is on nobody, because we have watched capable operators make exactly this purchase.

The denominator that actually matters

Triage cost per technician is a real number and you should know it. It is just the wrong denominator for a buying decision. The number worth having is what share of last week's tickets came from a cause you already know about.

Getting that number does not require software. It requires somebody to pull one week of closed tickets from the PSA and tag each one with a cause rather than a category. Not "alert" but "disk threshold on a server with headroom." Not "password" but "password at a client without self-service reset." Not "workstation" but "the Henderson laptop, again." The categories your PSA already has are the vendor's categories, and they are built to describe work, not to explain why the work exists.

When we do this exercise with an MSP the result is usually uncomfortable in a useful way. The owner discovers that the triage problem they were pricing at 26,000 dollars a year is, on inspection, a few hours of RMM threshold work, a harder conversation with two clients about SSO, and a reimaging schedule that would have paid for itself last quarter. What remains after those three is a queue small enough that a five dollar per tech per month triage tool is a perfectly sensible purchase for it. Sometimes a very good one. The order matters, and the order is never the one the vendor proposes, for reasons we laid out in the automation ROI math vendors show you, recalculated.

There is a second-order benefit to the cause-tagged week that no triage tool provides. It tells you which clients are unprofitable and why. An MSP's margin per client is mostly a function of ticket volume against a fixed monthly fee, and the clients generating the self-inflicted volume are the ones eating the margin. The refusal to adopt SSO, the unreplaced hardware, the environment that was never remediated at onboarding: these are pricing conversations disguised as support tickets. Triage automation turns them into cheaper support tickets. The cause analysis turns them into a renewal conversation with a number attached.

What we would ask before you sign

If the vendor demo is already scheduled, go to it. Ask three things.

Ask what share of your current volume the tool expects to route differently from how your dispatcher routes it today. If the answer is small, you are paying for speed on tickets that were never the bottleneck.

Ask whether the tool can tell you, after a month, which sources of tickets it is routing most often. Some can. If it can, it becomes a diagnostic as much as a triage engine, and that changes its value considerably.

Ask what happens to the alert noise. If the answer is that the tool classifies it and routes it to a low-priority queue, understand that you are paying monthly to warehouse a problem that a threshold change would delete.

None of those questions require a consultant to ask. What does is the work underneath them: pulling the week, tagging the causes, putting a number on each client's self-inflicted volume, and deciding which of the resulting conversations to have first. That is a week inside your PSA and your RMM, and it cannot be done from an article.

If your queue is growing faster than your headcount and every vendor is quoting you the same arithmetic, talk to us before you buy the minutes back. We would rather find out first which of the tickets deserved to exist.