How to define your Service Level Agreement

A SLA, Service Level Agreement, is a mechanism to manage customer expectations. The term agreement is often used in contract form, where the organization describes its services for the client. Sometimes service contracts actually have penalties in the contract. Using the SLA in this approach can result in a complaint mechanism, where the provider is judged against what he did not achieve.

We believe that the SLA’s purpose is to give the organization a tool which can be used to continuously monitor its performance in order to continuously try to increase customer satisfaction.

As soon as the customer and the organization both treat the SLA exactly to the letter you get in a situation that the service team only works against the SLA instead of working for the client. For example it could well be that the SLA determines that an issue must be resolved within 48 hours and the service desk actually achieved this, but the customer is very unhappy. The solution could have been to help the customer to get the job done within 24 hours with a completely different solution and the actual issue be solved in 72 hours way outside of the actual agreed service level and this customer is very happy.

So think of an SLA as:

• Communications tool. The value of this agreement is not the signed contract. It is the process to implement the agreed service and continuous improvement of this agreement. The SLA should be there to measure against and to use as a discussion platform together with the client. It gives you the instrument to talk.
• Collaboration tool. The SLA is something which is agreed upon between 2 parties. It clarifies what one party offers in services and it sets the right expectation at the other party what they can expect. It helps to avoid conflicts.
• A living document. As organizations change during their lifecycle the SLA should grow with the organization. For example an organization moving more to the internet will have a different need.
• A basis to measure service effectiveness.

Do you really need an SLA?

Think carefully if you really need an SLA. Many organizations seem to think that an SLA will solve the problems they have with their vendors or with their IT department. If you think like this the SLA is more used to increase the pressure on your supplier and is mostly used as a stick to beat someone with. Most organizations can significantly improve their ability to manage expectations with some relatively simple service improvements. One such improvement is to create service standards and to document and communicate them. Having done so, you are one step closer if you decide to establish an SLA.

What should be in the Service Level Agreement?

The SLA should contain two elements. The actual service elements and the management elements. The service elements clarify what the service organization communicates.

• The services you provide
• Service availability
• Service standards like Time to Resolve, Time to Fix, Time to Respond, etc..
• Responsibility of the service provider as well as the client. It should be very clear where everyone’s responsibility starts and ends. For example. A service provider can be responsible for software on a server, where the server can be the clients responsibility
• Cost vs Service trade off. The highest level of service might be only achievable at a high cost. For example an SLA with a software vendor where you agree upon 99,99% availability might be only achievable if the vendor is responsible for both hardware and software and can only be achieved if there is a full service redundant system and software available. Is this really necessary? Is the complete business down because of a 4 hour downtime for example? I would say yes if this concerns a trading software for a business working on the stock exchange. I would say no if it is a software that is not business critical. This last example is an example which we actually regularly receive ourselves as vendors of service desk software. Whenever we than say, ok we can do that, but are you sure? It is not that your service desk team cannot help your customers anymore. Very often the client thinks about this and realizes it does not really make sense. In other words. Be realistic.
• Escalation procedures.

More information can be found in the whitepaper.

The whitepaper will give you the complete story inclusive of:

• Work towards the agreement together with the client
• Make an inventarisation
• Implementing the agreement
• Develop the agreement
• How to define the Serviceable times?

Download the full story here. No need to leave your details.



How Can IncidentMonitor help

IncidentMonitor contains a service level management area that encompasses three sections:

• Service Hours section – allows for each unique area to have designed service hours that organizations have contractually or verbally agreed to ensure that service violations will only occur based on contractual agreements and not linear time.
• Service Matrix – enables an organization to define its service policies based on the contractual or agreed to Service Level Agreements (SLA’s) also providing the facility to define serviceable hours.
• Service Level Rules – provides a customizable service management engine that allows organization specific service level rules to be defined based on contractual obligations with rules able to be bound to any user defined state.