ITIL has 34 practices. Your MSP probably needs about 7 of them.
The problem is, most people try to implement all 34 and end up with a bureaucratic mess that slows everything down instead of improving it. They get so bogged down in process documentation and approval workflows that they forget the whole point was to deliver better service to customers.
I've seen MSPs spend months building elaborate change advisory boards for a five-person team. I've watched Service Desk managers create incident categorisation schemes so complex that techs spend more time classifying tickets than fixing them. And don't get me started on the MSPs who think they need a full-blown service catalogue when half their customers just want their email to work.
Here's the thing about ITIL: it was designed for large enterprise IT departments with hundreds of staff, complex infrastructure, and rigid governance requirements. Your 15-person MSP serving 50 small businesses is not IBM's IT department. You don't need the same level of process overhead.
With the majority of the MSP space comprising businesses with fewer than 50 people - making up over 50% of the market - these smaller MSPs need to be slick. They can't afford the bureaucratic overhead of full ITIL implementation, but they also can't afford to run chaotic operations.
The most overlooked ITIL practice? Continual Service Improvement. It's the one that ties everything together, but it's also the hardest to implement because everything can't be done on day one. There's always a need for ongoing improvement, which is why having a structured approach to CSI is crucial (shameless plug: this is exactly what Oprising was built to solve for MSPs).
But that doesn't mean ITIL is useless for MSPs. Quite the opposite. The principles are brilliant - it's the implementation that often goes wrong.
Most MSPs approach ITIL like it's an all-or-nothing proposition. They either ignore it completely ("We're too small for that corporate nonsense") or try to implement everything at once ("We need to be ITIL-compliant").
Both approaches miss the point.
The "too small" crowd ends up with inconsistent processes, no clear escalation paths, and the same problems happening over and over again because there's no structured approach to learning from incidents.
The "implement everything" crowd gets buried under process documentation, approval workflows, and governance structures that are completely disproportionate to their business size and complexity.
The sweet spot is cherry-picking the ITIL practices that actually solve problems you have, and implementing them in a way that fits your MSP's reality.
After 25 years in IT operations and working with thousands of MSPs, here are the ITIL practices that consistently add value:
What it solves: Consistent response to service disruptions, clear escalation paths, and proper communication with customers.
MSP reality: You're already doing incident management - you just might not be doing it consistently. The key is standardising how you record, escalate, and communicate about incidents.
Keep it simple: Standard incident record template, clear escalation triggers (time-based and impact-based), and customer communication templates. That's it.
What it solves: Stopping the same incidents from happening repeatedly by addressing root causes.
MSP reality: You're probably brilliant at firefighting but less good at preventing the fires in the first place. Problem management is about stepping back and asking "Why did this happen?" instead of just "How do we fix it?"
Keep it simple: Monthly review of recurring incidents, root cause analysis for major problems, and a simple action log to track preventive measures.
What it solves: Reducing the risk of changes causing new problems, and having a rollback plan when things go wrong.
MSP reality: Changes are happening constantly in your environment. The question isn't whether to manage them, but how to manage them without slowing everything down.
Keep it simple: Risk-based approach to change approval (emergency, standard, normal), simple change record template, and clear rollback procedures. No need for a change advisory board - just sensible approval workflows.
What it solves: Handling routine requests efficiently and consistently, separate from incident resolution.
MSP reality: Not everything that comes into your Service Desk is an incident. Password resets, access requests, and routine maintenance like a single software install for one user are service requests that can be standardised and streamlined.
Keep it simple: Identify your most common service requests, create standard procedures for fulfilling them, and track completion times separately from incident resolution.
What it solves: Capturing and sharing solutions so you're not solving the same problems repeatedly, and new team members can get up to speed quickly.
MSP reality: Your best technician has all the solutions in their head. When they're on holiday, everything takes twice as long. Knowledge management is about getting that expertise documented and accessible.
Keep it simple: Solution database linked to your PSA, or even Sharepoint, regular knowledge article reviews, and incentives for techs to document solutions as they work.
What it solves: Proactive identification of issues before they become incidents, and automated response to routine events.
MSP reality: You're probably already monitoring systems - the question is whether you're responding to monitoring data effectively or just drowning in alerts.
Keep it simple: Clear escalation rules for different types of alerts, automated responses for routine events, and regular review of monitoring effectiveness.
What it solves: Ensuring your service delivery keeps getting better over time, rather than just maintaining the status quo.
MSP reality: This is the most overlooked ITIL practice, but arguably the most important. You can implement incident management, problem management, and change management perfectly, but without CSI, you'll never know if they're actually improving your service delivery or just creating process overhead.
Keep it simple: Regular assessment of your current state, structured action planning with accountability, and measurable progress tracking. The key is having a systematic approach rather than ad-hoc improvements that get forgotten in the daily firefighting (shameless plug: this is exactly what Oprising was built to solve for MSPs).
The key to successful ITIL implementation for MSPs is starting small and building gradually:
Start with Continual Improvement. This gives you the framework to assess what you're doing well and what needs work. Without CSI, you're just implementing processes for the sake of it.
Add Incident Management once you understand your current state. Get consistent at recording, escalating, and communicating about incidents. This alone will improve customer satisfaction and team efficiency.
Layer in Problem Management gradually. Start reviewing recurring incidents monthly and implementing preventive actions.
Build Change Management around your biggest risks. Begin with high-risk changes requiring approval, then expand to cover routine changes with standard procedures.
Implement Service Request Management when you're ready to optimise. Once incident handling is smooth, start separating and streamlining routine requests.
Build Knowledge Management organically. Don't try to document everything at once. Start capturing solutions as you work and build the knowledge base over time.
Add Monitoring and Event Management last. This requires the most technical setup and works best when your other processes are already running smoothly.
The biggest challenge for MSPs is implementing ITIL practices without creating bureaucratic overhead. Here's how to keep it lean:
Use your existing tools. Don't buy new software for ITIL compliance. Adapt your current PSA, documentation tools, and communication platforms.
Focus on outcomes, not documentation. The goal is better service delivery, not perfect process documentation. Document what you need to ensure consistency, but don't document for the sake of it.
Keep approval workflows simple. A quick Teams approval or email confirmation is often sufficient. You don't need formal change advisory boards for routine changes.
Automate where possible. Use your RMM tools, PSA, and monitoring platforms to reduce manual process overhead.
Review and adapt regularly. ITIL processes should evolve with your business. What works for a 5-person MSP won't work for a 25-person MSP.
The beauty of ITIL for MSPs isn't in following every practice to the letter - it's in using the framework to think systematically about service delivery.
Instead of asking "Are we ITIL-compliant?" ask "Are we delivering consistent, reliable service to our customers?"
Instead of implementing every ITIL practice, ask "Which of these practices would solve actual problems we're having?"
Instead of creating perfect process documentation, ask "What's the minimum documentation needed to ensure consistency when I'm not here?"
ITIL should make your MSP more efficient and your customers happier. If it's doing the opposite, you're probably implementing too much of it.
You possibly don't require full ITIL implementation - it requires thoughtful adoption of the practices that actually improve your service delivery.
Cherry-pick what works, ignore what doesn't, and focus on the outcomes that matter: faster resolution times, fewer recurring problems, and happier customers.
The goal isn't ITIL compliance - it's service excellence.
Ready to move beyond basic metrics? Start your 7-day trial of Oprising and transform how you approach Service Improvement, or book a demo to see how our platform helps you focus on what matters.
Visit oprising.com to learn more or contact us at hello@oprising.com / (+44) 0333 358 3786.
Remember: Success isn't about working harder—it's about working smarter. Focus on what matters, ditch the chaos, and get stuff done with a structured approach to Service Improvement.