ITIL Service Management Roles: Incident, Problem, Change and Service Desk

IT service management is easiest to understand through its people. Behind every reliable service there are people answering users, restoring service when it fails, finding out why it failed and making changes without breaking things. ITIL® describes these activities as practices. In most organisations, they also become jobs.

This guide explains the core service management roles: the service desk, incident management, problem management and change enablement. It also covers the roles that surround them, such as service request fulfilment, service level management and the service owner. For each, it describes what the role does, the skills it needs, how performance is measured and how the roles hand work to one another. It ends with typical career paths and how ITIL Foundation supports them.

Practices, roles and job titles

A quick clarification first. ITIL describes practices: organised sets of resources and activities for doing a type of work, such as incident management. It does not prescribe job titles. Organisations decide how to staff each practice. In a large enterprise, a practice may have a dedicated team and manager. In a small one, one person may cover several practices.

So when this guide talks about an "incident manager" or a "problem manager", it means the person accountable for that practice, whatever their job title.

An example to hold in your head

A user cannot log in to the finance system on Monday morning.

1. The service desk logs the ticket, asks the right questions and tries known fixes.
2. Many users report the same issue, so the case becomes a major incident. An incident manager coordinates people to restore service as fast as possible.
3. The team applies a workaround. Service is restored, but the cause is unknown. A problem manager starts an investigation to find the root cause and records a known error.
4. The permanent fix requires a configuration update. Change enablement assesses the risk and authorises the change.
5. After the change, the problem is closed and the knowledge is shared, so the next occurrence is faster to resolve.

Every role in that story has a different question, a different time horizon and a different measure of success. The rest of this guide explains each one.

Service desk

The service desk is the single point of contact between users and IT. For most users, it is IT.

• Core activities: receiving incidents and service requests through phone, chat, email or a portal; resolving what it can at first contact; routing what it cannot; communicating status; and keeping users informed.
• Skills: listening, empathy, clear writing, a systematic approach to diagnosis and a good working knowledge of common technologies.
• Measures: first-contact resolution, response and resolution times, user satisfaction and the quality of ticket records.
• Tools: an IT service management (ITSM) platform, a knowledge base and remote support tools.

The service desk's question is: "What does this person need, and who can help?"

Why the service desk matters more than its reputation

The service desk is often treated as an entry-level role, but it shapes how the whole organisation sees IT. A good service desk analyst gathers the information that lets incident and problem teams work faster, spots patterns early and turns user frustration into clear tickets. Many senior service management professionals started here.

Service request fulfilment

Not every ticket is an incident. Many are requests for something normal: a new laptop, access to an application, a password reset, information. Service request management handles these predictably and efficiently.

• Core activities: defining standard requests in a catalogue, automating where possible, fulfilling requests and confirming completion.
• Skills: process discipline, attention to detail and an eye for automation.
• Measures: time to fulfil, percentage automated and user satisfaction.

The distinction between an incident ("something is broken") and a service request ("I need something normal") matters, because they are handled differently. Treating requests as incidents distorts incident figures and frustrates users.

Incident management

Incident management restores normal service as quickly as possible, with minimum business impact.

• Core activities: logging, categorising, prioritising, diagnosing, escalating and resolving incidents; managing communication during major incidents; and making sure incidents are closed properly.
• Skills: calm coordination under pressure, clear communication, triage judgement and technical breadth.
• Measures: time to respond and resolve by priority, user satisfaction, number of major incidents and how often incidents are reopened.

The incident manager's question is: "How do we get service back now?"

Major incidents

Some incidents are serious enough to need a separate procedure: a dedicated coordinator, a communication plan for stakeholders, regular updates and a review afterwards. Major incident management is where incident managers earn their reputation. The skills are closer to crisis management than to technical troubleshooting: bringing the right people together, keeping them focused, and keeping leaders and users informed.

A common trap

Incident management is about restoring service, not finding the root cause. Teams that try to diagnose the underlying cause during an outage often extend the outage. The right move is usually to restore service with a workaround, then hand the cause to problem management.

Problem management

Problem management reduces the likelihood and impact of incidents by identifying and managing their underlying causes.

• Core activities: analysing incident trends to spot problems; running root cause analysis; recording known errors and workarounds; and driving permanent fixes through change.
• Skills: analytical thinking, curiosity, patience, and persuasion, because fixes often need other teams to act.
• Measures: recurring incidents eliminated, time to identify root causes, quality of known-error records and how often workarounds are used.

