The five ITIL 4 practices to start with

ITIL 4 describes 34 management practices, grouped into general management, service management and technical management practices. No organization needs to adopt all of them at once, and almost none could do it well. This article proposes a concrete starting point: five practices and a service desk, what each one needs at a minimum, how to measure it and in what order to tackle them.

Why not start with all 34

The full set of practices is a reference, not an implementation plan. Trying to cover it all from day one tends to produce three recognizable symptoms: documented processes nobody follows, a service management tool that is half configured, and teams that see ITIL as paperwork rather than help.

The framework itself pushes in a different direction. Its guiding principles include start where you are, progress iteratively with feedback, and keep it simple and practical. Within the service value system, practices are resources that combine to run the service value chain; they are not boxes to tick.

The useful question, then, is not "how many practices do we have" but "which day-to-day operational workflows still depend on people's memory and goodwill". In almost any IT organization, the answer points to the same places: how you handle what breaks, how you stop it from breaking again, how you change what is in production, how you deliver what users ask for, and how you agree on what good service looks like.

The foundation: a service desk with a single front door

Before any process, the operation needs a single point of contact. The service desk is the practice that captures demand for incident resolution and service requests and routes it. Without it, each practice receives work through a different channel (email, chat, hallway, a direct call to the specialist) and no metric can be trusted.

A minimum viable service desk has defined and published channels, mandatory logging of every contact, clear criteria for telling an incident from a request, and a simple escalation rule. It does not need a large team. It needs everything to go through it.

The first metric worth watching is first contact resolution, together with user satisfaction at closure. The common mistake is turning it into a ticket dispatcher that only reassigns work, with neither the capacity nor the knowledge to resolve simple issues.

The five practices, one by one

Incident management

Purpose: limit the damage incidents cause by getting the service back to normal as fast as possible.

Minimum viable process: logging, simple categorization, priority calculated from impact and urgency, diagnosis, escalation, resolution, and closure confirmed by the user. Plus a separate procedure for major incidents, with a coordination lead and a defined communication cadence.

Key metric: time to restore by priority, expressed as the percentage of incidents resolved within target. An average alone hides the extreme cases.

Common mistake: letting the reporter decide the priority, or having so many categories and levels that nobody uses them the same way. Four priority levels and a visible matrix are usually enough.

Problem management

Purpose: make incidents less frequent and less harmful by finding what really causes them, and by managing workarounds and known errors.

Minimum viable process: an explicit criterion for opening problems (every major incident and every incident that repeats, for example, three times in a month), an analysis with an owner and a due date, a known error record with its workaround available to the service desk, and a link to change enablement for the permanent fix.

Key metric: recurrence of incidents tied to problems that have already been analyzed. If recurrence does not drop, the analysis is not reaching the cause.

Common mistake: blending it with incident management. An incident is closed when the service is back; a problem is closed when the cause is removed or formally accepted. Keeping the incident open "until we know what happened" distorts both sets of metrics.

Change enablement

Purpose: get as many changes as possible to succeed, making sure risk is assessed, each change is authorized and the change schedule is managed.

Minimum viable process: three types of change (standard, normal and emergency), a defined change authority for each risk level, a visible schedule, and a review of failed changes. The name is deliberate: ITIL 4 moved from "control" to "enablement" to stress that the goal is for changes to go well, not for there to be fewer of them.

Key metric: change success rate, read together with lead time from request to implementation.

Common mistake: a single board that reviews every change the same way. It stretches lead times, pushes teams to route around the process, and does not improve the success rate.

Service request management

Purpose: handle the predefined requests users initiate (access, equipment, information, minor pre-approved changes) efficiently and with a good user experience.

Minimum viable process: a short catalog of the most frequent requests, each with its form, approval (if needed), fulfillment steps and committed timeframe. Starting with ten or fifteen well-handled request types beats starting with a hundred poorly defined ones.

Key metric: percentage of requests fulfilled within the committed timeframe, and, as a second reading, the share fulfilled through automation.

Common mistake: logging requests as incidents. Creating a user account is not a failure. Mixing them inflates incident volume and hides where the automation opportunity lies.

Service level management

Purpose: agree clear performance targets rooted in business needs, then track and manage delivery against them.

Minimum viable process: a list of services with their business owner, two or three measures per service that reflect what the user experiences, a periodic report, and a review meeting with the internal customer. Formal agreements can come later, once there is data to back them.

Key metric: achievement of agreed targets, checked against the satisfaction the business reports. If achievement is high and satisfaction is low, the agreement is measuring the wrong thing.

Common mistake: measuring the availability of technical components instead of the outcome the user gets. That is the source of the well-known "watermelon effect": green outside, red inside.

Summary table

Practice	Minimum viable	Key metric	Common mistake
Service desk	Single point of contact, mandatory logging	First contact resolution	Dispatching without resolving
Incident management	Priority from impact and urgency, major incident procedure	Restoration within target by priority	Subjective priority, too many levels
Problem management	Opening criterion, known error record	Incident recurrence	Confusing problems with incidents
Change enablement	Three change types, authority by risk, schedule	Change success rate	One board for everything
Service request management	Short catalog with timeframes	Fulfillment within timeframe	Logging requests as incidents
Service level management	Measures per service, periodic review	Achievement versus satisfaction	Measuring components, not outcomes

A suggested sequence

There is no single right order, but there are dependencies. We recommend moving in short increments, each with a visible result, instead of one large project with a distant end date. How long each increment takes depends on the size of the operation; as an example, six to eight weeks per increment is a reasonable pace for a mid-sized IT organization.

1. Service desk, incidents and requests. These go in together because they share the front door. The first win is separating the two flows and logging everything.
2. Change enablement. With incidents already logged, you can see how many originate in changes. That figure justifies the process to technical teams and shows which changes to declare standard first.
3. Problem management. It needs incident history to spot recurrence. Starting earlier tends to end in analysis without data.
4. Service level management. The conversation with the business can start in the first increment, but formal targets are best set with at least a few months of real incident and request data.
5. Review and expand. With the foundation running, assess which other practices (knowledge management, service configuration management, monitoring and event management) add the most value given the bottlenecks you observe.

How to tell the foundation is ready

The signal is not having every process documented. It is being able to answer questions like these with data, without rebuilding anything by hand:

• How many high-priority incidents did we have last month, and how many were restored within target?
• What percentage of those incidents originated in a change?
• What are the five most recurrent incidents, and which open problem does each one have?
• Which requests account for the most volume, and which could be automated?
• Which service has the worst business satisfaction, even though its technical indicators are green?

If the team can answer them, the operation has a foundation to grow on. If not, adding practices only adds complexity. In that case, go back to the previous increment and close the gaps before moving on.

One last recommendation: the tool supports the process; it does not replace it. Platforms such as ServiceNow, Jira Service Management and others let you configure these flows, but none of them decides for you what a major incident is or who authorizes a high-risk change. Those are design and governance decisions, and they should be made before configuration starts.