Introduction

Service Level Managers are also called Service Managers or even Service Delivery Managers in many organizations. This is a very key role in the ITIL® landscape and central to managing customer expectations and customer satisfaction. Good Service Level Managers are in high demand, and the experience levels vary from about 6 years upwards. With higher level of experience, a Service Level Manager may become more adept at managing more complex IT landscapes or more complex outsourcing organizations, e.g. a multi-vendor setup. The Questions below are likely to be useful to aspiring Service Level Managers, during an interview, and after they land a new job. It is packed with experience garnered from complex IT Service Management landscapes and while the answers follow the ITIL guidance, this is not what you will typically get in ITIL books. Therefore, the information presented is an add-on, as opposed to presenting what is already available elsewhere.

1. What is meant by ‘Service Level’? How is it determined and who determines it?

Service Level or level of service is a quantification of the scope of services. E.g. if Incident Management is a service that is provided, the IT service provider may provide some commitments on – the number of incidents resolved on a business day, the response and fix times (in minutes or hours) per level of severity, the lead time (in days) to provide a major incident report etc. Levels of service must be defined for every service provided. 

Often, levels of service are associated with financial rewards or penalties. Target service levels will typically be defined during the Service Design phase of the ITIL Lifecycle and the actual performance will be measured during the Transition, Operations and Continual Service Improvement phases. Context of the service provisioning determines the committed service levels, but common influencing factors are – system documentation, system stability, user base, user experience design considerations etc. The technology expertise of the service provider is also important, e.g. a service provider who specialises in a technology may be able to commit to better service levels than a more generic service provider. 

Service levels are defined during the Service Design phase and the Service Level Manager defines these, with inputs from the Business Relationship Manager and in consultation with the customer and by leveraging the capability model of the service provider.

2. What does Service Level Management (SLM) hope to achieve?

The primary objective of service level management is to define, document, agree, monitor, share, report and review the level of IT services provided. SLM also ensures that appropriate information is available to Business Relationship Management so that the latter may have more effective communication with stakeholders. Metrics collection is an ongoing process in the later phases – Transition, Operations and Continual Improvement. SLM should have the tools and methodology to analyze and make decisions regarding re-calibration of the service levels.

Apart from defining the service levels, SLM also ensures that IT and the customers have clear and unambiguous expectations on the levels of service to be delivered. While BRM owns the customer satisfaction survey process, the SLM process ensures that the results of the survey can be mapped to the service levels that are agreed.

Last, but not the least, SLM is also responsible for improving the levels of service delivered by the provider organisation. Improvements are not only NECESSARY in the context of low customer satisfaction but also important for customer delight especially in a scenario where there are many other competitors IT service providers, which is typical in an outsourcing scenario.

3. What are the pre-requisites for a Service Level Manager to be successful?

There are mainly a couple of things that are inputs to the SLM process – the Service Portfolio and the Service Catalogue. The contents of these define the scope of services to those managed by SLM.

The Service Catalogue should be the single source of truth for the description of services agreed with a customer. Among other things, the description for each service should include current details, status, interfaces and dependencies on other services (which may well be provided by other IT service providers). These services could be current services being consumed or even the ones that are being designed or developed or transitioned into the live environment.

The Service Portfolio is a superset of the Service Catalogue. It exceeds the latter in terms of its scope i.e. it also includes information on ‘retired’ services, i.e. services that are no longer offered.

The Service Portfolio is internal to the IT service provider and includes all the services that are offered to all customers.

To understand with an example, if an organization is providing Incident and Problem Management services to customer A and Problem Management and Change Management services to customer B, then the Service Portfolio of the provider will include Incident, Problem and Change Management. However, the Service Catalogue for customer A will include only Incident And Problem Management (but not Change Management), and for customer B will include only Problem and Change Management (but not Incident Management). To put it in another way, the Service Catalogue is a customer-specific subset of the Service Portfolio, that is visible to the customer.

4. Have you heard of SLAM charts? What are these and why do we need them?

SLAM is an acronym for Service Level Agreement Monitoring, and SLAM charts are visual depictions of the actual level of compliance against the agreed levels. SLAM charts are built on top of data that is provided by the Service Transition, Operations and Continual improvement processes. The concept of SLAM forms the basis of many of the tools that are in use today to monitor the health of IT services and infrastructure.

