Choosing the right IT service provider is critical. Just as important — understanding your IT service provider’s service level agreement (SLA) and determining which parts of your IT infrastructure and applications need to be covered.
- Who Needs an SLA?
- What's the Purpose of an SLA?
- The Nine's
- Now That Your SLA Is in Place, What's Next?
In its simplest form, an SLA is a contract between a service provider and a customer that specifies, in measurable terms, what services the service provider agrees to provide in exchange for a fee.
No one ever really wants to think of being without service or having an interruption in normal processes, but things happen. However, having a solid SLA in place that protects both businesses and service providers is critical. To be effective, however, it must be created when the contract is first signed.
Any business that outsources any part of their IT infrastructure should have an SLA in place. Usually, SLAs are between companies and external suppliers. It’s a contract that protects both parties — the business and the service provider.
At the core, SLAs all guarantee the service provider will deliver on something. It’s the “something” that truly sets SLAs and providers apart. Understanding and establishing what the “something” is that the SLA protects is one of the most critical components. Another significant factor is the compensation a company will receive, should the service provider fail to deliver on their agreed upon SLA.
Oftentimes new to market providers will wrap an SLA around response time. However, businesses experiencing an outage or interruption in service rarely find this to be satisfactory in the long-run. It’s because responding in accordance with the parameters established in an SLA is very quick and easy (often automated).
On the other hand, an SLA based on the availability of a system or application is far more meaningful — and much more complex for a service provider to deliver on. Only a mature service provider will have the people and processes to deliver on an available SLA.
Take for example a credit card processing company who is unable to process transactions. If the interruption lasts a few minutes, it’s a big deal. What if it lasts an hour, half-a-day, or even longer? It quickly adds up to significant financial loss and can lead to greater consequences. If the SLA is based solely on the service provider responding within a certain amount of time, how does that help the business recover? In this example, is the service provider incented to resolve the issue ASAP? Not really. However, the service provider who is guaranteeing availability of the down application is certainly doing everything possible, as quickly as possible to resolve the issue.
The magnitude of the issue and the potential impact on a business could (and should) be factored into the SLA. Although the definition and concept of an SLA is mutually agreed within the industry, there are lots of differences in how providers define SLAs. It’s important to establish the parameters ahead of time.
Six segments to understand when discussing SLAs:
- Definition of what the SLA intends to provide to both parties (business and service provider).
- Clearly define each system or application that’s covered (e.g., hostname, IP, serial numbers).
- Definition of an SLA violation and metrics by which the service is measured. If an outage occurs, what are the established time increments?
- Outline the level of service expected by the business from the provider. Do you expect them to call within a certain amount of time? How frequently do you expect updates as the situation is being escalated and resolved?
- Remedies / penalties should the service levels not be achieved. How will your business be compensated? Service providers typically offer service credits to customers should performance be compromised.
- The expectations of the provider. What does the service provider expect from the customer? If the customer’s staff is unavailable, does that void the SLA?
Another important element to understand when establishing an SLA with your service provider — they are typically measured in nine’s. Essentially, the more nine’s the less downtime service providers are allowed annually.
- Customers should review their service provider SLA any time a contract change is made. Does the SLA still align with the business needs?
- Monitor and manage the SLA. Is it your responsibility to notify the service provider of an outage?
- Customers should set appropriate expectations with their IT staff and business units to align with SLA expectations. This is often a gap.