ITIL Service Level Management Practice

How can a Service Desk communicate response, resolution & customer satisfaction to generate trust & confidence? Use the ITIL Service Level Management Practice.
We may not use this title, but we know what it means. When you take your laundry to the dry cleaners, you get a receipt that says it will be ready on Thursday afternoon. What is not displayed, because it is assumed, is that it will be clean, neatly pressed, and meet your standards. This conversation increases trust and confidence.
Service promises are no different in the complex Information Technology (IT) world.
Think of the thousands of transactions in a company where users contact the Service Desk with a request. Based on the impact, urgency, and history of all IT departments working together, the Service Desk says we will have this taken care of in 48 hours. This conversation is also to generate trust and confidence.
How can a service desk communicate response, resolution, and customer satisfaction like this? That is the topic of this paper.
When companies do Service Level Management (SLM) correctly, they increase customer satisfaction and lower costs — the perfect combination.

Service Level Management: Information Technology's performance Practice

ITIL's history since the 1980s, there has been a Service Level Management (SLM) Practice.
ITIL defines the purpose of the SLM Practice as:
"The purpose of the service level management practice is to set clear business-based targets for service levels and to ensure that proper assessment of service delivery of services and to monitor and manage against these targets."1
A Service Level, according to ITIL, is "one or more metrics that define expected or achieved service quality."2
Before we get too far ahead, IT organizations cannot effectively create an SLM Practice by just making wild promises or guesses. In large and diverse IT teams, no one knows 100% that the team can do anything at a specific time without an analysis of accurate history. It is unprofessional to make promises, set customer expectations, and miss targets.
The right strategy is to start with something other than a Service Level Agreement (SLA) but to end with one.
"A Service Level Agreement (SLA) is an agreement documented between a service provider and a customer that identifies both services required and the expected level of service."3
SLAs are not just a statement of expected service. For an SLA to be effective, it should have the following characteristics:4
  • SLA metrics related to a defined "service" in the Service Catalog. Missing this, and you end with metrics without purpose.
  • SLA measurements that were more than just operational metrics and established outcomes. To accomplish this, use a balanced bundle of metrics5 (i.e., customer satisfaction and business outcomes).
  • SLAs should reflect an "agreement" (i.e., an engagement and discussion between providers and consumers) and not IT dictating the levels.
  • For all parties, SLAs should be simple to use and comprehend (i.e., these are not legal documents).
  • Effective SLAs require continuous engagement to understand and confirm ongoing needs.
"If you can measure it, you can manage it."6

Objectives of Service Level Management

As we have already discussed, the main objective of SLM is about documenting how IT responds to operational business demands via the Service Desk, and SLM objectives continue with that theme:7
  • The level of IT services offered should be defined, agreed upon, tracked, measured, reviewed, and corrected as necessary.
  • Offer and enhance business relationships and customer communications in combination with the Practice of Business Relationships Management.
  • Ensure that IT develops specific and measurable targets for all IT services listed in the Service Catalog.
  • Continually evaluate and raise client satisfaction with the caliber of the services provided
  • Make sure that the level of service to be provided is understood by both IT and customers.
  • Ensure service levels are subject to proactive, cost-effective continual improvements, even when meeting all agreed targets. You can always get better.

SLM's value to the business

SLM is at the heart of everything we do in IT. According to ITIL best practices, "SLM provides a consistent interface to the business for all service-level-related issues."8
SLM gives the company the agreed-upon service goals and the necessary management data to make sure we achieve those goals. When targets were breached by IT, SLM provides feedback on the reason why it happened as well as specifics on what was done to stop it from happening again.
As a performance setting and reporting Practice, SLM is the perfect source for reliable, comprehensive communication channels with the appropriate customers and business representatives at the operational level.
In addition, SLM, if used as a strategic asset, helps optimize service delivery speed and user productivity. It may also increase IT's involvement in business planning to improve a competitive edge.

SLM and Business Relationship Management: The one-two punch!

