You can usually feel it before you can prove it. The Service Desk is busy, but it is not just volume. It is the type of busy that drains everyone. Tickets bouncing, customers chasing, repeat issues coming back around, and a constant sense that you are one absence away from a bad week.
That’s the moment most MSPs start talking about “maturity”. Not because they want a framework, it’s because they want the Service Desk to behave consistently, and they want a clear way to decide what to fix next.
Service Maturity, in plain English, is understanding how capable your service is at delivering what you promise, right now, and having clear criteria for what needs to improve. It is not a vanity score. It is a practical baseline, a direction of travel, and a way to build confidence in the service without adding chaos (or headcount).
Service Maturity is capability you can improve on purpose, not performance you hope stays stable. The goal isn’t to be SML5 everywhere, it’s to be mature enough for the outcomes and risk you’re carrying.
Operational Maturity is the bigger picture. How well the business runs end-to-end, leadership cadence, governance, decision-making, tooling strategy, people management. Service Maturity is narrower and more useful day-to-day. It is the maturity of a practice inside Service Delivery, things like Incident, Change, onboarding, and customer communications.
This matters because you can improve the business and still have an immature practice that keeps creating churn risk. And you can tidy up one practice and still have wider operational issues that keep derailing progress. They are connected, but they are not the same lever.
Most maturity models follow a similar five-level pattern. Labels vary, but behaviours do not. Here is the grounded version for MSPs, using the level names that actually help in the real world.
At SML1, the practice exists mostly in people’s heads. Work gets done, but it’s inconsistent and heavily dependent on who’s on shift. When pressure hits, the “process” disappears.
What breaks at SML1 is predictability. Customers get different answers. Engineers do their own thing. Ownership is fuzzy. You can’t reliably explain why something happened, and you definitely can’t prove you’ve fixed it.
What needs to be in place to move forward is basic structure. Clear scope for the practice. A minimum set of steps people follow. One named owner who can make decisions.
Example: if service delivery falls apart when one person’s away, it’s SML1.
At SML2, you’ve got the shape of a practice. There are steps, templates, maybe even a checklist. The problem is behaviour. It’s followed most of the time, but not when things get busy, which is exactly when it matters.
What breaks at SML2 is consistency. People skip steps to go faster, then spend longer cleaning up. Reporting tends to measure activity rather than outcomes. Customers feel the wobble because the experience is not stable.
To move forward, you need the minimum viable standard written down in plain English, training that uses real examples, and tooling that nudges people into the right flow, so it’s easier to do it properly than to bypass it.
Example: Processes and ways of working aren’t being followed when you’ve got a P1 on the go.
At SML3, the practice behaves the same way regardless of who is working. The steps are documented, roles are clear, and the team understands what “good” looks like. Customers start to notice stability.
What breaks at SML3 is usually measurement and follow-through. You can deliver the practice, but you cannot always prove performance without scrambling. Improvement still tends to be reactive “we’ll fix it after it goes wrong”.
To move forward, you need reliable measures, not just reports, and a cadence of Continual Service Improvement that turns recurring pain into planned work.
Example: You may find that you occasionally have no specialist knowledge at times, there’s no internal or external reporting of any metrics, or training takes place when you think about it rather than having a plan in place to meet needs going forward.
At SML4, you aren’t just delivering the practice - you are managing it. Performance is measurable. Decisions are less emotional and more evidence led. You can see trends, spot repeat issues, and prioritise improvements with confidence.
What breaks at SML4 is often speed of improvement. The practice is stable, but it can still be heavy. Manual steps creep in. People accept pain as “normal” because the service is no longer on fire.
To move forward, you need to reduce friction. Smarter automation and tooling. Better knowledge. Proactive work that prevents tickets rather than just handling them.
Example: You’ve got a couple of automations in place, but there’s still some way to go before all work that can be automated is in place.
At SML5, the practice doesn’t just work - it improves continuously. Automation removes repetitive work. Analytics highlight issues before customers notice. Knowledge deflects predictable demand. The Service Desk gets breathing room because the service is designed to be stable.
The risk at SML5 is complacency. Optimised practices can drift if improvement becomes “someone’s job” rather than “how we operate”.
Staying at SML5 means keeping the improvement cadence alive, reviewing automation and knowledge regularly, and treating customer feedback as a signal, not a nuisance.
Here’s a short baseline you can use for any practice (Incident, Change, Request, etc.). It’s intentionally simple. The goal is to spot where you are stuck and what to improve next.
Ask yourself:
If you can’t answer most of those with confidence, you have found your starting point, and that’s a good thing, because now you’re not guessing.
The win is not “being Optimised”. The win is knowing what to fix next and proving progress. It’s not about chasing a label, it’s about behaviour. When a practice behaves consistently, everything gets calmer - fewer surprises, fewer escalations, fewer “how did this happen again?” moments. The Desk gets space to do proper Service Improvement work, and customers feel the difference.
If you are early doors, do not beat yourself up, SML1 and SML2 are not failures – they’re starting points. The only real mistake is pretending you are further along than you are, then wondering why churn risk keeps showing up as a surprise.
If you want to baseline one practice and get a clear view of your current Service Maturity, I’m running a small number of MSP Service Maturity pilot sessions while we test the module in the real world. We’ll spend an hour working through one practice together, then I’ll send you a short report with your current level, the key gaps, and a practical action plan. You’ll get value whether you choose to use Oprising or not.