A common development in information technology all over the world—especially in the United States and Europe—is the use of application service providers (ASPs) to reduce the costs of application implementation and bring solutions to market faster. Organizations turn to third-party outsourcing for any number of reasons. Whether the objective is to obtain expertise or to reduce costs, application maintenance, and help desk operations, one of the most important ingredients for a successful relationship between an ASP and its customers is a strong service level agreement (SLA).
This article presents a general overview of the service level agreement, along with a list of issues you need to consider when creating your own SLA. The practical information provided here is derived from several years of experience in formulating information technology SLAs in the course of very large enterprise assignments and consulting agreements.
Contents of the SLA
A well-defined SLA records the expectations for both sides of the relationship and provides targets for accurately measuring performance against those objectives. The SLA lays down the boundaries of the project in a number of areas:
- Standard(s) by which service is measured
- Functions that the ASP commits to providing to the customer
- Volume of work that will be accepted and delivered
- Accepted criteria for responsiveness
- Quality of deliverables
- What should happen if something goes wrong
The SLA can end up as a very complicated document because it's meant to cover two sides, both of which are deeply interested in protecting themselves. In many cases, convoluted language in the SLA makes it complex to measure compliance. Loopholes occur due to obscure clauses related to availability, performance, and timing—all of which may be difficult to understand and measure. Therefore, preparing an SLA requires careful analysis and perhaps consultation with legal counsel.