While this article concentrates on SLM, ITIL also has a supporting Business Relationship Management (BRM) Practice:
"The purpose of the relationship management practice is to establish and nurture the links between the organization and its stakeholders at strategic and tactical levels. It includes identifying, analyzing, monitoring, and continually improving relationships with and between stakeholders."9
While SLM is about operational performance, BRM focuses on the strategic and tactical levels. Through IT's close relationships with business executives, it is possible to draw dependencies between what senior executives want to achieve and what occurs at the daily operations level.
When these two Practices work together, SLM can set higher-level service demands that will prepare the IT organization to support a future direction — another example of how all 34 ITIL Practices depend upon and support one another.

Where does SLM fit into the service lifecycle?

SLM is a practice of the Service Design stage. The ITIL service lifecycle is:10
Lifecycle Stage Purpose
Service Strategy Guides value creation.
Service Design Transforms service strategy into a method of achieving corporate goals.
Service Transition Gives instructions for building and enhancing the capacity to integrate new and modified services into supported systems.
Service Operations Outlines recommended methods for controlling services in supported systems.
Continual Service Improvement Advice on improving service Strategy, Design, Transition, and Operation in order to increase and retain customer value.
It is in Service Design when we know from service strategy that it would be beneficial to have XYZ service. As part of designing the service, a company wants to know how we should deliver the service to the company in a way to maximize value. This is where SLM begins. The Practice involves bringing together service consumers and service providers. From that beginning, SLM maps out who does what and how we will know if it is beneficial.
Before writing the SLA, SLM brings cross-functional teams (i.e., the providers) together to collaborate on how best to provide the service support both service and consumers require. This process occurs in Service Design and becomes refined in the Service Design Package. The Service Design Package is the product of Service Design and input into the service transition lifecycle.
OLA and SLA writing happens in the service transition lifecycle, is delivered to operational teams in service operations, and is refined in Continuous Improvement.
SLM is unique in all ITIL Practices. It works in all the lifecycle stages. It touches all 34 ITIL Practices. SLM guides how to execute Practices, and SLM measurements let everyone know how we are doing and what needs improvement to maximize Return on Investment (ROI).

Basic Concepts of Service Level Management (SLM)11

Service Level Management Concepts

How SLM supports the business and business units

The whole reason for SLM is to measure IT performance in support of the business. SLM needs all the above parts to work and contribute to value delivery.
Business units use the Service Catalog of services to support their specific business outcomes (i.e., what they deliver to business customers).
Business units use different services from the Service Catalog. Each service has its SLA — one SLA for each service. When users go to the Service Catalog, they read the SLA that tells them their responsibilities and IT's support responsibilities, priorities, and support targets for their service.

OLAs define each IT support team's commitment to supporting SLAs

"An OLA is an agreement between an IT service provider and another part of the same organization that assists with the provision of services. An OLA should contain targets that underpin those within the SLA to ensure IT does not breach SLA targets by a failure of a supporting activity."12
For SLM to promise SLA delivery targets, it is essential that IT teams complete the written OLAs before writing the SLA.

Using the Four Dimensions helps IT think holistically13

The ITIL framework defines four dimensions that, taken as a whole, are essential to the successful and efficient generation of value of products and services for customers and other stakeholders. These are:
  • Organizations and people
  • Information and technology
  • Partners and suppliers
  • Value streams and processes

Value streams detail how work gets done

Value streams outline the tasks, processes, checks, and safeguards required to meet predetermined goals:
"A value stream is a series of steps an organization uses to create and deliver products and services to a service consumer."14
Creating value streams helps identify the time, money, and effort to accomplish a goal. When you record these actions as time durations, the stream enables IT to better-set user expectations and SLA targets. The added benefit is that it becomes easier to identify waste. Eliminating waste increases customer satisfaction and decreases costs.

Service Level Management Value Streams and Process-Flow Diagram15

Value Streams and Process-Flow Diagram

SLM Key Performance Indicators (KPIs) and metrics

SLM is the performance Practice. SLM gathers metrics across all the ITIL Practices and services. SLM helps each 34 ITIL Practices develop, monitor, and manage its metrics.
Here are just some of the many metrics that SLM could monitor:
  • # and % of services covered by SLAs
  • # of OLAs and Underpinning Contracts (UCs) in place for all SLAs and %.
  • # and % of SLAs monitored and reported.
  • % of SLAs/OLAs/UCs that meet expectations.
  • # and % of review meetings conducted on time with minutes produced.
  • Reporting on the number of service improvement suggestions added to the Continuous Improvement Register (CIR) and summary of ongoing improvement projects resulted.
  • Measurements of SLAs/OLAs/UC reviews conducted, and what % require review and update.
  • # and % of service targets met.
  • #, %, and severity of SLA/OLAs/UCs service breaches.
  • Analysis of improving service level achievements.
  • Statistical measurements of customer perceptions.

