By Catalyst Consulting Group
Mike Scheuerman, CIO, MCP, Partner & Senior Consultant
As more institution’s look to outside vendors for providing online services to their clients, they are entering into contracts with Application Service Providers (ASPs). Many of those contracts are derived from previous software license agreements and may not contain all the protections that the institution needs in the world of remote, online services. There are some essential elements of an ASP contract that you should look for before signing anything. These are typically addressed in the Service Level Agreement (SLA) portion of the contract, but can be contained anywhere, as long as they are there and provide some enforcement mechanism. An SLA has two major components, Service Levels and Problem Resolution Procedures.
Service Levels
When you put a crucial portion of your institution’s service into the hands of a third party vendor, you loose some control over the operational aspects. You are relying on the service provider to meet your expectations for quality of service to your clients. In order to protect yourself from some of that risk, there are two service level metrics that you want to address in the contract, uptime and response time.
Uptime
Uptime refers to the amount of time a system is available for use. It’s calculated as a percentage of the total available time. If you have 99% uptime for the month, the system was available for use 712.8 hours out of the total 720 hours in a 30 day period. To get a good feel for what up-time levels are appropriate for your institution, take a look at the current levels of service you're providing to your clients. For example if you are providing online loan application processing only during the hours your branches are open, and you intend to continue with that practice, then you probably don't need 24x7 service levels but you do want to have the system up and functional when you're actively taking loan applications. The service level you want for the hours you're taking applications is very high, whereas the uptime for the rest of the day can be very low. Typically you'll want to get agreement for uptime to be in excess of 98% for operational use hours. That number will exclude any scheduled maintenance downtime. That means if the system is scheduled to be down for maintenance, that time will be excluded from the available time in the uptime calculations.
Response Time
Response time refers to the amount of time that it takes to get an answer back from the system once the user has entered data that the system needs to do its job. It’s typically measured in seconds from the time the user presses the submit key until data is returned to the screen. There can be a wide range of response times depending on the work the system is required to do to come up with an answer and the complexity of the network that the data must travel through to get to the computer doing the work. You want to determine what an average response time should be and build that into your SLA. For example, for a system that is doing a simple calculation and is directly connected to the user terminal, you would expect to see a response in less than 2 seconds. For a system that is doing a complex task like scoring a loan application and the user is connected via the Internet, you might expect to see response times of as much as 30 seconds.
The primary issue here is productivity. If an application is too slow the user will not get as much accomplished in the same period of time as they would with a more responsive product. They will also get impatient and perceive it as a poor system. Not a good customer service situation.
Enforcement
On the enforcement side of the SLA you have a couple of options. If the provider fails to perform at the desired level you can ask for a refund of monthly fees or you can terminate the contract.
Both of these options are valid separately, however, the combination is even better. If your uptimes don't meet the SLA levels you may want to consider getting a refund of a portion of the monthly fees you're paying for the system. For example you might want to get a 10% refund for every percentage point under the uptimes. If the system was unavailable on an unscheduled basis for 96% of the month and you had a 98% SLA, you would get a 20% refund on your monthly services fees. This again is a productivity issue for the institution. If the application wasn't available then you weren't able to do business and thus there is some loss for which you should be compensated.
To address chronic uptime/response problems, you can build in a contract termination clause if uptime and/or response time levels are not acceptable over a defined period. Typically that period would be a fixed timeframe of 3-6 months. You can also use chronic problems 6 months out of 12 to trigger a contract termination. You will want to be careful about invoking this part of the SLA, because it means that you'll have to find another vendor and retrain your staff which can be very time consuming and expensive. You will have to determine if the cost of changing is better than frustrating them continuously by having a system that is not up and usable.
Problem Resolution Procedures
The second part of an SLA addresses how problems are resolved when things go wrong. It may be a critical problem where the system is totally down or just a minor inconvenience. In either case you'll want to know what’s being done to fix the problem. You should have your vendor provide you with a set of priority definitions as they apply to problems, i.e. what does critical mean, what is severe, etc. Along with those definitions you should also get a resolution timeframe, who to contact to report a problem and how often you will be updated on progress toward a solution to the problem.
If the problem is not solved in the agreed upon timeframe, what do you do? The SLA should contain an escalation procedure including contact information.
The last thing contained in a good SLA is a list of the reports that you can expect to receive that tells you how well the vendor is providing the service levels. These may be just a couple of email reports on a monthly basis or they may be detailed analyses of every aspect of the service.
It doesn't really matter how you receive the information, just make sure that you get something that lets you determine if you've gotten the levels of service you expect.
Summary
Most vendors will be willing to supply you with a Service Level Agreement. This is one way they can compete in the marketplace and can point to the SLA as their commitment to their customers. If a vendor isn't willing to supply most or all of the Service Levels and Problem Resolution Procedures, you may have to consider whether their support structure is able to provide you with the kind of service you can rely on to support your business.