SLAM charts will almost always include some visual aids to denote the health levels – usually on a Red-Amber-Green (RAG) traffic-lighting model, where Red is obviously poor health needing IMMEDIATE attention, and Amber denoting services that need to be monitored so that they do not slip into the Red zone. Online tools and most of the cloud service providers will use SLAM charts for their customers built using agreed thresholds defined during the service design phase. E.g. two customers A & B, both requiring 98% Availability of a service may have different tolerance levels for service degradation. Customer A may define an Amber threshold as 96% to 97.99%, while customer B may have a more relaxed lower limit at 92% but a slightly stricter upper limit at 98.10%.

Dynamic SLAM charts may be used extensively by the operations teams such as the Application Management and the Technical Management Teams as well as the Service Desk. Modern tools allow drill down to the service level. SLAM charts are also used in service status reporting and in re-defining the service strategy – in the BRM process. They are a sure-shot source of current and historical information (trends over time) for the stakeholders involved in Service Improvement – for increased customer satisfaction and beating the competition.

5. What is an SLA? Does it always have to be documented?

The SLA is an acronym for Service Level Agreement. SLAs must always be mutually agreed between the customer and the IT service provider and documented. SLA information must be available to the ‘people on the ground’ – namely the development, application management, technical management and Service Desk teams.

SLAs will be referenced in the contract, and be used to arrive at contract pricing, as well as in defining rewards and penalties for the organization providing the services. Contracts are legal documents, so, there is always a possibility that the contents of the SLA documentation will be referenced during any legal proceedings. E.g. for medical equipment running on software at a hospital, there may be an SLA for providing on-site technical services in case of failure during a surgery. Failure to do so may risk the life of a patient, and therefore invite legal action against the service provider.

With the above, it is quite evident that SLAs must always be documented without exception.

The SLA must only contain what can be effectively monitored and measured. This is because it is difficult to define any contractual reference to subjective items.

6. A very JUNIOR member of your team is curious about ‘OLA’. How do you explain it to her?

OLA is an acronym for Operational Level Agreements. An IT service provider will typically agree to provide certain services at specified levels. This is documented in the Service Level Agreement (the SLA). However, in the real world, the service provider organization may need to contract with other organizations, or even with other internal departments. Let us see this with a couple of examples.

Let us say the customer contracts with an IT Service Provider X for providing Incident Management, Problem Management and Change Management services for System A. System A interfaces with a backend system B, which is serviced by another IT service provider Y. Upon investigating an incident, the Application Management team infers that the real issue lies in System B, so they pass the incident to the team in organization Y. Now, ownership for adhering to the service levels for the incident still lies with organization X. What if the team in Y accepts the incident, but reduces priority because they have other incidents to look at? How can org X ensure that Y attaches due importance to this incident? Through an OLA. Org X must formalize an OLA with Y, so that this incident is taken up within the OLA. E.g. all such delegated Severity 3 incidents will be turned around in no more than 20% of the overall SLA RESOLUTION. So, if the agreed service level with Org X for Severity 3 is 10 business-hours, the expected turnaround time from org Y is 2 hours.

7. Describe a typical day in the life of a Service Level Manager?

The Service Level Manager is the process owner for the Service Level Management (SLM) process. This is a critical role, and he wears many hats at a time. With the customer, he needs to negotiate and agree to the service levels for each of the services in the Service Catalogue – some of these would be for current services, and some for future services. Agreements may also be needed for improvements to service levels for current services, e.g. the IT Service Provider may commit to a 98% compliance for Year 1 of the contract and promise a 0.5% improvement Year-on-Year (YoY) basis. So, effectively, they are committing to a 98.5% compliance in Year 2 and 99% in Year 3.

The Service Level Manager knows most about the SLAs, so is best suited to align the OLAs with the downstream providers or suppliers. E.g. for on-boarding niche technology resources, there may be an OLA of 4 weeks with a staffing organization.

He also ensures that the service status reports are accurate and circulated with the relevant stakeholders in a timely manner. If there are any breaches reported, these should be investigated, and LESSONS learnt documented. He should represent the service provider organization in the service performance reviews with the customer and the suppliers.

