CREATING AN EFFECTIVE SERVICE LEVEL AGREEMENT WITH ASPS.

Application Service Providers (ASPs) can save information management staff time and headaches--but you need to make sure you know what you're getting

The Application Service Provider (ASP) market is rapidly expanding because many companies are deciding to centralize their information systems departments with an outside vendor. In short, the Service Bureau concept has transitioned into the ASP model. The functionality of this approach is totally dependent upon the Service Level Agreement (SLA) between vendor and customer.

The ASP, specifically, is usually a company that maintains all computer networking, e-mail, Web services and application servers (e.g., financial, database) for a given customer. The customer is connected to the ASP via a wide area network (WAN). The ASP performs all maintenance and support of the client systems. All necessary backups and disaster recovery options are handled by the ASP. This is an effective way for some companies to conduct corporate business without expending large capital and operating expenses on information systems.

Creating a good working relationship with an ASP takes careful planning.

Consider the following scenario:

It's Friday afternoon, month end is approaching and the weekend staff will arrive shortly to finish entering the resident visits and MDS forms. However, your clinical and financial computer application just experienced a major problem. Your staff will not be able to save any new records into the clinical application. You now need to call the company's Help Desk for Product Support. The dilemma is, it's now 5:00 p.m. and the Help Desk is closed. What can you do? The possibility of waiting until Monday is unnerving. It means a whole weekend of downtime and a backlog of work when staff comes back.

Does this sound familiar? Why do these types of problems always seem to occur at month end? The answer and remedy to this problem lies in the SLA. The SLA is a contract between a vendor and a customer that guarantees specific levels of performance and reliability. The SLA is used to set customer expectations for availability, reliability and responsiveness.

The benefits of an SLA should be apparent to both the customer and the vendor. The vendor needs to have specific guidelines within which to operate its business, while the customer needs a clear idea of what to expect. One example of an effective SLA would require the vendor's Help Desk to respond within four hours of receiving a call during normal business hours. The vendor knows that in order to meet the minimum requirements of the SLA, it will have to return the customer's call within the four-hour period. The customer, on the other hand, knows that the agreement is only in effect during business hours.

A customer might consider the addition of an after-hours component or might want to spell out a remedy, if the provider does not meet the given four-hour response time. For example, the SLA might spell out pager or voice mail support, or even include a 24/7 Support Contract. This could add cost to the overall SLA contract but might be worth it when considering the downtime that would result without it.

Some specific areas that an SLA should measure include the following (and see the table for suggested values):

Customer Support Hours

* Normal business hours, e.g., 6 a.m. to 5 p.m.

* After-hours support--conducted by pager? E-mail? web tickets?

* Holiday support

* Weekend support

* Month-/year-end support

* 24/7 support

* Dedicated support staff available

Service Metrics

* Average response time (calls picked up within 30 seconds)

* 1st-call resolution

* Average resolution time

* Percent of time spent on phone

* Abandonment rate

* 1st-level support call %

* 2nd-level support call %

System/Network Reliability

* Percent of system availability

* Percent of scheduled downtime

* Application/services availability

* Response time to access network resources

* Network throughput (speed) of LAN/WAN (local area network/wide area network)

* Service utilization

With the SLA components defined, the tracking and reporting of this information to the customer is one way to differentiate one vendor from another. When the Support Center is contacted, the call should be logged into an Automated Customer Call Tracking System. This system should note when the call was made, the resolution of the call and the time it took to resolve. This information will serve as the foundation for the Support Metrics because it is not only important to log each and every phone call, but it is equally important to know how long it took to answer the phone, solve the problem and report back to the customer.

If any of these steps are missing, they need to be added to your existing SLA. Support Metrics is one way to define how the vendor meets your needs. If the metrics are set too low, then the customer is the only one who really suffers. As a general rule, an overall service level of around 75% is a great starting point for measuring a Help Desk's efficiency in regards to the SLA.

Nonsystem factors should also be included in the SLA. Some examples include performance and availability guarantees. If a specific level for these is not identified in advance, and a remedy clause is not included in the SLA, both parties will have a hard time deciding who's doing a good job.

The ASP Data Center must adhere to a set level of system availability and downtime. For example, the system must be 99.9% available during normal operating hours, with downtime limited to 1 to 2 hours per week in the middle of the night. The SLA for an ASP would also address issues of connectivity from the facilities to the Data Center. The throughput, or speed, of the connection must not degrade (or slow down) by more than 15% over a typical day. This means that the data lines need to be monitored, and if degradation is more than 15%, another line might need to be added. Technical requirements such as these need to be discussed with your Information Services Department.

The SLA must be adaptable to new services or deliverables and, in general, should be adequate to meet the needs of both parties. A termination clause should be included in an ASP/SLA contract, and if the contract has to be terminated by either party, the clause should include legal terminology protecting the parties from litigation.

SLAs should have both incentive clauses and penalty clauses to ensure performance and help drive the vendor's level of compliance to a higher level, and vendor performance statistics should be published to the customer base.

One final consideration: An SLA should address the vendor's mission and vision. That mission and vision should drive the SLA's objectives and goals.

Taking some of these suggestions into account, those after-hours support problems experienced by the facility in the scenario, for example, could easily have been avoided. It's all in the SLA.

David Anderson is the director of Customer Support for SHS.com (Shared Healthcare Systems), Anacortes, Washington. Anderson has more than 15 years' experience in support, consulting and development with large Fortune 500 customers.

                     Sample Support Metrics of an SLA.
Support Metric
Software Support:
Average response time (calls picked               75%
up in 30 seconds)
1st-call resolution (%)                           75%
Average resolution time (minutes)             13 min.
Time spent on phone (minutes)                  7 min.
Abandonment rate                                  15%
1st-level support call %                          70%
2nd-level support call %                          30%
System/Network Support:
Percent of system availability                  99.9%
Percent of scheduled downtime              1-2 hrs/wk
Application/services availability                 95%
Response time to access network resources  30 seconds
Network throughput of LAN/WAN                 10 MBps
Service utilization (bandwidth degradation        85%
[less than]15%)