SLA Statistics

[Marc_EduTech]

Evening All,

 

I hope I'm using the correct forum for this, however I was wondering if I could throw out a few questions regarding SLA Statistics Reporting within your establishments?

 

At present I run weekly reports identifying the following data:

- Technician

- Calls closed within SLA

- Calls closed outside SLA

- Total calls closed

- SLA %

- Total calls still open

- Break down of calls that remain open if older than 2 weeks

 

I've noticed when reading through various reports written by myself and some of the other managers within our establishment, that we're finding the start of the academic year produces statistics that show a massively increased workload based around the number of calls logged during this initial period.

As a result, the SLA % for each individual technician drops quite substantially, requiring a fair time to return to sufficient levels.

 

My questions to those running similar reports are therefore as follows:

 

1. What data do you extract from your Helpdesk when reporting?

 

2. How frequent are you writing said reports?

 

3. What SLA % do you require from your Technicians, and does this differ from your own (if in a Senior or Management position)?

 

4. When reviewing your yearly statistics, do you see particular times when you receive substantially increased numbers of logged calls?

 

5. And finally (I think), are you seeing these times negatively effecting the SLA % of your Technicians?

 

Any and all responses most certainly welcome!

 

Thank you in advance

@Marc_EduTech

[featured_spectre]

1. Extract volume of calls. Volume of completed calls. Who completed them and the percentage each person completed

 

2. Once a month

 

3. Techs - 80% turn around. Senior tech - 90%. NM - 95% (based on the fact some calls need to get escalation to the next level depending on access needed).

 

4. Yes. Tax year end. Financial year end and when there are new starters.

 

5. Not massively. Techs do the bulk of the work with senior techs over seeing or training as well. When senior techs get a call they're expected to have the experience to close it. If domain administration is needed it goes to the nm. If it requires external repair such as printer repair or copier repair then that gets done.

 

Also I figure that new starters account for between 5 and 15% of the call out stats for the first 3 months after they join. After this it drops. Before you ask....all staff get given training on all aspects of what is running and get given sheets as well as an intranet to look at with videos. Just sometimes they dont. However if after the 3 months they're still asking basic things we've gone over, an email goes out to them, and their department head to either get them further one on one training or they get a talking too by their dept head to buck up their ideas and review the materials given (everyone signs a document that they have received the training and acknowledge that they should review paperwork and intranet before coming to us).

[pcstru]

1. What data do you extract from your Helpdesk when reporting?

Incidence of opened and closed cases per day. That gives us the major trend. We do some case age analysis and look at what is stalling and why. We do some measures of customer satisfaction using metrics gathered from the tickets when the customer closes the case.

2. How frequent are you writing said reports?

Monthly, quarterly and yearly.

3. What SLA % do you require from your Technicians, and does this differ from your own (if in a Senior or Management position)?

Our SLA's primarily relate to what the customer can expect on every case and what they can do if that can't be met. There is a secondary goal of providing evidence that we are aligned with the needs of the organisation and have the resources we need to do that. That said, I think if a technician was consistently getting poor feedback, we would be interested in the why of that, but we don't have standard metrics defined by which we measure an individual technicians performance, largely because the job is so varied and problems can be anything from trivial to impossible. We do try to build into the professional development process our strategic goals (so increasing customer satisfaction) but while metrics can be evidential in that, they are not a regularised whipping post, as happens in some environments. We also manage the workflow in a way that someone would not get away with incompetence or slacking off. The real problems are generally more along the lines of stopping them from drowning in issues (how do we get people to help themselves).

 

4. When reviewing your yearly statistics, do you see particular times when you receive substantially increased numbers of logged calls?

The start of the year and start of any term. September generally causes substantial backlog.

5. And finally (I think), are you seeing these times negatively effecting the SLA % of your Technicians?

Those times just result in some difficult decisions on priorities and a general lowering of satisfaction as people have to wait longer for support. I think those times would highlight how inappropriate a technician SLA would be, since they would be impossible to meet and a major source of de-motivation. I'm happy to measure machines by SLA (% uptime etc), but I'm not comfortable that you can measure people that way.

[Marc_EduTech]

Morning both (@featured_spectre and @pcstru), and thank you for your responses.

 

I'd like to try and *bump* this thread up a little, and see if there is anyone else out there willing to offer their own take on these questions.

 

Thanks

@Marc_EduTech

[steve]

It sounds like that you are compiling management reports as well as SLA reports.

 

I'd differentiate them as:

 

Management - for you and your LM to understand what is currently happening - high workloads, absence, holidays, system problems, etc.

 

