Mastering Service Level Agreements: Best Practices for SLAs

Service Level Agreements, or SLAs, are a vital piece of any outsourcing contract. As SLA development and management have evolved, common service level agreement best practices have become established, going beyond setting expectations for the service type and quality and driving business insights and performance.

Having Service-level agreements (SLAs) in place has always been good practice for businesses working with IT service and cloud service providers. However, as SLAs increasingly become the primary measure of performance, it has become more vital than ever to understand the best way to negotiate, structure, manage, measure, and report on SLA metrics to drive business value.

Following are SLA best practice tips on how your organization can craft effective Service-level agreements with your vendors and partners to improve business performance and drive value.

What is a Service Level Agreement (SLA)?

A service level agreement is an agreement between a service supplier and customer (whether internal or external) defining the services that will be delivered, setting expectations for the responsiveness, performance measurement, and the remedies or penalties should the agreed service levels are not achieved.

For example, A telecom company’s SLA may promise network availability of 99.999 per cent. If this network availability is not achieved, the customer may be entitled to reduce their payment by a given percentage.  The reduction will be on a sliding scale based on how much and for how long the breach exceeds the SLA thresholds.

The best practices tips for Service Level Agreements, outlined below in this article, can help you negotiate, structure, manage, measure SLAs to deliver value for your business.

Why are SLAs required?

SLAs are a fundamental agreement between a service supplier and recipient that is critical in establishing trust. They are a mechanism for handling customer expectations and inform the team of the sequence in which issues need to be resolved.

Service Level Agreements can promote best practices and provide benefits, such as a shared awareness of quality needs.

Implementing SLAs will support your business in several ways, including:

• Strengthening Vendor and Customer relationships – SLAs alleviate any apprehension towards risk, thereby increasing confidence between parties. They minimize ambiguity by specifying what happens in the case of a breach.
• Formalizing communication – Conversations about IT issues with stakeholders can be challenging. Nobody wants to hear from a customer ten times a day or let clients stew over their unspoken service performance requirements silently. An SLA allows stakeholders to have formal discussions based on previously agreed-upon terms.
• Improving productivity – SLAs set the priority of incoming requests. Consequently, SLAs can help focus the teams’ attention on the most critical issues for the client.

Service Level Agreement Challenges

It’s bad enough to be given false promises, but there’s a more sinister side to an SLA.

Service Level Agreements, despite best efforts, in practice can lead to one or more significant challenges. They can do more than disappoint; a genuinely dreadful one can do considerable harm to both the client and the supplier.

Here are some common issues that organizations can encounter while reviewing SLAs:

• Tracking SLAs can be challenging – changing them is even more difficult. Many IT managers must retrieve a large amount of raw data, write custom queries, and create elaborate Excel formulas and reports to determine how they are doing in relation to SLA. Furthermore, SLAs are frequently custom or hard-coded into several service desks, which means that changing them can take days of development effort.
• SLAs do not always align with business interests. SLAs rarely seem to shift or grow at the same rate as the company. In reality, they are often inherited. Someone founded a SLA a decade ago, and it is still honored today simply because it exists.
• Lack of reporting versatility. Despite the fact that there are many specific circumstances affecting SLA attainment (such as how long it takes a customer to react to you, etc.), most SLA reports do not easily account for them. You either met or did not meet your SLA. There is no way to illustrate anything in a report that explains why or aids in continuous improvement.

How is the Service Level Agreement created?

The best way to commence is to start with your supplier.  It is standard practice for most service providers to have pre-existing service level agreements (SLAs) templates — each reflecting a different level of service at a different rate.

In many cases, these are already likely to conform to SLA best practices. However, since they are typically skewed in favor of the seller, they should be reviewed and, if possible revised, by you and legal counsel.

When sending a Request for Proposal (RFP), a good practice is to include anticipated service levels in the request; this will influence supplier services and pricing and the supplier’s decision to respond.

For example, suppose you need 99.999 per cent availability for a service, and the supplier is unable to meet this requirement with the design you specified. In that case, the supplier can suggest a different, more robust solution.

What to look for in your SLA

The SLA should provide a summary of the services to be rendered and their planned service levels and metrics for measuring the services, each party’s roles and obligations, remedies or penalties for violation, and a process for adding and removing metrics.

It’s best to ensure that metrics are structured so that neither party’s poor conduct is rewarded. A good practice, for example, is to if a quality level is violated because the customer failed to provide information on time, the provider should not be penalized.

