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.
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.
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:
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:
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Lindsey has 18 years of operational, sales and commercial management experience. As one of the founders of BusinessTechWeekly.com, Lindsey is passionate about harnessing technology to drive business growth and efficiency to deliver optimum shareholder value. When not in front of a keyboard, Lindsey can often be found running the roads near her home, or swimming along the beautiful beaches of Bournemouth.
