The Outsourcing Continuum, Part VII: SLAs
Uptime refers to the amount of time a system is available for use. Its 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 company, look at the current levels of service you are providing to your customers. For example if you are providing online service processing only during the hours your offices is open, and you intend to continue with that practice, then you probably dont need 24x7 service levels but you do want to have the system up and functional when youre actively taking providing support to your customers.
The service level you want for the hours you are supporting customers is very high, whereas the uptime for the rest of the day can be very low. Typically, you will 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 refers to the amount of time that it takes to get an answer back from the system once the user has entered data. It is 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.
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 45 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 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.
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 dont meet the SLA levels you may want to consider getting a refund of a portion of the monthly fees youre paying for the system. For example you might want to get a 10% refund for every percentage point under the agreed to uptime. 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 your company. If the application wasnt available then you werent 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 time frame 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 will 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 will want to know what is 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 time frame, 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 time frame, 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 analysis of every aspect of the service. It doesnt really matter how you receive the information, just make sure that you get something that lets you determine if youve gotten the levels of service you expect and are paying for.
Most vendors will be willing to supply you with a SLA. 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 isnt 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.
Mike Scheuerman is an independent consultant with more than 26 years experience in strategic business planning and implementation. His experience from the computer room to the boardroom provides a broad-spectrum view of how technology can be integrated with and contributes significantly to business strategy. Mike can be reached at firstname.lastname@example.org.