SLA - A status for the wider organisation / customers.

 

 

1. Data to extract - what is meaningful and measurable.

 

For a management report - category of calls, vol calls, open calls, calls complete, calls per tech, % calls closed in SLA, categories of calls, origin of calls (depts). Graphs / trends of these measures over a 18 month rolling period to spot trends.

 

For SLA - keep it simple, 2-5 key performance indicators - category of calls, vol calls, calls complete, % calls closed in SLA, origin of calls (depts).

 

Also data that may be external to the helpdesk - customer satisfaction.

 

And I'd expect technicians to tell me if there were a significant change in the number or / type of jobs coming in. Don't lock yourself away and manage by metrics.

 

Remember that whatever you measure, it will influence the behaviour of the technicians. Have clearly understood expectations of the behaviours you expect.

 

2. Frequency

 

For management reports I'd go with a reporting period that matches your meeting schedule with your line manager. Weekly / fortnightly / monthly.

 

For full SLA - that would depend what you have written in the SLA, but at most once per quarter, but I used to do once per year (part of my annual review and other annual meetings). This averaged out the peaks / troughs of workload, but peaks could easily be shown using month by month calls logged graphs.

 

3. % SLA from technicians - No numeric expectations as holidays / absence / projects / etc could have too much impact. But conversations about the data at regular one-to-one meetings would add meaning and context to it. Reviewing some of their tickets to check behaviours.

 

4. Busy periods depend on where you work. But typically after long holidays (password resets / failed equipment / etc.), financial year ends, reporting (schools), after new systems are introduced, any large influx of new users, periods when people have free time (e.g when exams are over) - they decide its a good time to learn some new IT stuff when they have time.

 

5. Busy periods will negatively affect % SLA if you measure it. Unless you employ a reasonable amount of staff and can move their resource around to counter it e.g. no project work at x time, then you / senior management either have to accept there are busy times and times when other activities can fill the gap. Or employ more staff to ensure peaks are covered and have lots of gaps to fill with other work. Or pay overtime / time in lieu at busy times. Its a balance you and senior management have to strike and it will come down to cost.

 

The role I'm in at them moment means I chip in and do some basic tickets when it peaks a key times. Its about ensuring I'm aware of those peak times and I manage my project workload around it. Its teamwork.

 

Some nice trend graphs would help you and others see all this. If the trend is ever increasing it also becomes a nice tool to ask for more staff or alternatively a reduction in SLA.

 

 

Any data needs context and value. Think of what you want to gain from the data - understanding of workload, performance, issue areas, etc. Then how you are going to use the data - proactive support, why did x department have issues (training?), why so many printer issues?, can we pre-empt the common calls at the start of the term? - intro to IT booklet with FAQ, self service password reset.

 

Data should be the start of the conversation - a tool. Not the end, certainly not a stick to beat people with.

[Marc_EduTech]

That's very helpful @steve, thank you.

Some good thoughts to go away and ponder on there.

 

I would say at the moment the feeling overall is that this is mostly a stick beating exercise, rather than a conversation starter.

 

It's very interesting to see how other establishments operate when it comes to reporting, and I thank you all for responding so far.

@Marc_EduTech

[PotNoodleTech]

I take it based on the stats you can provide, you guys are not using post it notes to keep track of IT jobs then!

[TechMonkey]

I may be wrong, so ignore me, but it also sounds like you need to analyse a bit and check your SLA. Having a high volume of jobs shouldn't directly interfere with your SLA% unless your SLAs are very tight. I'm thinking about our start of term jobs and mostly they are forgotten passwords (which should be quick), user memory issues (which can be quick or slow depending on the amount of degradation) or issues arising from work we have carried out. Ok so there will be a lot of them, but start of year we aren't running any new projects, just mopping up ones that should be finished, so it is all hands to getting everyone up to speed. I can't see these affecting SLA% to a degree that they can't recover quickly. In your report from the high volume periods it should be explained why there is this volume and also be used as a point to get SLT to think about training, identify staff that may need a bit of a kick, or ways to start more efficiently.

 

Otherwise there is the option to massage the data. So the headline figures will be that months, with the year to date in smaller font and a smaller graph.

 

Hope that doesn't cause offence, not trying to pour scorn, but if something is consistently causing an issue then either the measurement needs to change or the resources.

[Marc_EduTech]

Hi @TechMonkey,

 

Thanks for your thoughts too, absolutely no offence taken!

 

At the moment we're operating on directives issued to the team, and so I'm just querying other establishments for some sort of comparison to see how we stack up really.

 

Any and ALL comments are welcome

 

Thanks

@Marc_EduTech