Every strong relationship is built upon clear communication, and clear expectations. That’s what Service Level Agreements, or SLA’s are all about. They clearly define the expected level of service from the provider (e.g. Cloud Software Provider) to the recipient (e.g. User of the Software).
Why do we need SLA’s?
When a service provider and recipient sit down to define the expectations of their relationship, the Service Level Agreement serves two purposes: a negotiation tool to balance the user demands against the resources available. After this negotiation is complete, the SLA defines the services that both sides consider to be reasonable.
The SLA give the customer clear expectations for reasonable levels of performance. And the service provider understands the details to which they’ll be held accountable.
Accountability also applies to the customer. The SLA defines the responsibilities of the customer, such as the format and nature of information they must provide when submitting a service request.
An additional benefit of the SLA is that it creates a culture of service quality. The process of negotiating an SLA causes service leaders to focus on quality service. And conscious adherence to SLA targets causes the service representatives to become more customer centric, by aligning their work with the customers’ priorities.
So, now that we know why we need SLA’s, let’s take a look at what makes a great SLA…
The 5 Parts of Great SLA's
The following five components should be included in every SLA. This is NOT an exhaustive list, but it’s a necessary core list. If you begin with the following five, you’ll be covering the core bases of an effective Service Level Agreement. So, here are the 5:
- When and how issues are escalated to a higher authority/expertise.
Escalating an issue is costly to the service provider, because the more knowledgeable or authoritative people are generally more highly compensated. And when those expensive people spend time resolving a customer issue, that’s less time they have to devote to more strategic, higher value projects. Therefore, it’s important to set boundaries on the use of these resources, by defining escalation rules.
- Clearly defined problem severity levels.
To a customer, every issue can seem like a high priority. But in order to effectively triage requests among a finite number of service representatives, severity levels must be set and agreed to in advance. When severity levels are routinely assigned according to a consistent set of rules, the service organization can work more efficiently. This benefits both the provider and the customer.
- Response and Resolution targets for each severity level.
A great SLA defines two “time targets” for each severity level. The Response target defines how soon after submitting the request the customer should expect to hear back from the provider. The Resolution target defines how soon after the request is submitted, that it should be fully resolved. These response and resolution targets comprise one of the most important criteria, because they apply to every request submitted to the service center.
- What happens when a target is missed.
No service provider is perfect. Or from another perspective, no SLA is perfect. Targets are bound to be missed on occasion. It’s important to define what the repercussions are for missing targets.A common example of this is the financial penalty if a SaaS (Software as a Service) provider exceeds the allowable system downtime.For example, if 99.95% availability is agreed upon in the SLA, and the actual availability is 99.90%, the customer is credited a certain percentage of the annual contract value.Defining these penalties within the SLA keeps the provider on task, and reassures the customer. It can also prevent lengthy disputes, if a target is missed.
- Clearly defined days and hours of service and contact information.
includes the hours of operation of the service center (e.g. 9am to 9pm ET, Monday through Friday, and 9am to 5pm on weekends). And don’t forget to define on which holidays the service center is closed!
