SLA & The Best Practices To Craft A Waterproof SLA

If you’ve been in the outsourcing world for a little while, you must have heard about the term “service level agreement” – a critical component of any outsourcing and technology vendor contract.

Wisely picking a data center partner can be a nerve-racking experience for several companies. From massive hyper-scale facilities and enterprise-level data campuses to smaller edge data centers, there are various types of data centers to choose from – and not all of them are created equally. Nevertheless, no matter what services and features your business requires from a colocation provider, there is one thing that all data centers have in common that should be at the forefront of every decision: The service level agreement (SLA).

Let’s go through our pick for the most actionable SLA practices to hit the ground running in 2019.

Before diving into the specific practices, it’s essential to first grasp some basic understandings of SLA and its metrics.

Service Level Agreement: The Fundamentals

1. Definition of SLA

A service level agreement (SLA) defines the level of service expected by a customer from a supplier, laying out the metrics by which that service is measured, and the remedies or penalties, if any, should the agreed-on service levels not be achieved. Or to put it simply, SLA is a legal document that outlines the specific terms of the services a data center provides: It outlines what responsibilities the facility has to its customers and what rights are accorded to them.

Usually, SLAs are between companies and external suppliers, but they may also be between two departments within a company.

To take an example, a telecom company’s service level agreements may promise the network availability of exact 99.999 percent (for the mathematically disinclined, that works out to about five and a quarter minutes of downtime per year, which, believe it or not, can still be too long for some businesses). Should that figure be not achieved, such SLAs may grant the customer a reduction of their payment by a given percentage, usually on a sliding scale based on the magnitude of the breach.

2. The Significance of SLAs

As fore-mentioned, SLAs are an integral part of an IT vendor contract.

An SLA pulls together information on all of the contracted services and their agreed-upon expected reliability into a single document. In such document, all metrics, responsibilities as well as expectations will be clearly and concisely stated, thereby, in the event of issues with the service, neither party can plead ignorance. 

Plus, the SLA is of indispensable importance as it does ensure that both sides have the same understanding of requirements. Actually, any significant contract without an associated SLA (reviewed by legal counsel) is open to deliberate or inadvertent misinterpretation.

Ideally, SLAs should be aligned to the technology or business objectives of the engagement. Misalignment can have a negative impact – not only on deal pricing and quality of service delivery but also on customer experience.

3. Provider of SLAs

Most service providers have standard SLAs — sometimes several, reflecting various levels of service at different quoted prices — that can be a good starting point for negotiation. These should be thoroughly reviewed and modified by the customer and legal counsel, however, since they are usually slanted in favor of the supplier.

When sending out a request for proposal (or an RFP), the customer should include expected service levels as part of the request. Not only will this affect supplier offerings and pricing but this may also enormously influence the supplier’s decision to respond.

To continue with the previous example, if you demand 99.999 percent availability for a system, and the supplier is unable to accommodate this requirement with your specified design, it may propose a different and more robust solution.

4. Specifics of SLAs

Of course, a well-written SLA will not include only a description of the services to be provided or their expected service levels. Rather, it does give extensive coverage over almost all the metrics by which the services are measured, the duties and responsibilities of each party, the remedies or penalties for breach as well as a protocol for adding and removing metrics.

In practice, metrics should be designed to such an extent that not any bad behavior by either party is allowed. For instance, should a service level be breached due to the fact that the client did not provide information in a timely manner as specified in the SLA, the supplier is not going to be penalized.

Crucial Elements of the SLA

To craft a strong service level agreement, it’s more than essential that SLA possesses those pivotal elements:

1. Urgency & Technicality Categories

Prioritization of important requests is a mutual interest of both customers and providers. Not only does it allow businesses to distribute their resources efficiently, but it also assures customers that their most pressing issues are dealt with first.

To precisely define prioritization in an SLA, it’s imperative to define request categories first. If the SLA refers to whole service operation, nonetheless, it will be somehow hard to predefine every single scenario. Thus, you’ll need more general issue types, which are still defined clearly enough to allow for a logical categorization of more detailed issue types.

In practice, you could label categories with expressive terms like “normal,” “urgent,” and “top priority.” Also, it’s a “should” that you add to your SLA a list or table of categories as well as their respective urgency level according to the customer’s operational needs.

Should you still be vague about it, just cast a glimpse over this example of Userlike: 

2. Accessibility

In fact, being accessible is a core principle of any customer service and so it’s one of any SLA.

Here are the most important general availability elements. Let’s differentiate them based on weekdays, weekends, holidays, time zones and urgency labels (“urgency”):

• Time of day during which the consumer or supplier will be available for any discussion
• Channels they will be available on
• Unique “online” times of each channel
• Option to call-through to managers in charge (yes/no/who)

Waiting limits per time, channel, and urgency:

• Maximum first response time of each when not available in real-time
• Maximum response time
• Maximum delivery time after order placement

3. Problem Resolution

It goes beyond any doubt that – in any business transaction – the customer wants to be 100% sure that he or she will reach their partner when something went wrong. besides, he/she does expect that these problems will be solved – quickly yet effectively. And this is exactly what an SLA should address.

At the heart of all problem resolutions is the disaster recovery plan. Usually, the disaster refers to a complete failure of all services or one of its central functions.

