The Outsourcing Continuum, Part VII: SLAs

By Mike Scheuerman

(Back to article)

When you put a crucial portion of your company’s service into the hands of a third party service provider, you lose some control over the operational aspects. You are relying on the partner to meet your expectations for quality of service. 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 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 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 don’t need 24x7 service levels but you do want to have the system up and functional when you’re 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

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 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 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 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 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 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 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 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.

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 mike@scheuerman.org.