Home > Cover Story

Service Level Agreements

Crafting the Service Level Agreement

An SLA requires an analytical approach with a logical workflow to break down components that can easily be apportioned

Some time back, I had a personal experience where a telecommunications provider failed miserably at accounting for their failure. Those were the days when SLAs were unheard of.

As the story goes, one month, we received a bill stating that our 64 Kbps ISDN line had been used for 24 hours continuously for an entire month. We knew this was impossible as the only service we had running full-time was an ETRN mail server, which polls the telco's mail exchange (MX) periodically and does not run full-time.

We went through loops to dispute the total amount, but fearing being disconnected, we paid the full fee, and took the issue with their billing department. After a long tussle, they promised a refund of around US$2300 which never came. We painfully wrote off that payment, and took our business elsewhere.

However, the growing number of service providers has created more choice and driven the need for more accountable service levels.

Do You Need One?
An SLA is binding contract which specifies the provisioning of performance and service quality parameters between two legal entities (the service provider and the customer). One misconception is that SLAs are only managed security services. In fact, you can set up SLAs with your Internet access provider, systems integrator, network cabling operator, and even your auditor.

To craft one that works well requires not only a right dose of legal know-how, but also an in-depth understanding of the scope of service, the level of work to be completed, accountability (or the absence of), schedule, costs, and human involvement. It also requires an analytical approach with a logical workflow to break down components that can easily be apportioned to individuals or entities, and have costs and time factors assigned appropriately.

Let us look at a simple example of an ISP that provides leased circuit and business broadband services. It "guarantees" 24 hours uptime per day or it will refund twice the fees back to the customer. Sounds good? Well yes until you see the string of constraints attached.

For one, this "guarantee" is restricted to technical faults on the part of the ISP that arise from a failed connection at the ISP's gateway or a failed connection due to the ISP's equipment. The ISP also states that in the event of scheduled downtime, there will be no refunds.

At the same time, the customer will not get a refund if the fault lies in the customers' own LAN, equipment, failure of third-party telecommunication providers (presumably upstream). Worse, the customer is not protected against hacks by external parties, e-mail bombs, or viruses. "Acts of God" a term that those in the insurance trade will be familiar with are also listed as an exception, which can literally mean anything. Thus, even if the ISP purports to provide 99.999% uptime or higher, beware of the small print that can neutralize the intended SLA benefits.

The components required for a good SLA include: Service description, service availability and/or response time, acceptable range of service quality, metrics of measurement, formulae for the metrics measurement, frequency of measurement, rewards and penalties for performance targets, escalation and crisis management, and an addendum outlining definitions, people or departments involved, contact details, costs or fees, and other related information that completes and encapsulates the SLA.

Seamus Phan writes for Network Computing-Asian Edition. He can be reached at seamus@knowledgelabs.net

Essential ingredients for a successful SLA

A good description

When you can define and describe your service clearly and comprehensively, it is a good start to crafting the SLA. For example, a service description for a managed security offering can be: "To provide a comprehensive managed (outsourced) security solution that allows remote employees and business partners to connect to the internal network and data resources using an IP-VPN." A service description provides an overview of the service; detailed metrics, measurements, etc. come in later.

Primary requirement
Next, you describe the primary parameter of this service, be it system availability or response time. If you are buying managed security, then system availability would be the primary requirement. If you are buying a technical support or maintenance service, then response time would be primary.

Acceptable limits
Here is where the numbers game starts. You need to define a range within which the service should operate in. In an SLA for Internet access, you may list the acceptable range for availability as between 99.9 to 99.999%. If you are buying technical support services, you may list the acceptable range for response time as between 4 to 6 hours after a support call is initiated.

Metrics of measurement
An SLA is then further described by metrics, which drills down to smaller components of the service. If you are buying a managed security offering, you may need to describe QoS, availability, latency, downstream and upstream bandwidth, service resilience (with auto or manual recovery), and so on.

Here is where you outline the specifics on which the entire service will be measured by. If the service provider states that downstream and upstream bandwidth is "guaranteed" at 1.5 Mbps, then the method of measurement must so be defined-such as a Web-based interface or via command line.

The metrics of measurement is also integrated with how you calculate the results, using formulae that are universally accepted, or mutually defined. In a bandwidth scenario, 1.5 Mbps means that the leased circuit should allow upstream and downstream data transfers of 1.5Mbps. This is easily observed by the peak in an analysis chart for traffic that goes in, and goes out of the gateway.

Measurement frequency
Once you identify the metrics and how to measure them, you next have to define when and how often you measure these metrics.

Rewards and penalties
No service provider is infallible. Thus, the SLA must include service provider accountability. This can be a two-way street. If the service provider is consistently over-delivering their contractual promises, you may opt to include within the SLA a clause where you will increase your contractual obligations. For example, if the service provider over-delivers for one year with no major incident, you may automatically extend an additional year upon the lapse of the contract with no need for a new contract.

Obviously, make sure your SLA has clauses which allow you to recover funds, or provision for recovery services and extra personnel stationed on location till the non-compliance is resolved.

Expect enforcement
An SLA is like an insurance policy to protect you against the unexpected. Thus, at anytime, both parties must be prepared to enforce the contract objectively and continue the partnership. The SLA should have full crisis management and resolution clauses built in. For example, if the service provider has an upstream connection problem and you are locked out of the Internet, the service provider should then provide alternative equipment and a recovery team.

A good lawyer
Remember that the SLA is a legal and binding contract. Don't simply sign off on a service provider draft. Instead, engage a lawyer familiar with commercial law as well as new economy law (including intellectual property), and have the lawyer co-develop the SLA with your service provider and their legal counsel.

>>