The SLA should include two components: services and management. It common practice for SLAs to cover the following areas. However, before you sign any SLA, it best to consider what is acceptable to your business:

• Does the Service-Level Agreement include the resolution time or only response time? Unfortunately, most suppliers are reluctant to include resolution times, since the most severe issues (such as hardware failures) are likely to take the longest to resolve.

For instance, an unexpectedly offline server may have several resolutions. The issue may be resolved by a simple server restart, which might only take a few minutes. Alternatively, a root cause could also be a hard disk failure. In this instance, a resolution will be far longer. Yet both these issues may be classed as ‘severe’, and be subject to the same resolution time.

• Are any types of issues excluded? Despite best efforts, it isn’t always possible to solve a problem in a couple of hours. For example, your IT provider may need to order a component or come to your office. It is a normal practice for an SLA to exclude situations like this.
• Are there any caps to the compensation? It is common practice for SLAs to set a limit on account credits. Make sure that you are satisfied with this. If not, you may wish to negotiate a provision which states you have the right to terminate the contract if the service provider reaches the limit.
• How is the SLA measured? Many SLAs, for example, are only applicable during the regular working day. Therefore, you will have to pay a premium for 24-hour coverage.
• Does the SLA cover your obligations? For the SLA to apply, you must uphold your end of the agreement. The best way to do this is to be clear about what you can and cannot do.
• Does the SLA contain an indemnification clause? An indemnification clause is a condition in which the service provider promises to compensate the consumer company for any violations in its warranties.

How best to set SLAs and measure performance

From the customer’s point of view, the SLA should say where the limit of acceptable service lies and provide sufficient motivation for suppliers to perform within this limit.

From the supplier’s point of view, the Service Level Agreement should define clear targets for good service that can be met with acceptable risk and provide a continuous incentive to improve.

It is a sensible practice to revisit your SLAs regularly to ensure the SLA is best meeting the organizational needs:

• Establish a baseline – One of the best places to start is by looking at your current SLAs and how well they are being performed. Next, review the services offered and how those align with the business goals of your company and your customers.
• Solicit feedback – Talk directly with customers and solicit constructive feedback. What is done well, and what could be improved? Are the right services being offered.
• Draft the Service Level Agreement – Remove any services no longer required, and add any services based on the feedback provided. When setting new SLA metrics to monitor, track and report, take a look at your current SLAs, and assess how well they:
  • Correspond with the services being offered
  • Align with the details of the service contract
  • Support your needs/wants
  • Can be monitored and measured
  • Can be managed
• Choose measurements that are easily collected – Balance the usefulness of a desired metric with its ease of selection. For example, the SLA metrics should ideally be collected automatically, in the background, with minimal overhead, but this goal might not be achievable for all desired metrics.
• Document how services are monitored – The SLA should also identify how data will be captured and reported, how often it will be reviewed, and who will be involved.
• Get management support – A successful SLA will have the blessing of management. Begin by getting your management to buy in and then gaining their support to negotiate with the other party’s management team.

10 Service Level Agreement Best Practices to follow

Common SLA pitfalls include treating service-level agreements as a one-time exercise to failing to drive business value.  While there is no magic formula for a good Service Level Agreement but there are some best practices you can follow to ensure your SLA is tailored best to your needs:

Agree on SLAs upfront

One of the best practices that can be employed regarding SLAs is for both parties to negotiate SLA terms before an issue exists.

Both parties often presume that expectations are clear and mutually shared.  However, that’s always the case if they are not spelled out in a document such as the SLA.

A contract is not a one-sided declaration of IT capabilities or a one-sided demand for business requirements. Instead, an agreement entails developing a shared understanding of expected service delivery and efficiency, estimating costs associated with goals, and then agreeing on results in return for investment.

Address security and compliance

A valuable best practice is to ensure the Service Level Agreement pushes service providers to address security and compliance.

Review and consider what continuous commitments the provider has made around disaster recovery, encryption, incident response, or vulnerability assessments.

Be sure the SLA is measurable

Another best practice to ensure a method to measure the Service Level Agreement is identified.  Its best that these  methods and processes are straightforward, understandable, and simple-to-use.

Unfortunately, it has become common practice to create a performance metric without sufficient data to back up the objective. This approach is not the best way to handle the SLAs and may result in unnecessarily onerous or neglected SLA management.

There is the potential to use data and process discovery tools to assist with measuring Service Level Agreements. Although these tools are not widely used yet, they provide an opportunity to define the most critical metrics and objectively quantify efficiency (e.g., cycle time, quality, compliance).