As a provider in the IT sector, the supplier probably has already worked out a disaster plan that applies to all their customers in scenarios of data loss and disconnection. Hence, such contents should find their way into the SLA along with possible disaster scenarios as well as solution strategies for the specific customer.

After all, the inclusion of a disaster plan in the SLA will allow both sides to agree on the actions taken in a certain scenario, that they’re the best shot.

4. Performance Monitoring

Actually, most SLAs are signed and left to “collect dust” until something goes wrong. Also, since processes and requirements in the IT sector swiftly change, the paper loses applicability over time.

To avert the danger of the SLA’s obsolescence, it’s a “must” to perform periodic performance reviews. Such reviews also raise genuine trust in the relationship between customers and suppliers as well as help to identify performance trends. Should the providers find that they have been getting increasingly sluggish in responding to customers, then it’s time for them to take timely countermeasures before they breach the SLA.

It’s important to first reach an agreement on a fixed rhythm for sending out performance reviews and then throw in metrics responding to the terms agreed on. Let’s consider the following metrics to represent the service performance as regards the crucial elements of your SLA:

• Average first response time (maximum response time when not available in real-time per label)
• Average response time (maximum response time)
• Average problem resolution time (maximum problem resolution time)
• Average time until the issue is touched (maximum time until the issue is first touched)
• Average delivery time after the order was placed (maximum delivery time after order placement)
• Singular breaches
• Average breaches of SLA per 100 requests

5. General Security Measures

In an IT company’s SLA, security measures translate to detailed descriptions of its setup. In practice, these elements will largely be waved through by the customer as the supplier explains why and how his/her company is the best fit for the given consumer.

Based on Ready.gov, there exist some elements of an IT setup to be emphasized:

• Computer room environment (secure computer room with climate control, conditioned and backup power supply, etc.)
• Hardware (networks, servers, desktop and laptop computers, wireless devices and peripherals)
• Connectivity to a service provider (fiber, cable, wireless, etc.)
• Software applications (electronic data interchange, electronic mail, enterprise resource management, office productivity, etc.)
• Data and restoration

6. Penalties

In an SLA, penalties are super powerful – they work like an insurance for the case of breaches. Obviously, not every breach’s result can be estimated down to pennies. In many cases, service downtimes can damage a company’s reputation and then cause diffuse long-term losses. Thus, close consideration paid to them is by no means unnecessary.

Service Level Agreement: Best Practices

Now you have gained some basic insights into SLA as well as its vital “ingredients”, it’s the high time that we moved onto the most critical part of this article: the winning practices for setting up an SLA

#1. Make Coordination A Two-Sided Effort

Actually, an SLA only makes sense if both sides gear to a mutual agreement. Under no circumstances should a company “rubber-stamp” the demands of a customer just to score the deal. Likewise, when sending counteroffers, they should themselves only suggest terms that they can achieve and deem satisfying for the customer.

The overall objective in SLA negotiations should be to prevent penalties while performing the service which satisfies the customers’ requirements and even beyond.

#2. Adopt The “SMART” Model For SLA

An SLA is a legal document that should be clear at the least but better ironclad. Once an expensive issue arises, so will the question of liability. Then, loopholes can be costly and moreover jeopardize a company’s reputation.

To avoid such situations, it’s imperative to follow George T. Doran’s “SMART” model, which does provide with a handy overview of service level agreement best practices:

• Specific. An SLA must be specific and detailed enough to define expectations for service delivery.
• Measurable. There must be a way to track actual performance against the promised SLA. Many service management platforms contain capabilities for comparing SLA promises against the actual time or other service measurement recorded for that item. In fact, it will be challenging to accumulate and prove SLA performance if your basic management tools do not include SLA targets and the measurements used while delivering service catalogu items.
• Achievable. The SLA must be realistic and able to be met. Unrealistic goals can demotivate your service delivery team.
• Relevant. The SLA must be directly related to the IT service being delivered and it must be relevant to evaluating performance against that goal.
• Timely. The SLA must contain a time frame against which the service will be delivered.

#3. Go Into Great Detail 

It’s more than vital that the SLA covers anything that matters in your service transaction, taking these crucial elements of SLA into close consideration.

For example, if the supplier has agreed on a personal success manager, how will they handle the scenario of their rep being unavailable due to illness? Since no one exactly knows when that happens, it’s a smart move to settle a time limit upon which the service provider will have to notify their customer upfront. Then, also communicate whether there will be a sub and if yes, the sub’s qualification, quantifiable through years of experience.

Another point which is often left underestimated is to state the “obvious”. What’s not covered by your service is relevant if it may inflict uncertainty. Plus, seemingly obvious exceptions like longer processing and response times during holiday seasons should be explicitly mentioned. These so-called “obvious” or “self-evident” should be paid adequate attention; otherwise, some contract breaches may easily happen.

#4. Review & Adjust

After all,an SLA describes the intersection of a customer’s operational needs and a provider’s capabilities to serve them. Both sides have their own operational needs, which due to market movements or deliberate strategic changes are in a constant flow.

Hence, for smooth operation, it goes without saying that an SLA has to be reevaluated every once in a while. For instance, an SLA commonly is reviewed after software updates and re-staffing in departments with direct customer contact.

The Bottom Lines

As a critical component of any outsourcing and technology vendor contract, SLA should be paid the attention it does deserve. Let’s follow these tactics and practices to craft winning SLAs with your vendors and partners.