The problem manager's question is: "Why did it happen, and how do we stop it happening again?"

Reactive and proactive problem management

• Reactive: investigating problems after incidents have occurred, especially major or repeated ones.
• Proactive: looking for problems before they cause incidents, for example by analysing trends, monitoring data or vendor advisories.

Mature organisations do both. Organisations under pressure often do neither, and the same incidents keep coming back. A problem manager who can show that recurring incidents have fallen is one of the most valuable people in IT operations.

Common root cause techniques

Problem managers use structured techniques such as the "five whys", fishbone (Ishikawa) diagrams, timeline analysis and fault tree analysis. The technique matters less than the discipline: gathering evidence, avoiding blame and confirming the cause before applying a fix.

Change enablement

Change enablement makes sure that changes are assessed, authorised and scheduled, so that the benefit of the change is delivered with controlled risk.

• Core activities: classifying changes; assessing risk and impact; authorising; coordinating schedules to avoid conflicts; and reviewing outcomes.
• Skills: risk judgement, stakeholder management and pragmatism. Too much control slows delivery; too little causes outages.
• Measures: change success rate, number of failed and emergency changes, incidents caused by changes and time to approve.

The change manager's question is: "Is this change worth the risk, and are we ready?"

Types of change

Moving routine changes into the standard category, with automation where possible, is one of the most effective ways to speed up delivery while keeping risk under control. Modern change practices often work closely with DevOps pipelines, where automated testing provides much of the assurance that a change board once gave.

Service level management

Service level management sets clear, business-based targets for service performance and checks that they are met.

• Core activities: agreeing service levels with customers, monitoring and reporting performance, and reviewing services regularly.
• Skills: negotiation, communication and the ability to translate technical measures into business terms.
• Measures: performance against agreed targets and customer satisfaction with the service.

Service level managers connect the operational roles to the customer's experience. Their question is: "Is the service delivering what the business needs?"

Service owner

A service owner is accountable for a specific service end to end: its performance, its improvement and its value to users. Service owners rely on all the practices above. When the payroll service has repeated outages, the service owner is the person who asks why, and makes sure problem management has the resources to find out.

How the roles work together

The hand-offs are where things often go wrong. An incident closed without a problem record means the cause is never found. A problem fix applied without change control causes the next outage. Good service management is as much about the connections as about each role.

Career paths in service management

There is no single route, but a common progression looks like this:

1. Service desk analyst – learning users, systems and the basics of service management.
2. Senior analyst or incident lead – handling escalations and coordinating incidents.
3. Incident, problem or change manager – accountable for a practice.
4. Service owner or service delivery manager – accountable for one or more services end to end.
5. Service management lead or head of IT operations – accountable for the service management system as a whole.

Others move sideways: into service management platform administration, into quality and continual improvement, into DevOps and site reliability engineering, or into IT governance, where frameworks such as COBIT® become relevant. Our guide to ITIL vs COBIT explains how the two fit together.

Skills that move you up

• Communication with non-technical people. The higher you go, the more of your job is explaining.
• Data. Being able to show trends in incidents, changes and service levels makes your case for improvement.
• Improvement mindset. ITIL places continual improvement at the heart of service management. People who fix the system, not just the ticket, get noticed.
• Tool knowledge. Familiarity with the ITSM platform your organisation uses.

Job titles you will see

Because ITIL does not prescribe titles, job adverts use many names for the same work. This table maps common titles to the practices they usually cover.

Read the responsibilities, not only the title, when you compare roles.

Where ITIL Foundation fits

ITIL Foundation gives everyone in these roles a common language: the same meaning for incident, problem, change, service request and value. That shared vocabulary is often what makes hand-offs work. It is the usual starting qualification for each of the roles above.

ITIL (Version 5) Foundation is the current entry-level qualification. PeopleCert's published exam format is 40 multiple-choice questions in 60 minutes, with a 65% pass mark. Our ITIL 5 exam preparation guide explains how to prepare, and what ITIL 5 is gives an overview of the framework.

Get free certification pathway advice →

Next step

If you are preparing to move into one of these roles, ITIL Foundation is the place to start. See CertScope's ITIL® 5 Foundation training and request current course details.

View ITIL® 5 Foundation Training Schedules →