When Service Level Agreements are measured by the customer and sufficient supporting data is created, the reliance on the service provider resources as the source of truth for performance data diminishes.

Set thresholds

To ensure your SLA delivers value, it is good practice to have a defined consequence if an SLA is breached.  Without clearly defined points in the contract, the SLA isn’t worth much. These are crucial for ongoing poor performance or missed objectives.

The best way is to clearly state thresholds defining ‘x’ number of times in a given period and should be reviewed with the vendor regularly.

Not every violation need to have a penalty. Some of the most successful SLAs have no penalties whatsoever, other than perhaps the chairman coming along for a quiet chat demonstrating a desire to work together between the supplier and the user towards the best business solution.

However, our SLA must clearly define the consequences and the expected outcome from these – whatever that may be.

Don’t view SLAs as a one-off exercise

Getting the right business results by SLAs and service integration is like running a marathon. It is a continuing aspect of IT’s core competency.

IT leaders must develop muscle memory when it comes to identifying their position and recognizing the dollars they invest in relation to business results or benefits. IT organizations should develop expertise in managing SLAs in order to realize value.

Use the SLA to drive performance

When SLAs are viewed as a revenue stream rather than a source of knowledge to drive performance enhancement, it breeds contention rather than business benefits. Customers should not be concerned about recovering their losses. When a network outage occurs, the harm is always done. Instead, IT leaders should concentrate on SLAs that keep the provider responsible for the highest quality of service from the start.

Setting artificially — and often unrealistically — high-performance expectations raise provider costs without actually resulting in a corresponding market gain. Furthermore, vendors understand that SLA clawbacks are one-sided. As a result, if revenue clawbacks occur due to nonperformance, then exceeding SLAs could also include revenue incentives. As a result, two-sided SLAs are becoming more popular.

Take responsibility

The customer plays a crucial role in service delivery. And those who cultivate the most fruitful relationships with their service providers are aware of this.

It is a mistake to fail to consider the position of the service user in allowing service providers to operate as intended. SLA prerequisites which state that a certain threshold will not be met if a vendor does not obtain all of the necessary information from the requesting entity in order to perform the function.

As a result, a company must determine whether the sophistication of its internal processes allows for the type of SLAs that it expects from a vendor. It is likely that SLAs was implemented but never enabled because the vendor’s prerequisites are not met due to the organization’s immaturity.

Minimize the number of SLAs

An overabundance of SLAs will violate agreed-upon service, resulting in virtually meaningless service credit. Too many SLAs dilute the effectiveness of the service, making it difficult for providers to know which are the most important to prioritize and effectively manage.

Individual infrastructure and application component uptime-focused SLAs are also troublesome.

With a greater emphasis on business outcomes, SLAs should consolidated and comprehensive, addressing broader umbrella categories or outcomes.

Avoid using SLAs as conflict resolution tools

It is a mistake to rely on contractual language to settle a problem before delving deeper. Rather than dwelling on who was contractually at fault and what penalty should be imposed, the first step in any dispute should be recognizing the effect and attempting to address the damage.

Prioritizing the consumer relationship and result is more critical than litigating technological or organizational misunderstandings that could have contributed to the dispute in the first place.

Read the fine print

To ensure that SLA meanings are met, a provider may modify them. The Incident Response Time metric, for example, is supposed to ensure that the provider responds to an incident within a certain amount of minutes. Some providers could attempt meet the SLA 100 per cent of the time by sending an automatic response to an incident report.

The contract should define the services to be rendered, and it should also document how the services will be monitored, including how data will be collected and reported, how often it will be checked, and who will be involved in the review.

How often should SLAs be reviewed?

When companies evolve, so do their service needs. An SLA should not be regarded as a fixed text. To align with best practices, SLAs should provide a specified mechanism for contract adjustment during the duration of the contract.

The SLA should be checked regularly, particularly if:

• The client’s business expectations have changed (for example, establishing an e-commerce site increases availability requirements).
• The technological landscape has changed (for example, more reliable equipment makes a higher availability guarantee possible).
• The workload has shifted.
• Metrics, measuring instruments, and procedures have also been enhanced.

The SLA is an essential component of supplier management, and it will pay off in the long run if it is well thought out and codified at the start of a relationship.

It protects all sides and, in the event of a conflict, specifies remedies to prevent misunderstandings, saving both the client and the supplier a lot of time and money.

A simple set of formal reviews that ask the questions shown in the above diagram is enough to keep the SLA live (and, therefore, useful). In most organizations, this is a straightforward adjunct to an established quality or project management structure.