MSP performance and quality: why ticket counts mislead you

Measuring MSP quality sounds obvious, yet in practice almost every appraisal still hangs on tickets and written hours. At the front you sell value, and internally you judge people on volume. Those two worlds clash harder than most owners want to admit, and the gap widens every quarter as AI and automation take over the simple tickets.

A familiar scenario: on the client side you are moving towards a value-based model. Managed contracts, fixed monthly fees, taking work off their hands. Ninety per cent of your client portfolio is no longer on time and materials. And still, the half-yearly conversation with your engineer is about how many tickets he cleared and how many hours he was billable. That is not a small administrative detail. It is a fundamental mismatch between what you sell and what you steer on.

The second layer under that problem is subtler. An engineer who handles 80% of his tickets quickly scores excellently on paper. But if part of that fast work comes back three weeks later as a bigger problem, you have measured productivity that was not value. You rewarded what you will have to fix again next month. And in a world where AI increasingly picks up the simple tickets itself, exactly that kind of work is what remains: the context, the judgement call, the conversation with the client.

Then there is the leadership question. If you as an owner cannot make clear what quality means in concrete behaviour, your management team is guessing. And the team below them even more so. Vague terms such as responsibility and flexibility end up on the whiteboard, but nobody can say which behaviour goes with them at half past nine on a Monday morning.

From ticket counter to quality mix

What starts to work at MSPs that take this shift seriously is not a new tool and not a fourth dashboard. It is an explicit decision that output is a mix of quantity and quality, and that quality weighs more. That sounds soft, but it has direct operational consequences. You measure metrics over a longer period, not per sprint or per month. And you accept that speed on its own says nothing until you know whether the fix holds.

In practice, for most MSPs, that means looking beyond ticket volume at repeat incidents within 30 or 60 days on the same infrastructure. At margin development per service contract over a year. At how often an engineer escalates a problem to a colleague, and whether that drops after coaching. Not because those figures are the truth on their own, but because together they give a picture that one ticket KPI never can.

The second shift sits in frequency. An annual or half-yearly appraisal no longer fits a trade that changes every quarter through new tooling, new threats and new client expectations. You want to adjust continuously, not look back at January in June. That asks for short check-ins of fifteen minutes a month in which you discuss not only numbers but concrete behaviour.

And that third layer, the human skills, deserves a place in the model. How well does someone handle a difficult conversation with an angry client? Does a junior dare to say a deadline is not achievable? Does someone pick up new tooling adaptively, or stay stuck in the old way? Those are things you can assess, provided you make them concrete.

What measuring quality looks like in practice

A workable setup we see more and more consists of four blocks that come round every quarter. Block one: output quality. That covers first-time-fix percentages, repeat incidents per client per quarter, and average resolution time split by complexity. Not one number, but three that together tell you whether someone works fast and durably. An engineer who reaches 95% first-time-fix but produces two repeat incidents a month scores differently from someone at 80% with zero repeats. That distinction only surfaces if you are willing to put the figures side by side instead of averaging them into one dashboard number nobody can interpret any more.

Block two: client impact. How many contact moments per contract per quarter, which type (incident, advice, proactive), and the trend in client feedback. Many MSPs have an NPS figure here, but rarely trace it back to individual engineers. That is exactly where the learning sits. If three clients in one quarter name the same engineer specifically as a strength or a weak point, that is harder appraisal material than any timesheet. A practical way to pick this up: have your account managers note two names after each quarterly client review, one positive and one point of attention. Within a year you have a picture no ticket system can give you.

Behaviour indicators alongside the numbers

Block three is where it usually goes wrong: concrete behaviour. If you want to assess people on core values such as ownership or collaboration, you have to define three to five observable behaviours per value. Ownership then becomes, for example: reporting back to the client within 24 hours, bringing in second line yourself without waiting for management, and proposing a new schedule yourself when a deadline slips. That can be discussed. "He has ownership" cannot. And the useful part is this: once you make it that concrete, an engineer can assess himself before you say anything. That takes the tension out of the conversation and moves it from judgement to development.

Block four is about adaptiveness, and that is the block most MSPs do not even have yet. How quickly does someone pick up new tooling? Does someone experiment independently with AI support in daily work, or wait until a training comes along? You cannot capture this kind of behaviour in figures, but you can in observations you record each quarter. The engineers who will make the difference in three years are not the ones clearing the most tickets, but the ones who pick up new context fastest. That also means revising your hiring profile: whoever you recruit now purely on technical depth risks getting stuck in two years when the nature of the work shifts.

How to introduce this model without resistance

The rollout matters at least as much as the model. If you announce in tomorrow's team meeting that tickets no longer count, you will lose your senior engineers within a quarter. They have worked hard for years inside the old system and feel ambushed, rightly so. What does work is a parallel track: you keep the existing KPIs visible, add one new block per quarter and discuss it explicitly in the one-to-ones. After three quarters everyone understands how the new model works and you can quietly move the old dashboard into the background.

One last practical note: this model only works if you as an owner are prepared to steer differently yourself. If you ask about ticket volume and billable hours in every management meeting, your team hears that signal louder than any new appraisal form. The shift to quality starts in the boardroom, not in HR. And it takes at least two to three quarters before you see anything of it in the numbers, so patience is part of the deal.

The MSPs that genuinely move to a value-based model over the next three years are the ones that have already stopped judging people internally on volume. Not because tickets do not count, but because they tell you too little. Anyone waiting for the perfect XLA structure before adjusting their internal appraisal stays stuck in a model everyone knows is out of date. Start with one team, one quarter, four blocks. That is enough to see whether it works.