Service Desk KPI's/metrics

[MelN]

I have been asked by my company to produce KPI's/metrics so that we can guage our performance on the service desk.

I am interest in those out there who already have these established, what metrics have you introduced to measure your service desk and it's people.

So please throw your two cents.

Thank you Meln

[rjp]

I would recommend that you approach implementing KPI measurement for
the Service Desk, and your Incident Management process separately.
This is because

* While the Service Desk might have primary responsibility for Incident
Management, others factors (and people) in the ICT organisation will
participate in this process.

* The primary objective of the Incident Management process is to
minimise the impact of incident of the business, and as such Incident
Management metrics should aim to capture that, and be drected primarily
towards making visible a key part of the overall Service Quality
preformance of the organistation.

* The primary objective of the Service Desk is Customer Satisfaction,
which is a different thing to Service Quality, and needs to be assessed
differently - with careful reference to factors that are not 'numeric'.
For example, no matter what you do, and no matter how 'effeciently'
your Service Desk staff are turning over their cases, if they do not
have high levels of 'job satisfaction' you will undermine the objective
of high customer satisfaction. In fact in many cases driving efficiency
up directly drives staisfaction down. And if you are going to do this,
I suggest it be a deliberate choice.

Another important factor in establishing good metrics is distinguishing
between those that report on the process itself, and how well it is
functioning, and those that report on the outputs of that process. In
the case of Incident Management this would mean you would be clear
about which metrics are used to monitor the Incident Management
Process, and which are being used to monitor and report on the real
contribution Incident Management is making to Service Quality.
(Primarily through lowering the impact of the Incidents that are
occuring.)

So For Incident Management process itself:

* percentage increase in the Incidents resolved by first line
operatives

* percentage increase in the Incidents resolved by first line
operatives on first response

* percentage reduction of Incidents that required reassignment in the
incident life cycle

* percentage reduction of Incidents that required reclassification in
the incident lifecycle

* reduced mean elapsed time for resolution or circumvention of
Incidents, broken down by impact code

* increased percentage of Incidents resolved within agreed (in SLAs)
response times by impact code. (You said you don't have SAL - but this
is an important one and of value to others reading this thread.)

For Incident Management objectives, the contribution it is making to
Serrvice Quality:

* reduction in the service unavailability caused by Incidents
(note this is a metric 'shared' by a number of processes)

* reduction of the Incident backlog

* percentage increase in the Incidents fixed before Users notice

* percentage reduction in the Incidents reopened

* percentage reduction in the overall average time to resolve Incidents

* percentage increase in number of incidents resolved by application of
recorded workarounds.

* reduction of delays in the production of management reports

* percentage reduction number of times first line operatives bypassed

* percentage reduction in average cost of handling incidents

Serivce Desk metrics (should be CSS metrics for Service Desk
operations):

* percentage improvement in CSS responses on the transaction follow-up
surveys.

* percentage reduction in length of queue time waiting for Service Desk
response

* percentage reduction in the number of lost Service Desk calls

* percentage reduction of the number of revised business instructions
issued.

Note that the metrics I have suggested here are priramily 'out of the
book', and are very much focused on measuring margins and changes. This is because the goal of measurement is to see why what is occurring over time is ocurring. Flat 'target' metric indicate a score-card approach
which is likely to create (over time) poor working conditions, and can
easily lead to the thinking that improvement means simply raising or
lowering the 'numbers'. By identifying trends you are actually
measuring the effectiveness of your own initiatives as a manager (or as
a team overall). You get to see what works and what doesn't. You can
also identify spikes, where events occuring elsewhere are a factor - eg
the growth and decline curves for incidents resulting from poorly
implemented changes. Flat measurements may retrun the errroneous result that your staff are performing poorly in one week, when the fact of the
matter was they were doing better, but facing the downstream effects
of other people's sloppy work.

Care needs to be taken that when measuring changes form baseline to
baseline, values in those changes are not then used as targets; eg,
setting a target that there will be a monthly reduction of 5% in the
number of high impact incidents resolved in under 2 hours. Anyone with
grade shcool arithmetic should see that this is doomed to failure