SLM scatter diagram for CSAT and FCR

An important SLM metric is Customer Satisfaction (CSAT). This measurement is often associated with the Service Desk. But in the SLM world, everything that IT does, all the different departments working as one, creates the user experience (i.e., all departments supporting the Service Desk).
A standard Service Desk metric is First Contact Resolution (FCR) vs. customer satisfaction. The scatter diagram below is an excellent example of a balanced service metric.
SLM measures Customer Satisfaction (CSAT) with many independent surveys. FCR is a metric easily obtained from the call tracking software. Plot them together, and it becomes easy to see that CSAT depends on FCR.
What influences FCR? Call quality, handle time, agent satisfaction, coaching, career path, and training hours. Everything is related. Ultimately, only two metrics matter, Cost per Ticket and Customer Satisfaction.16
Metricnet First Contact Resolution Chart

How to staff for ITIL SLM

Typically, ITIL does not have full-time employees in SLM roles or any other Practice. Staff "do" ITIL in addition to their traditional IT roles. ITIL does not have the typical boss-employee structure. It is not a full-time job. For example, a person could be the Service Desk manager and the department's SLM Practice manager doing all the above mentioned tasks.

ITIL Practice Roles for optimal efficiency

ITIL Practice Roles

SLA is the ultimate document tying IT and business

