It's easy to understand why the FTF rate is the Service Desk metric that gets the most attention. When measured correctly, it is the figure that identifies when your end-users get a resolution at the time of asking for it. Therefore, it is closely related to user satisfaction.
Working to improve your FTF rate helps you stay focused on the user experience while helping identify issues with processes and performance. However, in order for this to be a productive exercise, the measurement of your FTF rate must be reliable, accurate and consistent with user feedback.
It also needs to be agreed upon and understood by all key stakeholders. This is easier said than done, given there isn't even an industry consensus on either its name, commonly referred to as First Call Resolution or First Contact Resolution, or its definition. This is evident by the wide range of FTF rates reported by IT functions from anything between 30% and 98% (according to the Service Desk Institute research).
Since we know that FTF can be confused with other metrics and even has multiple names depending on who you speak to, it might be easiest to first define what it is not first. FTF is neither First Line Fix (FLF) or Service Desk Resolution (SDR).Whilst all 3 metrics require each support ticket to be logged and resolved by the Service Desk, here’s how they are different;
- SDR doesn't require the ticket to have been handled only by 1st Line – indeed, the ticket may have done the rounds through multiple resolver groups before finally being resolved by 1st Line. It also doesn't require any prompt resolution of the ticket
- FLF is a measure of tickets which have only been handled by 1st Line, but, like SDR, not necessarily with any prompt resolution
- For us, FTF requires the ticket handling to be self-contained within 1st Line and needs to have been resolved in one single motion without break or delay.
FTF needs to be something that makes the most sense in your organisation and for your team. It might be quite a technical definition, very specific, or easy to understand. For example at Plan-Net we define it in the following way.
A ticket that is resolved in 'one single motion without break or delay' that typically will have to adhere to all of the following criteria:
- Be logged and resolved without the need to save, close and later re-open the ticket
- Be resolved by the analyst from his/her desk position
- Be resolved without seeking assistance from another colleague
- Be resolved quickly
While the ‘single motion’ might involve the analyst calling the user back, it should happen within a set time limit. We use 15 minutes as our FTF deadline to allow an analyst to fix and return a call to the user. The analyst should not work on anything else during that timeframe but should be focussing on the one resolution at hand.
Once the definition has been agreed, you need to consider the variables to be included in the analysis. For example in the above, what does ‘resolved’ actually mean? Is the user happy? Is the problem fixed? And what happens if it is the user that has the error?
It’s important to be very specific about this criteria. If your FTF rate does not align with user feedback, then you do need to take a closer look at how you define ‘fixed’.
If a user is calling, it’s easier to define ‘First Time’ as the problem being fixed during the phone call. But what happens if the contact is made by logging a ticket or email? Perhaps the Service Desk can resolve the issue as soon as they have looked into it, but what if it takes 2 days to get round to it with some time spent reading it, researching a fix and yet more time to resolve and contact the user? In other words, the total time an analyst spent on the ticket might only amount to 15 minutes but the end-user is still left dangling for two days. That is certainly not a recipe for customer satisfaction.
Timing and the criteria around timing need to be totally transparent. At Plan-Net, we only count phone call tickets in our FTF rate so as to ensure that the tracking makes sense to us and our clients. After all, the FTF rate is most important in relation to urgent incidents and queries and users are most likely to call rather than send a written ticket. It also makes a timing parameter more meaningful as the resolution cannot be so easily disrupted.
Finally, the metric formula needs to be agreed and understood by the stakeholders and managers interpreting the results.
You might decide that it should be a percentage of ‘tickets’, ‘calls’ or ‘incidents’ resolved in the first contact over the total number of incidents resolved or opened. Or, the total number of incidents resolved less the total number of incidents reopened over the total number of incidents. Whatever your formula for calculating FTF, it must make sense and remain consistent in order to make for meaningful reporting.
If you are provided with reports on First Time Fix, it’s important you understand how it is defined and measured in your organisation and to ensure it fits with your business goals. It’s also important to understand any factors that influence its results that are outside of the control of the Service Desk. For instance, there is no getting around some tickets that need a physical visit and therefore cannot be fixed ‘first time’, neither can a Service Desk be held responsible if the ticket is regarding a 3rd party fault. In order to make the FTF rate a fair and representative figure, there should be means by which such tickets can be identified and excluded from the FTF rate where possible.
If your FTF rate does not match up with anecdotal end-user satisfaction, then take a step back and look again at how you are defining it. Work to make the metric better reflect reality. Use it to guide your team set goals, but remember to take a step back to look at the bigger picture when reviewing reports. After all, no amount of ‘but look at this percentage’ will work under a tidal wave of negative end-user feedback.
Although all these five points seem like a lot to adhere to, most good service management tools can mark a resolved ticket as 'FTF' if logged and resolved without first being saved. This will provide a reasonable basis upon which to report a meaningful FTF that you can understand and make informed judgements and management decisions.