ITSM vs ITIL: the work, and the guidance for doing it

ITSM is the work. ITIL is one set of guidance for doing it.

That sounds like a definition for an exam, and it is. But I keep meeting the cost of confusing the two in real projects: tenders that ask suppliers to be "ITIL-compliant", tool rollouts sold as "implementing ITIL", and hiring decisions made on a certificate alone. Each one spends money on the wrong thing.

ITSM: what every IT department already does

IT service management (ITSM) is how an organisation designs, delivers, supports and improves the IT services its people rely on. Restoring email when it fails, approving a firewall change, agreeing what "available" means for the point-of-sale system, deciding who answers to the CFO when payroll is late: all of that is ITSM.

Every IT department does ITSM. The only question is whether it does it on purpose, or by habit and heroics.

ITIL: one guidebook for doing it well

ITIL is a framework of guidance for ITSM, published by PeopleCert. It describes how services create value and sets out 34 management practices, such as incident management, problem management, change enablement and service level management, with guiding principles for adapting them.

ITIL doesn't tell you how to configure a tool or how many people to put on a shift. It gives direction, not instructions, and expects you to decide how each part applies to your services and your risk.

The current version is ITIL (Version 5). PeopleCert's current plan is to retire the ITIL 4 exams on 31 December 2027. ITSM itself has no version number: the work carries on whichever edition of the guidance you follow. If your team holds ITIL 4 certificates, the ITIL 4 to ITIL (Version 5) guide covers what to do before that date.

The difference in one table

The software is neither. ServiceNow, Jira Service Management and Freshservice are ITSM tools: they record and route the work. A tool can make good ITSM faster. It can't make bad ITSM good.

Three mistakes that come from mixing them up

1. Asking a supplier to be "ITIL-compliant". There is no such certificate for an organisation, so every bidder will tick yes and none of them can prove it. The clause gives you nothing to hold the supplier to. Ask for what you actually need instead (see the wording below).

2. Calling a tool rollout "implementing ITIL". A new platform goes live with ITIL's practice names on the menus, and the organisation believes it has adopted ITIL. Six months later the same incident is logged for the fifth time and nobody has opened a problem record. The tool was implemented. Service management wasn't.

3. Hiring on the certificate. ITIL Foundation proves someone knows the vocabulary. It doesn't prove they can tell, at 2am with a store estate offline, whether they are looking at an incident or a problem, or that they will open the problem record once the pressure is off. I've written about that gap in why ITIL experience matters more than ITIL knowledge.

Tender wording you can use

Instead of "the supplier shall be ITIL-compliant", write what you will measure:

• The supplier restores service within the agreed time for each priority, measured on the business calendar named in the contract, and reports compliance monthly.
• Every repeat or major incident is referred to problem management, with a named owner, a root cause and dated actions.
• Changes to the services in scope are categorised as standard, normal or emergency, and authorised to match their risk.
• The supplier names one person accountable for each service in scope.
• The service desk staff and managers on the account understand ITIL (an ITIL Foundation certificate is acceptable evidence).

Every line can be checked at a monthly service review. "ITIL-compliant" can't.

Are you doing ITSM, or just owning ITIL?

Five questions. If you answer "no" to two or more, your ITIL training and your ITSM tool are ahead of how your services are actually run.

1. Does every service have one named Service Owner: a person, not a team, who answers for it end to end, vendors included?
2. When the same incident comes back, does someone open a problem record, and is there a date by which the cause will be removed?
3. Is every change put in the right category, so a routine patch isn't waiting for a board and a quarter-end database change still gets a second look?
4. Were your SLA targets designed from what the business needs, and are they measured on your real working week and public holidays?
5. Does something improve every month because of what last month's reports showed?

Question 2 is where most teams slip, and it's where I've seen the biggest gains: structured problem management is how my teams cut recurring incidents by 40%. To check how your team decides between the two records, run a live case through the incident or problem decision tool. It gives a verdict and the reasoning in under a minute, and runs in your browser.

The rule

Judge your ITSM by how your services perform. Use ITIL to improve that performance. Never confuse the certificate, the guidebook or the tool with the work itself.

For a fuller picture across governance, service levels, incidents, change and improvement, take the free ITSM maturity assessment.