Deciding What SLAs You Need (Part 1)

Serio allows you to create multiple Service Level Agreements (SLAs). But how do you know what and how many SLAs you need, and is it a good idea to have multiple SLAs?

Over the next few posts I’ll be looking at these questions by considering a real world situation where an SLA must be designed, and the decisions taken in designing it.

I’ll start with a reminder of what a Service Level Agreement is, and what it is not.

A Service Level Agreement is an agreement with your customers describing the minimum levels of service they can expect from the Helpdesk/Service Desk. As such it may include such things as the times during which the service is available (e.g. 9-5.30 Monday to Friday, or 24/7), target response and resolve times for Incidents of different priorities, and levels of availability of IT services, such as email and key applications.

Key Concept: A Service Level Agreement should make levels of service predictable from a customer’s point of view.

For example, the Service Level Agreement may say things like: “A high priority Incident is an Incident that is preventing you from working, or seriously disrupting your work – for example, if your workstation or an important software application you use is not functioning. We aim to resolve 95% of such Incidents within 2 working hours.”

A Service Level Agreement is not meant as a direct measure of performance of Service Delivery staff and you should not design SLAs to measure Agent performance. (Of course, Helpdesk/Service Desk performance must be measured against the SLA, but the SLA’s main function is enable customers to predict the level of service they will receive, and the latter must the principal consideration in designing your SLA.)

In the next post I’ll introduce a real world situation requiring an SLA to be designed, and in subsequent posts at the decisions involved designing the SLA.