Putting the "Service" in Application Service Provider

Application Service Providers are delivering many critical hiring management software tools, which require that agreements of service are clearly defined. A Service-Level Agreement (SLA) is a contractual obligation between an Application Service Provider (ASP) and its customer. It spells out the details of the service that the customer can expect from the ASP. In addition, it may specify penalties when these levels of service are not met. Service level agreements protect the customer, and give recourse when expectations are not met. The need for service level agreements is clear, but which details are important to include?

Infrastructure

Many of the topics addressed in a typical SLA concern the performance of the critical components of the ASP’s infrastructure, such as its network, systems, and the performance of the application. A SLA might cover:

• Allowable downtime
• Application response times
• Security issues
• Disaster recovery
• Scheduled maintenance periods

The Internet is the crucial bridge between the ASP’s application and the end user. The SLA should be clear on whether the ASP guarantees an end-to-end level of service, or if Internet connectivity is out of its scope of responsibility.

Support

The SLA should address issues that go well beyond simply specifying a percentage of uptime. Customer service is of equal importance in a business relationship with an ASP as application performance. Customer service issues that could be addressed by a SLA include:

• Help desk support
• Notification of changes
• Escalation process
• Usage statistics

Measurable Performance
It is not sufficient merely to list the issues the SLA is intended to address. The second step is to define specific and measurable performance metrics in order to set an objective standard to determine whether the various service conditions are met. For its part, the ASP benefits from a clear set of expectations rather than having to guess the customer’s expectations, or be held to a vague set of service conditions. It is better to take the time and be pedantic about the details and what-ifs up front, rather than sort out the legal responsibilities of the various parties after the unexpected has occurred.

Defining measurable performance metrics for infrastructure-related issues is often fairly straightforward, if a bit technical. The SLA could s pecify performance benchmarks to which actual performance will be periodically compared by a third-party monitor, and the reporting procedures. It is just as important to define ways of measuring levels of customer service. For instance, the SLA could set out quantitative metrics for how quickly the ASP reacts to or escalates technical problems.

Legal Documentation
In the end, an SLA is a legal document. Unsatisfactory or untimely performance on any of the terms of the SLA could trigger remedies such as financial penalties on the ASP. It is a good idea to involve legal counsel early in the SLA negotiations, since they may have to become familiar with new concepts in the licensing and delivery of software. Yet always let the business needs drive negotiations. The role of legal counsel is to make sure the metrics defined by the business needs are written into the contract.

An SLA is a living document subject to revision over time. Even if the relationship is running smoothly, a company may revisit the SLA in order to include new metrics or to adjust the expected level of performance from the ASP.

An SLA helps set expectations for both sides. It formalizes the framework for managing the relationship with the ASP and facilitates that relationship as one between business partners.