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
- 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.
Basic Concepts of Service Level Management (SLM)
How SLM supports the business and business units
The whole reason for SLM is to measure IT performance in support of the business. Implementation requires measurements of all aspects of the above diagram.
Users in business units use Service Catalog services in support of business outcomes
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."10
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 holistically11
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."12
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 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
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.13
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 abovementioned tasks.
ITIL Practice Roles for optimal efficiency
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."14
ITIL says that the critical requirements for a successful SLA include:
- 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
- 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)
- How to contact the Service Desk
- Service Desk hours
- Other support
- 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!
- 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
- Amendment sheet
Sample ITIL Operational Level Agreeent (OLA)16
- Support service description.
- Scope of the agreement.
- Service hours.
- 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.
- The agreed-upon roles and objectives for the development and application of changes.
- The agreed-upon roles and objectives for the development and application of releases.
- The agreed-upon roles and objectives for the advancement and execution of deployments.
- Early life support preparation, training, documentation, and escalations.
- 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).
- 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.
- 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.
- Help managing contracts and suppliers, primarily within the parameters of their technical domain.
- 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.
- IITI® Foundation ITIL 4 Edition, Axelos Limited, 2019, p. 152
- Ibid, p. 152
- Ibid, p. 152
- Ibid, p. 153
- The Balanced Scorecard, Kaplan and Norton, 1992
- Ibid, Kaplan quote
- ITIL v3, Service Design, The Stationary Company, UK 2011 Edition, p. 106
- Ibid, ITIL 3, p. 107
- Ibid, ITIL 4, p. 96
- Ibid, ITIL 3, p. 108
- Ibid, ITIL 4, p. 24
- Ibid, ITIL 4, p. 32
- MetricNet, "The Economics of Shift Left"
- Ibid, ITIL 4, p. 152
- Ibid, ITIL 3, Appendix F, p. 327-330
- Ibid, ITIL 3, Appendix F, p. 330-332