Service Management Journey: First Call Resolution Basics

After the last post, Request Fulfilment and the Stop Button, I received some feedback and more importantly questions around first call resolution. The theme was how to track it better.

Depending on the system that you use for tracking requests you may have a very easy way to calculate this. However from the people I connected with after the post they either did not have a simple way in their current system or, when they set up their current system they inadvertently made it more complicated to track.

But let’s take this discussion back a bit to see where this all comes from. We have all heard from the top that we want to improve on our first call resolution but why?

The statistical answer is that we are able to quantify the number of requests which were handled by the service desk, but what other impacts are there. I will give you my favorite three:

1. It’s cost effective. Let’s face it; it always comes back to the cost of service support. For example, if 55% of the requests we get in are resolved at the service desk level the other 45% are hitting 2 or more teams, which you guessed it comes at a price. More teams equals higher price tag, do we need to have all these teams looking at this? Further investigation to this may indicate that we have escalation issues which impact the cost if it goes to the wrong team by mistake.

2. Making customers happy. Think about your own experiences if you are able to call, email or chat and get a resolution right away you are going to be far more satisfied that if you have to send something in that may be reviewed for an unknown period of time.

3. Happy customers are loyal customers. If you are able to better satisfy your business, they are less likely to look for ways around you with shadow IT or other vendors.

Ok, so we know why we want to do it but how do we better manage the reporting if our system is less than cooperative. Since there are many nuances to everyone’s system the best way is to be a master of the data that comes in which constitutes the FCR numbers and those which do not. The trick is to decide what you want to know so you can engineer the request form to produce results. My motto – simple is best.

In the beginning you may just want to know the volume of FCR and how they were escalated. The easiest answer is that we have a checkbox or a flag of some sort to indicate that the request was handled in the initial call. The next challenge is to differentiate between phone calls, email and any other avenue where requests may be initiated. There may be a drop down for this with a few choices. Remember we want to keep it simple so that we can break up the FCR which were resolved on the phone vs the FCR which was handled by chat. Doing this will allow us to better tailor improvement strategies and automation down the road (that’s another post)

When we do something like this we need to ensure that the teams who will be completing the request forms understand why we need to ensure accuracy. They also need to understand that the goal is to ultimately help them improve their workload by understanding what comes in each day.

To ensure that we remain as accurate as possible there also needs to be a level of audit. This may be done by the service desk lead or manager but there should be some takeaways from the reviews that are done on the information. Sharing with the team what was done well and not so well in an anonymous way will allow your team to improve the information which is captured.

Overall the goal of this is to improve the satisfaction of customers so we should also accompany these stats with some customer follow up to ensure that not only did we resolve the request in the initial contact but that we did it in a satisfactory way.