Neven Zitek In my previous Service Level related article (ITIL Service Level Management – making sure that what you want is what you get), I’ve tried to emphasize the importance of Service Level Management. If that article got you thinking about the topic of SLA, then we have a treat for you; within this article we’re going to explore different options to ensure that all services and customers are covered with best-suited Service Level Agreements (SLAs).
Service-based SLA
Figure 1 – Service-based SLA
As a service provider, the list of services you provide (e.g., e-mail, file share, desktop management, etc.) is contained within a Service Catalogue. Each service has been designed with its own properties (utility), which can be translated into business expectations in the form of capacity, availability, security, or continuity (warranty).
If the services you provide are uniform across a wide customer base, then a service-based SLA is the most appropriate way to go. Each service has its own SLA parameters, which don’t change with customer specifics – as there are expected to be none.
Even though there might be some variations in terms of class of service (e.g., bronze, silver, gold), customer-based SLAs are the most straightforward, and the easiest to implement and maintain. However, the biggest downside is the fact that customer-specific requirements can’t be taken into account.
A good example of a service-based SLA would be any kind of cloud service.
Customer-based SLA
Figure 2 – Customer-based SLA
As the complete opposite to the service-based SLAs, customer-based SLAs put all the customer’s requirements and expectations into a single document. This means that all the services you provide for a specific customer will be described and contained in one SLA per customer.
Even though customers prefer such agreements, they are much harder to manage, and in the case of change in one service, the whole document must be rewritten and signed again – covering the whole service group.
Despite the obvious disadvantages, from my personal experience customer-based SLAs are probably the most common SLA types out there. This is not surprising, as Service providers use this framework to display their orientation and focus toward the customer and as mentioned before, customers prefer such arrangements.
Multi-level SLA
Figure 3 – Multi-level SLA
When providing services, either internally or externally, to very large organizations, it may be very challenging to balance SLA types and classes. In order to cope with this issue, a multi-level SLA framework is often broken into three distinct groups:
- Corporate level SLA – covers all generic service level management (SLM) issues, which are common throughout the organization, but are less prone to changes during the contract.
- Customer level SLA – covers SLM issues specific to a customer group, or business unit (BU), regardless of service being used. Good example of such specifics would be service hours, which should match the BU’s working hours (e.g., night shifts, WAN/internet connection bandwidth, etc.)
- Service level SLA – covers all specifics within a single service in relation to a specific customer (one for each service). For example, e-mail-specific measurables and targets (KPI) are contained within the e-mail SLA, and the same goes for file-share services, desktop management, etc.
Selecting an appropriate framework
SLA frameworks are quite straightforward in terms of their applicability.
Service-based SLAs are suitable for generic services (e.g., cloud), and may be used by Type I, and even Type II service providers (ITIL Service Provider types – Type I: Internal service provider, ITIL Service Provider types – Type 2 or Shared Services Unit), as their services are already tailored to meet business demands, and they provide services to a single organization or BU.
Customer-based SLAs are widely used by Type III service providers (ITIL Service Provider types – Type 3 or External Service Provider) because customers prefer to have a single agreement with one provider. Type II providers can use this framework as well, in case they treat individual BUs as individual customers with specific requirements.
Multi-level SLAs are mostly present in large corporations (though not always) that require special treatment in the form of a mixture of generic and specific demands, which must be documented in detail, but at the same time must not generate overhead in management, or overlap in documentation.
Important decisions
One important piece that could define your SLA framework selection may be service performance monitoring capabilities; nothing should be included in the SLA unless it can be monitored and measured effectively. If you deliver services over a common shared infrastructure (e.g., internet), there is no point in leaning toward customer-based SLAs, as your service performance is directly related to an important piece of infrastructure that is totally out of your control (the internet).
Different SLA frameworks present different options; within a customer-based framework, when negotiating SLA targets with the customer, it’s recommended that you have outlines of the SLA drafted instead of giving a “blank piece of paper.” Such drafts, however, should not be too detailed, as the customer may feel like negotiations only go one way. On the other hand, for service-based SLAs, the customer expects a very detailed and informative SLA document right from the beginning of the negotiations.
For any service-oriented organization it’s extremely important to implement a working SLM process. It’s seemingly complex, and many organizations feel discouraged regarding SLM implementation – but you don’t have to be one of them. My suggestion is that after learning best practices on this topic, you simply start making changes you know you must benefit from. Waiting for things to change by themselves is definitely not part of best practices. When there is a hill to climb, don’t think that waiting will make it smaller.
You can also check out this free template: Service Level Management Process to get familiar with activities, roles, and responsibilities of Service Level Management.
