Your team probably has service-level agreements (SLA) in place today with your internal or external customers, but are you sure they’re accurate representations of the service you can guarantee? This article will explain what a good SLA looks like and show you what you need to improve SLAs for any customer.
It has long been standard IT industry practice for a service team to set service-level agreements (SLAs) with their customers. Those customers could be external, but they’re just as likely to be others team within the same company.
The goal of either an internal or external SLA is to put everyone on the same page about what they can expect from the business relationship.
Good SLAs will include five core components:
Here is an example of the components of a basic SLA that a cloud service provider might set with an external customer:
The items above cover the bare minimum of what you should include in your SLAs. The next step you should take in improving your SLAs is to expand the documentation of your service and management processes.
There will undoubtedly be a tipping point beyond which more detail adds confusion, but in most business relationships, you’ll want to include information on the following:
As you can see, a good SLA isn’t really about technology. SLAs are just as integral as pricing and legal documents in your service contracts. A well-written SLA outlines everything relevant to the business relationship surrounding the delivery of an IT service.
Putting everything relevant in a single document is essential, so neither party can claim to be ignorant of their responsibilities should an issue arise. The last time you want to get into a disagreement with one of your customers is after a service interruption.
SLAs are a critical component in any IT service management process. Here are five often-overlooked best practices you should follow when drafting your own SLAs for internal or external customers.
Indemnification clauses are provisions where the service provider agrees to cover any penalties incurred by the customer should the service fail. For example, the provider pays the customer for any third-party litigation costs resulting from an outage.
Post your SLAs somewhere each customer can easily access them. Customers should be able to reference it whenever they need it. For confidential SLAs, that might mean in a protected customer portal. For broad public-facing SLAs, that might mean on a webpage.
Each SLA might require you to collected different metrics, depending on what matters to the covered customer. Two of the primary metrics you’ll likely need to track are:
Today’s cloud-centric customers often use applications or other services that straddle multiple cloud services. As a result, the metrics that matter to them often depend on services provided by those various providers simultaneously. Consider creating joint SLAs with those other service providers to keep everyone on the same page about how complex cloud architecture must run.
Additionally, the different service providers might want to draft Operating Level Agreements (OLAs) with each other. OLAs detail what each provider owes each other to honor their joint SLA.
SLAs need to have strict and well-defined penalties that can be enforced when minimum performance standards are not met. Usually, service providers and customers agree to apply a percentage of monthly fees tied to the vendor’s profit margin when SLA targets are missed.
Most highly functioning IT organizations do not use harsher SLA provisions as a punishing tool for their partners. Instead, they use SLA metrics to allow for fluid and productive conversations regarding performance issues, prioritization, and business relationships.
Reliable ITSM tools are important, of course, but sound business practices, like implementing a well-crafted SLA, are also essential to serve your customers and your team best. Both provide peace of mind.