What does service management mean here?

Running services so that their performance can be evidenced to somebody outside the organisation, not only shown on an internal dashboard. Incidents, changes and requests recorded as they happen, by the systems that handled them.

How is this different from a helpdesk?

A helpdesk answers requests. Service management is the discipline around it: how a change is approved, how an incident is classified and escalated, and how either can be reconstructed afterwards without asking the person who was on shift.

What does evidencing performance actually require?

That the record is produced by the work rather than assembled after it. A monthly report compiled by hand describes the service; a log written by the systems as they ran is what a regulator can test.

Do we need ITIL to do this?

No. The established frameworks are useful vocabulary and they are not the point. What matters is that the process is defined, applied by the systems, and evidenced, and an organisation can have all three without adopting a framework wholesale.

Service management

Service operations that can evidence their own performance to a regulator, not only to an internal dashboard.

Since January 2025, the Digital Operational Resilience Act has required financial entities and their ICT providers to evidence exactly that, register included (DORA; EIOPA). A number that cannot be produced on demand is a regulatory exposure, not an operational irritation.

The same incident, measured twice

Reported at 09:00. Nobody looked at it until 13:30. Fixed at 15:40.

From when it was reportedFrom when the desk picked it up

The waiting counts.

Process fidelity or platform convention
Matching the platform to your process preserves familiarity and multiplies upgrade cost; adopting its convention is cheaper and politically harder. We adopt the convention unless the process genuinely differentiates you.
What an SLA is for
An SLA that everyone always meets measures nothing. Metrics that have never triggered a corrective action are reporting, not control.
Who holds the register
For DORA-scope entities the ICT third-party register needs a named home. Service management is usually the right one, and rarely the assumed one.

What you walk away with

Four pieces of work, and not one of them is a number we promise to hit. Each one is what has to exist before any number you are given means anything.

Definitions in writing, before anybody quotes a figureThe clock demo, settled: baseline, window and scope.
Where each clock starts and stops, which hours count and which do not, what is in scope and what is explicitly outside it, and what happens to the measurement when a ticket is reassigned or reopened. Agreed once, written into the contract, and applied the same way by both sides.
Without it every reported figure is negotiable after the fact, which is how two parties look at the same afternoon and honestly disagree about whether the service level was met. The argument is never about the incident. It is always about the definition nobody wrote down.
This is deliberately the first piece of work and not the last. Measuring against a definition agreed afterwards produces a number shaped by whoever agreed it.
The four processes running against those definitionsRequests, incidents, changes and knowledge, on one set of rules.
Each of the four has a measure and a condition that keeps the measure honest, as set out above, and the work is making both real: the routing, the categories, the approval path, and the article lifecycle behind them. Not four separate improvement projects, one operating model with four flows through it.
They are done together because they share their failure modes. A knowledge base nobody prunes inflates the request numbers, an unclassified change inflates the incident numbers, and each one fixed in isolation quietly moves the problem into the next.
What arrives is the process as it will actually be run, with the people who run it trained on it, rather than a target operating model in a document.
A register with a name against itThe third decision, answered rather than assumed.
The record of who provides what, under which agreement, supporting which function, with the evidence a supervisor would ask for. Built inside the engagement rather than assembled the week a request arrives, because assembling it under time pressure is how the gaps get papered over.
For financial entities the obligation is explicit and dated. For everybody else the same register is what turns a question about concentration risk from a research project into a lookup.
The point of naming an owner is that a register with no owner is out of date within a quarter and nobody notices until it matters. Service management is usually the right home and rarely the assumed one.
Reporting that has actually triggered somethingThe second decision, taken seriously.
A small set of measures that are reviewed on a cadence, with a defined consequence when one moves the wrong way. Fewer measures than most reporting packs contain, and each one attached to a decision somebody is accountable for taking.
A service level everyone always meets measures nothing, and a metric that has never caused a corrective action is reporting rather than control. That distinction is the difference between a pack that gets read and a pack that gets filed.
It also gives the definitions above their teeth. Rules nobody checks against are documentation, and this page has spent its length arguing that documentation is not the same as proof.

We instrument the service first so you can see what it is really doing, then change it. Reporting a regulator will accept comes out of running it properly, not out of a separate exercise.

Review your service