system analyst and adjunct cio business analyst and technical writer

 Home  Who We Help  Services  Approach  Case Studies  Resources  Contacts  About Us


Does your organization...

» Critically depend on a software application?
» Rely on another organization to provide support?
» Experience significant application down time?

Answered yes to any of these?

You may need an SLA.

We can help.


What is a Service Level Agreement?

A Service Level Agreement (SLA) identifies the services to be provided for maintaining a software application or set of applications. The goal being to ensure reliability, security and availability. The SLA is a commitment between the application owners and the information technology people that support their systems. The SLA sets expectations and defines the boundaries of the physical environment.

What belongs in an SLA?

There is some fluidity in what goes into an SLA but here are some things to consider.

Description of the System

Define the purpose of each system or application and its scope. Explain its importance to the business such as essential, important or useful.

Time Period of the Agreement

When does the deal start and when does it end? Is it renewable? If so, how and when?

Identify the key roles required by the SLA

For example, there should be a primary technical contact on both sides. There should also be administrative contacts to deal with billing issues. Phone numbers, fax numbers, email addresses, etc. should be included.

Application Usage Metrics

For some applications, it is very important to know the size of the user population, the expected number of transactions over some time period, peak volume demands, etc. Exceeding these numbers could overly stress the system and result in failures.


Discuss normal business hours versus off hours. If you need 24x7 access, make that clear. Also indicate critical times when the system MUST be available, for example, month-, quarter- and year-end, daily from 3 to 6pm, etc. You may also want to specify when the system can be taken down for maintenance.


Specify the required uptime. Highly critical applications may require "five-nines" (ie. 99.999%) uptime. This is not usually the case however and can be costly. You might indicate that the system must be available at least 99% of the time during normal hours. Make sure you have a process to track that number. Someone needs to be accountable.

Performance Criteria

Establish benchmarks for the application. These may include expected response time for typical tasks, database query times, report generation times, etc. You may have to differentiate between peak and non-peak usage.

Problem Reporting and Resolution

How are problems reported? To whom? Indicate preferred methods of contact (eg. phone, email, pager, etc.). Specify how problem resolution will be managed, who will manage it, and how progress updates are to be provided. Also make it clear how priority is established. Urgent issues require immediate attention (4 hour or same day response); important issues require action within 24 hours; secondary issues can often be put off until the next scheduled maintenance check.

Periodic Review

You may want to periodically review performance against the SLA. This is often done more frequently early in the agreement period and less frequently later on. State what the penalty will be if terms of the agreement are not met.

If you think through these issues, you'll be able to set expectations both with your user community and with your service provider. Then you can spend more time focused on what matters to your business.

You should also take a look at our article called "What Are Best Practices?" for more information.

Service level agreement

Not Just Vendors

You may think that SLA's apply to outside vendors only. But that's not the case. Any two organizations within a company can create an SLA between them.

Why would you do this?

-To set expectations.
-To get on the same page.
-To establish goals and objectives.

If your team is dependant on software to get its job done, you need assurances that the software will operate reliably and be available when you need it.

SLA's are not about forcing people to do their jobs. They're not about binding, legal contracts.

They are about clearly defining what's expected and putting a process in place to meet those expectations. When done well, everyone benefits. Everyone wins.