We have spent a great deal of time discussing concepts the SLA depends on. And with good reason. ITIL defines the SLA as:
"A documented agreement between a service provider and a customer that identifies both services required and the expected level of service."17
ITIL says that the critical requirements for a successful SLA include:18
  • An SLA must relate to a defined service in the Service Catalog (see diagram above).
  • SLAs must to be tied to clear business results rather than just operational data:
    • Outcomes are business goals, what the business achieves by using an IT service with their business procedures.
    • Use well-balanced sets of metrics to monitor results, such as important business results and customer satisfaction. (See Kaplan and Norton's book, "Balanced Scorecard").
  • SLAs should exhibit the service provider's and consumer's discussions and engagement in coming to a service agreement. All parties involved, including partners, sponsors, customers, users, and IT stakeholders, must be involved.
  • SLAs must be presented in a clear and usable manner for all parties invovled.

Sample Service Level Agreements (SLA)

SLAs cover how a service provider delivers a service. To explain some of the topics, we provide the following sample:19
  • Service Description
  • Service Hours
  • Functionality (if appropriate)
  • Service Availability (Warrantee = The right amount of availability)
  • Service Performance (Warrantee = The right amount of performance)
  • Service Continuity (Warrantee = The right amount of continuity)
  • Service Security (Warrantee = The right amount of security)
  • Customer Support:
    • How to contact the Service Desk
    • Service Desk hours
    • Other support
    • Self-help
    • Incident logging on the Serice Desk portal
    • Metrics and measurement
    • Definition of an incident (i.e., service delivery broken)
    • Definition of a request (i.e., anything else)
    • Response and resolution times by priorities
  • Contact points and escalation:
    • Users must contact the Service Desk as the single point of contact. No exceptions!
  • Change Enablement:
    • A brief mention that the Service Desk will handle all Standard change requests.
  • Information about the duties and obligations of the several parties — including the service provider, the client, and the users — involved in the service.
  • Service reporting and reviewing
  • Glossary
  • Amendment sheet

Sample ITIL Operational Level Agreeent (OLA)20

  • Support service description.
  • Scope of the agreement.
  • Service hours.
  • Service targets:
    • The objectives for delivering the support service.
    • The frequency and methods of reporting and reviewing.
  • Contact points and escalation:
    • Information on who to contact at each of the parties in the agreement.
    • Processes and points of contact for escalation.
  • Response times and obligations for incidents and the Service Desk:
    • Objectives and responsibilities established for the Service Desk's assistance of incident progress and resolution.
  • Problem response times and responsibilities:
    • The agreed-upon roles and objectives for problem progress and solution.
  • Support of a Shift-Left strategy:
    • Levels 2 and 3 provide incident and request ticket documentation to eliminate Service Desk documentation errors.
    • Training of Service Desk staff in incident analysis
    • Writing of knowledge articles for Service Desk staff
    • Cross-training with Service Desk staff.
    • Monthly reporting to measure escalation and documentation errors.
    • Proactive quality plan to reduce escalations and increase quality metrics.
  • Change Enablement:
    • The agreed-upon roles and objectives for the development and application of changes.
  • Release Management:
    • The agreed-upon roles and objectives for the development and application of releases.
  • Deployment Management:
    • The agreed-upon roles and objectives for the advancement and execution of deployments.
    • Early life support preparation, training, documentation, and escalations.
  • Configuration Management:
    • The duties involved in the provisioning, ownership, and maintaining of accurate Configuration Items.
  • IT Asset Management:
    • The responsibilities for the ownership, provision, and maintenance of accurate IT asset items.
    • Coordination and documentation when IT transfers assets from IT to users and between users.
  • Information Security Management:
    • The duties and objectives established to support the Information Security Management Practice and the relevant security policy(s).
  • Availability Management:
    • The obligation to manage and support all components within their support domain in order to achieve and maintain all service and component availability objectives.
  • IT Service Continuity Management:
    • Ensure that all components within their support domain have current, tested recovery plans that support established, outlined business needs.
  • Capacity/Performance Management:
    • The obligation to support the requirements of the Capacity Management Practice within the predetermined parameters of their technical domain.
  • Service Level Management:
    • Help with the definition and agreement of acceptable targets for components falling within the purview of their technical domain in SLAs, service level agreements, and OLAs.
  • Supplier Management:
    • Help managing contracts and suppliers, primarily within the parameters of their technical domain.
  • Glossary:
    • Clarification of any necessary acronyms or jargon used to aid in understanding the provisions of the agreement.


SLM is the standard Practice for capturing IT support data, analyzing metrics and trends, identifying continuous improvement opportunities, and the Practice to join all diverse IT departments together for a common goal.
SLM takes much work. It must involve all people in all departments to correctly set up the Practice to be fair and unbiased.
When done correctly, SLM provides an accurate picture of past business support, current support, and predictions of future support.
  1. IITI® Foundation ITIL 4 Edition, Axelos Limited, 2019, p. 152
  2. Ibid, p. 152
  3. Ibid, p. 152
  4. Ibid, p. 153
  5. The Balanced Scorecard, Kaplan and Norton, 1992
  6. Ibid, Kaplan quote
  7. ITIL v3, Service Design, The Stationary Company, UK 2011 Edition, p. 106
  8. Ibid, ITIL 3, p. 107
  9. Ibid, ITIL 4, p. 96
  10. Ibid, ITIL 3, p. 6-7
  11. Ibid, ITIL 3, p. 110
  12. Ibid, ITIL 3, p. 108
  13. Ibid, ITIL 4, p. 24
  14. Ibid, ITIL 4, p. 32
  15. Ibid, ITIL 4, pp. 32-33
  16. MetricNet, "The Economics of Shift Left"
  17. Ibid, ITIL 4, p. 152
  18. Ibid, ITIL 4, p. 153
  19. Ibid, ITIL 3, Appendix F, p. 327-330
  20. Ibid, ITIL 3, Appendix F, p. 330-332
Bart Barthold

About the Author

Bart Barthold

Bart Barthold is an independent senior ITIL instructor with years of experience in combining ITIL knowledge with practical expertise in running a world-class support organization. He has earned the certificate for the highest level of ITIL training - IT Service Manager, holds an MBA, and he has taught various ITIL certifications and hundreds of students since 2004.
Bart is known for his outstanding performance in IT service management and is a recipient of the Help Desk Institute's prestigious Team Excellence Award in 1998. He also finished second in 1997, making him one of the most decorated IT service managers in the industry.
Request a Live Demo
See It In Action
Assess Your Needs
Get the Tool
Try Giva's 30 Day Trial
Sign Up Today