This is another in the series of posts on the subject of Service Level Management – my last post in this thread started the topic of how to develop a Service Level Agreement (SLA) by defining the services you provide to users (more commonly referred to as the Service Catalog).
In this post I’m going to look at some of the data you might need to have before you enter into discussions about an SLA with a customer. I’ll start with the scenario of someone providing support to an internal customer base looking to set-up their first ‘formal’ SLA.
So, what data do you need? Speaking personally, I’d want to know approximately what our position was before any negotiations took place – so we can see if the gulf between what the customer might want, and we can deliver, is too large that we can expect to cross it with efficiency gains alone. Specifically I’d want to know:
- The average of expected number of Incidents and Change requests logged each month
- My average time to resolve Incidents, broken down by Priority. I’m not a big fan of average figures, so if possible I’d want a ‘spread’ graph that shows my the distribution of resolution times. For Serio users, this would mean SLA12.
- I’d probably want a few different ‘slices’ of Incident and Change logging data. For example, I’d like to know which user groups (departments or companies for example) logged Incidents and Changes with us.
- Most importantly, I’d want data on service availability (see our Availability White Paper for more information). I’d want our key service availability expressed as a percentage, and I’d also want some downtime statistics (in hours, per system).
- Information on customer perceptions of service – specifically data gathered from satisfaction surveys.
- Statistics on our callback performance.
- What Service Level Agreements we have, if any, with out most important suppliers.
- A few other miscellaneous statistics such as our first time fix rate, number of major Incidents, number of complaints received.
Ideally, I’d probably want this data over at least a 3-month period as well because availability statistics in particular are subject to ‘bouncing’ due to one-off major Incidents.
The reason I’d want all this is because it does no-one any good to sign-up to SLAs that are unachievable – you’ll simply set unrealistic expectations in the minds of your customers, and demoralise the IT staff that are working to meet the SLA. Of course it might be that your business needs a better service – but sometimes this requires additional investment in staff, training and infrastructure. Your discussions about SLAs should as a matter of course include these as subjects for discussion.
I’ll continue these series of posts later by looking at how we structure our SLA, and who we enter into these discussions with.