[xitil]

Thanks for the excellent contribution RJP. Only one question: What does CSS go for?
_________________
Better have remorse than regrets

[itilimp]

Hmm... customer support specialist?

[rjp]

xitil - Customer Satisfaction Surveys

[itilimp]

Doh! It's all about context isn't it? I confess when I first see CSS I think Cascasding Style Sheets

[lukes]

RJP has an excellent post about KPI's in fact I will be using some of them soon enough.

I believe that if you are setting your desk up now and its not a very large team or you do not have that many incidents then you should concentrate on areas where improvements is needed, like problem areas or areas that impact business.

This will ensure that your department is aware of where they need to work on the the KPI's that you have defined will target those problem areas, once you have achieved consistent performance then you can look at other problem areas as per their priority.

Let me know your views on this approach.

[peppermint]

lukes,

from your post, I assume that you would go for some kind of a 'phased approach', where you're describing stages of setting up a Service Desk. (If you're just starting up I would strongly recommend compiling a Service Catalogue, so you'll know that what services do you provide a Service Desk for.)
In these stages you can describe that what KPIs you're going to use, and obviously they can differ, but progressing through the stages you can include the previous KPIs so that you know that you're still good in sg you were good once, or you can measure the improvement.
You can also start to use a Continual Improvement Plan for your Incident Mgmt process and lessons learnt and improvement ideas in each phase can be added to the CIP. (One tick for ISO20k.)

Hope this helped,

pep

[rzesie]

Hi,

I'm new here so hello to everybody.
I was wondering if you have ever encounter an approach which defines the most important KPI's and sub-KPI's metrics which influence the main KPI.
The idea is to define metrics on which KPI is dependent so that you can take a look at sub-metrics when the main KPI is not fullfilled.
I think the example might call abandonment rate as the main KPI and then service desk capacity (staffing at the hour at which the abandonment occurred), PABX failures or peak times of call ratio as the sub-metrics that influence the main one.

I was presented with such an idea on a meeting lately and I was wondering if any of you have ever seen such appoach.

Thanks!

Regards,
Jacek

[Diarmid]

[edit] Please ignore this post. It was a brilliant witticism, but the evil-doer's post has been deleted and it now lacks context. I would just delete it, but it is the only recorded witticism of such power to emerge from my keyboard - even if I don't understand it myself. [/edit]

Is this advertizing?

... or just a grandchild?
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[viv121]

KPI library is another one. It should say double u double u before the kpilibrary. I have a KPI of Cost per Incident. How do I keep this reduction % trend in this KPI. What happens after the cost becomes 0 USD per incident?
_________________
regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

[Diarmid]

dinoalan911 seems to have sneaked in a url in his last edit.

naughty naughty.

He has also edited out the context for my joke and I cannot understand what I meant by it.

wicked wicked.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[ITILadmin]

Link spam deleted.....

[StanleyLuces]

rjp gave some very good metrics there.. but i feel it left out one of the most important metrics for SD.. Customer Satisfaction (CSAT)

with "The primary objective of the Service Desk is Customer Satisfaction" then its just logical that the main metric for that is CSAT.

with "The primary objective of the Incident Management process is to
minimise the impact of incident of the business" or simply put "to restore normal operations as soon as possible".. then a good metric for that would be something like average time to resolve/close case.

[TomOzITIL_2]

For what it is worth, good measures:

• Can be influenced
• Are an objective measure
• Measurements are repeatable
• Produce visible results;
• Are accepted
• Are motivating
• Are focused towards an objective
• Support good decision-making

Other advice:
• Read up on Kaplan & Norton Balanced Scorecard.
• Read up on Net Promoter Score (NPS) - a simple but hard-hitting measure.
• Have a look in the ITIL V2 and V3 books - plenty of examples there.
• Start simple - you learn more from trends than hundreds of measures.
• Google S.M.A.R.T. measures.
• Read the CSI book for some insight on how to select the right measures.
• Ask your customer (buyer).
• Ask a representative group of end users.
• Don't over promise.