You have a customer with a signed Service Level Agreement (SLA) and a good relationship with them. This is a great start, but can you imagine how many customers are served without an SLA? Many.
There are different reasons for such a situation, but one thing is certain: it’s not good. There are often explanations such as, “We’ve worked with the customer for so many years and there are no disputes, everything runs well… so why bother?” This statement is partially correct. When there are no disputes there is no need for an SLA.
But, what is often forgotten is that the SLA defines many operational processes, procedures, and parameters, for example: how incidents will be handled, which measurements (and how frequently) are needed, and availability of the service, among other things.
Roots
Usually, there is an SLA template and all you have to do is adapt it to the service for which it will be used. And then the brainstorming begins. Where is a description of the service? What are the availability requirements? How about security? These and many other questions may arise. Basically, when the service has to be operational in a live environment (which brings a lot of activities and issues to solve), you start asking questions that go far back in the service lifecycle. An even worse situation is when the SLA is signed much later after the go-live. The later the building of the SLA starts, the more complicated it gets.
Thankfully, this situation can be quickly remedied. Service does not come from nowhere. It is carefully prepared before it goes live. And that gives the chance to start preparing the SLA, i.e., its content, much earlier.
Service Level Requirements
Customer requirements (as a result of fulfilling customer business needs) are the basis for the service. By documenting the customer’s requirements, the Service Level Requirement (SLR) is produced. The SLR is made in the form of a document that will serve as the basis for the future SLA. The SLR should describe the service, i.e., how the service should deliver what was required by the customer (defined as warranty of the service), e.g., the capacity of the storage to satisfy the customer’s requirement for e-mail service.
The result of the defined SLR will be service level targets, i.e., what must be achieved to fulfill the SLR. This is where we go into a deeper description of the service. To describe a service with all its parameters sounds difficult, and it is. Therefore, many other processes need to be completed before finishing the SLR document. This means also operational processes (e.g., Incident Management or Problem Management process). Another good idea is to set service level targets as measurable as possible. In this way, later misunderstandings will be avoided.
SLR Throughout the Lifecycle
The SLR is not a one-time job. Let’s take a new service as an example.
Already in the service strategy phase of the service lifecycle there is enough information to start building the SLR, which is, at that stage, business-oriented. Service Portfolio Management, Business Relationship Management, and Financial Management processes will be essential to defining the first requirements (in this stage – high-level). During the design phase of the service lifecycle, there are many processes that contribute to creating a content-rich, i.e., more detailed, SLR (e.g., Availability Management, Capacity Management process, etc.). Usually, during the transition phase, many tests are performed. The SLR is a live document that will be constantly fine-tuned, because during the testing many new details will be discovered and the requirements will be updated. Customers usually have an idea about the functionality (“We need to support a certain number of simultaneous payment transactions.”) and it’s up to us to fulfill such requirements. It is hard to predict everything during the design, so that’s why the SLR may be refined during the transition phase.
When the transition phase is over, we have a complete SLR document, which is an excellent basis upon which to create a detailed SLA. The SLA should be rich in content. Throughout the lifecycle we defined enough parameters to have a good foundation upon which to build the SLA.
Figure: Influence of some of the processes on the SLR and SLA throughout the service lifecycle
Customers and the Process
Service Level Management (SLM) is the process that takes care of both the SLA and the SLR from the beginning (determining and negotiating), through revisions until the SLA is created.
Since there is a customer requirement where it all starts, it’s a good idea to involve your customer from the beginning. There are several reasons for that:
- They like to be involved and feel constructive.
- They are paying for the service, so they have the right to influence the service.
- Clarity – when they are involved from the beginning, there are no details that need to be clarified and can change, e.g., the design of the service (which can happen if you leave customer interaction for the end).
- In such a way, the customer is also the “creator” of the service – so there is no danger that they are not satisfied with the end result.
Ideally, we all like our customers, and therefore it would be nice to have them involved in creating the service from early in the service lifecycle. But, that could be dangerous – therefore you should be careful. If you involve them in every single detail, the sky won’t even be the limit anymore. Their requirements will balloon and your Financial Management process will signal overspending. In the end, it could be a very difficult fight to get the project under your control.
ITIL – Service Level Agreements: Designing Frameworks
Let’s 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 that 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. A 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.
