Tom Gabriele, Product Manager
Now that my system is up and running, how can I ensure that it remains that way over some acceptable level of time? If I want that assurance, I may enter into a SLA with my service provider. A SLA, or Service Level Agreement, is a contract between a service provider and their customer, either external or internal, which describes the service to be furnished, usually in some measurable terms. SLA's serve as critical components of many vendor contracts and list expectations of service type and quality; they also provide remedies when certain requirements aren't met. SLA's are usually between companies and external suppliers, but they may also be between departments within a company and represent a negotiated agreement designed to create a common understanding about services, priorities and responsibilities.
While SLA's originated with network service providers, they are now widely used across a myriad of industries. Firms that offer network-based services (ISP's), telecommunications and managed services, typically provide some sort of SLA's to their customers. Internally, Corporate IT departments, especially those that provide service management to various other departments, may enter into SLA's with their users in order to track IT resource allocation. They do so to measure, justify and perhaps compare its services with those of hiring outside vendors. The growth of cloud-based services in recent years likewise expanded the growth of SLA's into other areas.
A proper SLA pulls together information on all of the contracted services and their agreed-upon expected deliverables into a single document. It clearly states the metrics, responsibilities and expectations agreed upon, so that in the event of issues, neither party can plead ignorance, thereby ensuring both sides have the same understanding of the requirements. While not only including a description of the services to be provided and the expected service levels, SLA's should also contain the metrics by which the services are measured, the duties and responsibilities of each party, and the remedies and/or penalties for breach. The metrics should be designed so that bad behavior by either party is not rewarded.
An SLA should include components outlining two areas of coverage, services and management. Service elements include specifics around services provided and excluded, conditions of service availability, windows of time for each level of service (prime time and non-prime time), responsibilities of each party, escalation procedures, and cost/service tradeoffs. Management elements should include the definitions of measurement standards and methods, reporting process, content and frequency of reporting, dispute resolution process, and indemnification clauses protecting the parties from third-party litigation resulting from service level breaches (although these may already be covered in a master contract). The most critical management element within an SLA should be a mechanism for updating the agreement since service requirements and vendor capabilities change. SLA's should be periodically reviewed and updated to reflect changes in technology as well as any impact of new regulatory directions.
The service level agreement should be a communications tool for creating a common understanding between two parties regarding services, expectations, responsibilities and priorities. However, if it is established at the wrong time, for the wrong reasons, or in the wrong way, it can cause bigger problems than those it is trying to solve. If your current relationship is afflicted by distrust and finger pointing, now would not be the right time to create an SLA. The underlying problems should first be addressed before establishing an SLA, so that each party can start with a clean slate. Also, having the SLA initiated and established solely by the service provider, with little or no say from the customer concerning content or process, negates the benefits of a successful SLA. The principle of an SLA remains that both parties provide input. While sometimes rarely practical or feasible for every step in creating the agreement, a successful SLA requires collaboration of both parties. When truly collaborative, the two parties succeed in learning how to work together.
Lastly, as your business changes so may your service level requirements, therefore an SLA should not be viewed as a static document but rather reviewed periodically especially if:
Your business needs have changed
Your technical environment has changed
Workloads have changed
Metrics, measurement tools and processes have improved
An SLA remains a critical part of any supplier agreement and it pays off in the long-term, if it is properly thought-out and arranged at the beginning of a relationship. It should protect both parties, and, should dispute arise, specify remedies and avoids any misunderstandings, thereby saving considerable time and money for both parties.
If you have any questions about SLA's, please email us at inquiries@getgsi.com.