ITIL 4 in practice: ITSM best practices that stick

ITIL 4 is the most sensible version of ITIL there has been, and also the easiest to leave on paper. Plenty of teams pass the certification, write the process docs, and then run their service desk much the way they did before. The gap is not knowledge. It is the distance between the best practice and the place people actually work.

This is a practical look at what ITIL 4 changed, the best practices that earn their keep, and what it takes to make them stick rather than frame them.

What ITIL 4 actually changed

The older ITIL was a stack of processes. ITIL 4 reorganised the thinking around a few ideas that hold up well:

• Value streams instead of isolated processes. You follow a request from demand to value, across whatever teams it touches, rather than optimising each process in its own silo.
• Guiding principles, the most quoted being focus on value, start where you are, and progress iteratively with feedback. These are deliberately plain. That is the point.
• Practices, not processes. ITIL 4 calls things like incident management and change enablement "practices," signalling they are capabilities you build, not scripts you run.

None of that is controversial. The trouble starts when you try to live it.

The best practices that actually matter

Strip ITIL 4 down to what changes daily life and a short list remains:

• Focus on value. Every ticket, change, and report should connect to an outcome someone cares about. If it does not, stop doing it.
• Start where you are. Do not rebuild service management from zero. Measure what you have honestly before you change it.
• Keep it simple. Remove steps, approvals, and statuses that exist out of habit. Complexity is where adoption goes to die.
• Make work visible. People should be able to see status without asking. Hidden work breeds duplicate tickets and chase emails.

These are not exciting. They are the ones that move the numbers.

Why best practice usually dies on adoption

Here is the uncomfortable pattern. A team does the work properly. The processes are clean, the principles are sound, the training happened. And six months later half the requests still arrive as a Teams message or a tap on the shoulder, because the official route asks people to leave their work, open another system, and re-enter context that already existed.

Best practice does not fail because it is wrong. It fails because it sits too far away. "Focus on value" and "keep it simple" are hard to honour when the tool itself adds a context switch to every interaction.

Making ITIL 4 stick inside Microsoft 365

The reliable way to close that gap is to run the practices where the work already happens. For most organisations that is Microsoft 365, and it lines up with ITIL 4 better than it first appears:

• Focus on value is easier when requests are raised in Teams, in context, so the actual need is visible rather than flattened into a form.
• Start where you are is literal: you are already in Microsoft. You extend it rather than bolt on a parallel platform.
• Keep it simple holds when there is no second system to reconcile, no connectors to maintain, no duplicate data store.
• Make work visible comes naturally when status, tasks, and approvals live in Teams and SharePoint, on data that never left the tenant.

The practices stay exactly as ITIL 4 describes them. What changes is that they run in the flow of work instead of beside it, which is the only place adoption is ever won.

A short, honest checklist

If you want ITIL 4 to be behaviour rather than documentation, ask:

• Can someone raise and track a request without leaving the tools they already use all day?
• Have you removed at least as many steps as you have added this year?
• Does each practice connect to an outcome a non-IT person would recognise?

Get those three right and the framework starts paying for itself. Get them wrong and you have a very well-documented service desk that people quietly avoid.

The bottom line

ITIL 4's guiding principles are plain on purpose, and that is exactly why they are easy to write down and hard to live. The framework does not fail on the page. It fails at the point of contact, when the official route asks people to leave their work and start over somewhere else.

Closing that gap is less about better documentation and more about location. Practices that run inside the tools people already use, instead of beside them, are the ones that survive past the first six months.