ASP contract essentials
Scheuerman, Mike
As more credit unions look to outside vendors for providing online services to their members, they’re entering into contracts with application service providers (ASPs). Many of those contracts are derived from previous software license agreements and might not contain all the protections your credit union needs.
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, so long as they’re present 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 credit union’s service into the hands of a third party, you lose some control over the operational aspects. You’re relying on the service provider to meet your expectations for quality member service. To protect yourself from some of that risk, there are two service-level metrics you should address in your contract: uptime and response time.
* Uptime refers to the amount of time a system is available for use. It’s calculated as a percentage ofthe total available time. Ifyou 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 (Table I).
To get a good feel for what uptime levels are appropriate for your credit union, take a look at the current levels of service you’re providing your members. For example, if you’re 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 24/7 service levels, but you do want to have the system fully 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.
When negotiating your ASP contract, you’ll want uptime to be greater than 98% during operating hours. That number will exclude downtime for scheduled maintenance.
* Response time refers to the amount of time it takes to get an answer back from the system once you’ve entered the data 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 the data must travel through to get to the computer doing the work.
Determine what an average response time should be and build that into your SLA. For a system that’s doing a simple calculation and is directly connected to the user terminal, you would expect a response in less than two seconds. For a system that’s doing a complex task such as scoring a loan application and the user is connected via the Internet, you might expect response times of as much as 45 seconds.
The primary issue here is productivity. If an application is too slow, the users won’t get as much accomplished as they would with a more responsive product. They’ll also get impatient with what they perceive as a poor system.
If problems like this arise, you have a couple of enforcement options: You can ask to have your monthly fees refunded or you can terminate the contract. Both of these options are valid separately, but the combination is even better. If your uptimes don’t meet the SLA levels, you might want to consider getting a refund of a portion of your monthly fees.
For example, you might want to get a 10% refund for every percentage point your system was under the uptime level spelled out in your contract. If your system was up 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 your credit union. If the application wasn’t available, then you weren’t able to do business and there was some loss for which you should be compensated.
Build a termination clause into your contract to address chronic uptime and response problems. These clauses usually are triggered if problems persist for three to six months, or if you have chronic problems six out of 12 months. Be careful about invoking this part of the SLA because it means you’ll have to find another vendor and retrain your staff, which can be very time consuming and expensive. Determine whether the cost of changing is better than frustrating staff.
PROBLEM-RESOLUTION PROCEDURES
The second part of an SLA addresses how you resolve problems when things go wrong. It might 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-what “critical” means, what’s “severe,” etc. Along with those definitions, you should also get a resolution time frame, whom to contact to report a problem, and how often you’ll be updated on progress toward a solution.
If the problem isn’t solved in the agreed-upon time frame, what do you do? The SLA should contain an escalation procedure including contact information.
The last thing a good SLA contains is a list of reports you can expect to receive that tell you how well the vendor is meeting service levels. This could be just a couple of monthly e-mail reports or they could be detailed analyses of every aspect of the service. It doesn’t really matter how you receive the information. Just make sure you get something that helps you determine whether or not you’re getting the level of service you expect.
Most vendors will be willing to supply you with an SLA. It’s one way they can compete in the marketplace and show their commitment to their customers. If a vendor isn’t willing to supply most or all of the service levels and problem-resolution procedures, it could be an indicator that their support structure isn’t able to provide you with the kind of service you can rely on to reach your member-service goals.
MIKE SCHEUERMAN is business technology officer at First Tech Credit Union in Beaverton, Ore.
Contact Mike Scheuerman at 503-671-1454 or at mikes@1sttech.com.
Copyright Credit Union National Association, Inc. Dec 2001
Provided by ProQuest Information and Learning Company. All rights Reserved
