The ITSM maturity model and self-assessment

Maturity models are useful and easy to misuse. They give a shared language for how developed your service management is. They are easy to misuse because "we need to reach the next level" is a convenient reason to buy more tooling, whether or not tooling is what is holding you back. This post covers the model, what each level feels like, a short self-assessment and the trap to avoid.

The levels

Most ITSM maturity models, including the ones Gartner and ITIL-aligned assessments use, describe roughly five stages:

• Initial. Service management is ad hoc, and things get fixed because someone knows who to ask. Little is recorded, so little is repeatable.
• Repeatable. Basic processes exist for the common cases and incidents mostly get logged, but results depend heavily on individuals.
• Defined. Processes are documented and roles are clear, so the same request gets handled the same way regardless of who picks it up.
• Measured. You manage with data: SLAs, trends and quality are tracked, and decisions follow what the numbers show.
• Optimised. Improvement is continuous and largely proactive: recurring issues are prevented, routine work is automated and changes follow the evidence.

The levels are cumulative, so you do not skip one.

What each level feels like

The labels are abstract, so here is the lived version. At initial, a key person on holiday is a risk. At repeatable, things work until they are busy, then they fall back to chat and shoulder-taps. At defined, a new hire can be productive quickly because the way things are done is written down and followed.

At measured, you can answer "are we getting better or worse?" with a number instead of an opinion. At optimised, you spend more time preventing incidents than fighting them.

Where most teams sit

Most organisations sit between repeatable and defined, and quietly suspect they are less mature than their documentation suggests.

A self-assessment you can run

You do not need a consultant for a first read. Answer these honestly:

• If your best service desk person left tomorrow, how much would break?
• Does the same type of request get handled the same way regardless of who takes it?
• Can you show, with data, whether service quality improved or declined this quarter?
• What share of requests arrive through the official route versus a chat or a tap on the shoulder?
• When something recurs, do you fix the cause, or just the instance again?

The pattern in your answers places you better than any scorecard. The fourth question is the revealing one, because adoption limits most teams.

The trap: confusing tooling with maturity

It is tempting to read "we are stuck at repeatable" as "we need a more powerful platform." Usually the platform is not what limits you. Plenty of organisations run capable, expensive ITSM tools and remain at repeatable because adoption and data quality hold them back. If half your requests never enter the system, a more sophisticated platform will not move you to measured, because you cannot manage with data you do not have.

What moves you up

Real maturity gains come from closing the gap between the process and the work. When logging a request is effortless because it happens where people already are, adoption rises. Complete data follows, and then you can manage by evidence, which is the jump from defined to measured. When the work and the data live in one place, automation and prevention become realistic, which is the jump to optimised.

That is why running service management inside the environment people already use, rather than beside it, tends to move maturity more than another tool does. Maturity comes from the work and the record finally being in the same place.

The bottom line

Maturity models give you a shared language, and they are most useful when you are honest about what holds you back. For most organisations that is adoption and data quality. More features on a separate platform rarely change that.

The platform still matters, though the question you ask of it changes. A more powerful tool outside the daily flow of work runs into the same adoption ceiling as the last one. A platform that runs inside the environment where people already work raises that ceiling, because logging a request becomes part of the work itself. Adoption rises, complete data replaces opinion, and automation and prevention become realistic. So when you weigh your next step, look at how close the platform sits to the work as well as at its feature list. That distance decides how far up the model you can climb.