At the Change Advisory Board (CAB), the Service Level Manager represents the assessing authority for the impact of changes to the current and planned services. For any adverse customer survey feedback, complaints on the non-compliance to the agreed service levels, or requests for improvement he will first record and then manage the complaint lifecycle to resolution, by liaising with the other departments.

8. Can you give some real-world examples of multi-level SLAs?

Multi-level SLAs are typical of outsourcing scenarios, where one IT service provider provides a bouquet of services to different customers. This is done to ensure that the specific needs of the customer are met – in other words, the service provider is customising its portfolio. While this obviously means a possibility of achieving greater customer satisfaction, there are trade-offs that must be made in terms of service levels and costs.

A file-sharing service is a good example. Let us say basic users can only transmit 2 GB per day for no charge, and the receiver can access the files for 7 days without a login. So, at the most 14 GB of storage will have to be provided to the basic users. For premium users, the levels could be higher – let’s say 10 GB per day with a carry forward option and the receiver can access it for 30 days. Let us also assume that this service is available round the clock. So, we are talking of a service that offers a generic service level of 24X7 ‘availability’ for all users, but different levels of storage ‘capacity’.

Now consider another dimension to this – that of data encryption. The data protection laws of a country may require that all files transmitted from IP addresses in that country be encrypted and the receiver must have a basic service login. To promote usage of their file sharing service, the service provider includes the provision to automatically create a login for the receiver, so that the latter may only need to reset their password at first login. With this, the service provider also endsup providing a ‘user creation’ service in addition to the ‘availability’ and ‘capacity’. This is a 3rd level of SLA, specific to the user as well as the service.So, in this example you can see 3 levels of SLA – generic level, user-specific level, and a user-specific service level.

9. You have joined a new company as the Delivery Head, and you need to do goal setting for your Service Level Manager. What are his success factors and KPIs?

As mentioned in one of the earlier answers, a Service Level Manager wears many hats. Therefore, his performance goals need to be set accordingly. In fact, often the success of an engagement will depend largely on how well the service levels have been met.

In SLM, numbers are key – this is also true for the KPIs for the Service Level Manager. First, how many of the service targets are being met, and what are the levels of compliance – Red? Amber? Green? Too few SLAs being met may imply over-commitment on the part of the service provider and too much compliance can imply that they may have chosen easy targets. If there are any breaches, these need to be counted, as well as the extent of the breach.

A Service Level Manager must keep all the SLAs up-to-date and communicate this to the people on the ground. Service performance reports must be accurate and timely, and actions identified during service reviews followed up to closure. He must actively involve himself in improving customer satisfaction by way of cost reduction, service improvement and innovation. Most SLAs are valid during the lifetime of a contract, so the Service Level Manager must actively participate in renewing the SLAs during the contract renewal. During the renewal process, he must consider the service performance in the last performing period and re-calibrate them by negotiating with the customer.

10. During your induction in the role of a Service Level Manager to the new company, they have shared with you only the signed copies of customer contracts. What should you do?

I must ask for the Service Level Agreements (SLAs) also. Contracts are most likely to reference SLAs, which are usually documented separately, as the latter is not a legal document and changes to the same pass through a less rigorous change control process. This also allows the Service Level Manager to make operational changes to the SLA if the effort and budget does not exceed what is mentioned in the contract.

For a Service Level Manager to understand the context of the services in his new organization, the SLA, and the Service Portfolio and Service Catalogue are the three primary things that he needs to be familiar with within the context of ITIL. He also needs to get copies of the SLAM charts and access to any dynamic SLAM dashboards in use for the service. The service performance reports, and the minutes of the service review meetings are also useful inputs, as these will give him a good understanding of the current status of the service.

To know his stakeholders better, he must also review and understand the OLAs with the other groups and the other suppliers. After studying the SLAs and the OLAs, he must be able to stitch them together to understand the overall situation with the service levels. If the same service is provided to different customers at different service levels, he must understand the reason behind this.

Finally, the service improvement register, which should also include the actions being taken to improve customer satisfaction and redress complaints, is another source of information.

All the above are must-see must-know and must-understand artefacts for the newly inducted Service Level Manager. And of course, a bit of luck as well!