This is another post about Service Level Agreements and Management. The last post on this topic is here.
This post is on the subject of things which could form part of your Service Level Agreement. I’ll list these things in two groups: core and additional. For core read ‘items covered even when the IT group and organisation is quite small’, whilst for additional read ‘items often found in larger enterprises’. The list isn’t exhaustive, but it will give you a general idea and hopefully pointers for when you come to try to create your own.
Overview and introduction. A paragraph describing the main aims and scope of the agreement.
Key parties. From both the customer and provider side (names of people, not just departments).
Scope. If there are specific exclusions or exceptions state them clearly. Sometimes it’s just as useful to say what you don’t cover as what you do.
Services covered by the SLA. Describe each Service carefully, avoiding unnecessarily technical language. I’ve discussed this at length here.
Hours of Service availability. Typically this will be expressed in terms of a day of the week and then a start-time and an end time. Usually exceptions will also be listed – such as public holidays. In some Service Level Agreements that I’ve seen, a seasonal element has been introduced – for example, extended availability in the run-up to the Christmas period.
Hours of support availability. As I’ve discussed previously, this is not necessarily the same as your hours of Service availability. The times I’m talking about here are when the ‘support function’ (such as your Helpdesk or Service Desk) is available. Like Service availability times, you will specify a start and end time with exceptions and special cases as required.
Reporting. Monitoring and Reporting is key, and in itself should form part of the agreement. Ideally a complete sample report will be part of the SLA, showing performance against target and highlighting areas for improvement. Your reporting interval should be clearly defined here also.
Performance Targets. I’ve touched on how to describe these in previous posts (with examples), but here you are looking at quantifying service returned. Availability of the services covered by the SLA is a good place to start. You can express this as a percentage, or as a maximum permitted downtime interval in hours – for more see our availability white paper. You can also include targets for incident response and resolution, as well as extending this to cover escalation procedures for different types of Incident.
Performance benchmarking. If we are defining services as part of the SLA, you sometimes need to bear in mind (as I’ve blogged about previously) that defining when a service is down can be tricky – for instance, if transactions are succeeding but slow. As part of your SLA you can specify acceptable transaction times for key business processes.
Expected volumes. If you are describing your performance benchmarks, you should describe the volumes on which they are based. For example, if your customer employs 50 extra staff over the holidays for sales order processing without warning the service provider, then this could have a very detrimental effect on overall performance.
Change performance. Targets around the processing and execution of user-requested IT Change.
Procedure for requesting extensions. Sometimes organisation need to have extended service availability. You can include the procedure for obtaining as part of the SLA, along with notice required by the service provider, and any associated costs.