Is first contact resolution (FCR) a good KPI for the service desk and incident management? Many corporate IT organizations think that it is – after all, it’s definitely one that’s prominent in the ITIL books and is popular with many IT service management (ITSM) consultants. But is it right for every IT organization?
On one level, is it a just a measure of closed calls or of the percentage of end-user issues that were given proper care and attention? On another, what’s included in FCR stats? Just easy incidents, including password resets? FCR can be fiddled with, and I’ve even seen service desks that add room bookings into their FCR calculations. Are trickier issues disallowed for “fairness”? And I bet some would include wrong numbers if it made the FCR stats look better. FCR, along with other ITSM KPIs, can definitely drive the wrong behaviors.
However, the real issue for me is that IT organizations need to understand what they are trying to achieve before they can define their KPIs – so picking up an industry best-practice KPI and making important decisions based on it might not be in the best interest of the company using it. I’ll come back to this. First and foremost, IT organizations also need to understand what KPIs are, and their use.
The easiest place to start is to look at the KPI acronym and what it stands for, or at least what it should stand for:
Wow, us IT people really love our 3LAs (that’s three letter acronyms)!
CSFs are the things organizations or teams must achieve to help meet their goals and objectives. These may not be directly measurable, but it should be very clear how they contribute to success. Some examples of CSFs for ITSM processes include that:
And although IT organizations might not be able to directly measure these CSFs, they can discuss them with their customers and other stakeholders, and agree that this is what you are trying to achieve via ITSM.
Once CSFs have been agreed it’s time to define KPIs that indicate how well the organization is performing against these CSFs. There should only be a small number of KPIs for each CSF, otherwise the numbers become unmanageable.
Looking at the “Downtime of the service does not have a serious impact on the customer’s business process” CSF, example KPIs could be:
And remember, achieving these KPIs will not definitively prove that the CSF has been met, but it will help to indicate it.
Organizations should agree with the customer that this is what will be measured, and then report the KPIs to indicate how good the performance has been. But, in customer reviews, there is a need to discuss the CSF, not the KPIs – with the customer discussion something like “Here is the KPI data, do you agree that downtime of the service has not had a serious impact on your business processes?” This way, organizations can focus on what’s important rather than on what’s being measured. Read that last sentence again – it’s a very important point with KPIs and CSFs.
The ITIL books include many example KPIs, but in each section that lists KPIs it says:
“These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances.”
Let’s return to the example of FCR and think about whether this is a good KPI or not. Suppose that an organization just measures FCR, as the right thing to do, and then reports it to show how the service desk is increasing the number of customer incidents and requests it closes during the initial phone call. This has to be good, right?
But then suppose that the organization introduces a new self-service capability, to allow people to manage many of their own incidents and requests without the need for a phone call to the service desk. They might also automate password resets, and provide knowledge articles to help people resolve common issues for themselves. This should lead to faster resolutions and happier customers but, as more of the simple incidents and requests move away from the service desk, the agents will have a higher proportion of difficult incidents to deal with. Thus FCR will get worse and might even become irrelevant. Hence FCR might be a good KPI for some organizations, but it might be completely inappropriate for others. And, more specifically, using FCR to benchmark either over time or externally will be inappropriate as the average incident or request level changes over time.
So when an organization is defining KPIs it really does need to think about: its level of maturity; its customers; and its goals, objectives, and CSFs. It’s important that they choose a small number of KPIs that will help to indicate how well they’re doing versus the CSFs. They will also need to regularly review their KPIs to ensure they are still appropriate.
When did you last review the KPIs you use to manage your IT services? Maybe it’s time to think about them again. For further insights, I recommend you watch my good friend Rob England's webinar The Right Metrics for Your Service Desk.