Datto's #3 KPI Carries a Warning

First Call Resolution (FCR) seems simple enough. After all, why wouldn't any Managed Service Provider worth their salt want every Customer issue resolved on the first call? I mean, what more could you ask for when it comes to a stellar Customer Experience?

WOW, there is a lot to cover on this topic, so hang on as we expand on the upside and downside of monitoring First Call Resolution (FCR). Let's jump in with a quick review of Datto's summary:

For a First Call Resolution Live Report you can write for yourself, click here.

Datto's 3rd KPI: FCR sub-article takeaways: 

  • Solid SLA performance will help you build a strong brand and retain clients.

  • Datto recommends measuring your first call response (FCR) rates along with SLA performance.

  • FCR can also be a great indicator for Customer satisfaction, because the more calls or touches it takes to resolve an issue, the more frustrated the client becomes.

  • MSPs who are utilizing (utilizing) the FCR metric have a more granular view into how well they're hitting SLAs.

  • Segment out those cases that take longer and dig into why. This will help you identify roadblocks in your process that need to be remedied to eventually increase your FCR rate.

To get the eBook from Datto, download it here

FCR Comes With a Warning…

This a great KPI and has got me thinking: For months, even years, we have been promoting SLA performance and Mean Time To Resolve (MTTR) as key KPIs all MSPs should be tracking (not sure why these two did not make the top ten list, but, oh well). 

It is not that we are unaware (or never thought)of FCR; it's that FCR carries a warning. And, applying the metric is only applicable to a portion of the Customer Requests we deal with. 

The Warning: What is measured and monitored is what the Support Team will respond to. Please do not implement FCR without implementing a Reopen Rate monitoring as well. 

FYI: Tracking Reopen Rate is not as easy as it sounds. You need a Ticket User Defined Field (UDF), a Workflow Rule that flags which tickets have been reopened, and a Live Report that indicates who closed the ticket prematurely. Rest assured, if you start monitoring FCR, Techs will be closing tickets prematurely just to get the score, and then open up a new ticket if the Customer calls back.

You know better than I do which portion of Customer Requests makes sense to track FCR:

  • End-User Incidents (Break/Fix)? Probably yes.

  • Minor Service Requests, such as adding new Off 365 users? Probably yes.

  • Network device incidents? I'm not sure on that one.

  • Anything that takes over 4 hours (major Service Request, Installs, and Projects) to complete the engagement? Probably not as Real-Time Time Entry calls for a separate time entry before lunch and after lunch (and of course all tickets embrace Real-Time Time Entry, and taking lunch).

FYI: We are adding FCR to our arsenal of Service Manager reports used to benchmark, track, and improve the Support Team's performance(the full list is at the end of the article). Thanks to Datto's eBook, it makes perfect sense to me that one way to improve SLA is to track FCR just for the reasons Datto indicates.

Other Datto eBook statements that have my head spinning:

Datto: "SLAs, however, may only scratch the surface when it comes to truly measuring performance."

This is so true, and it's why we track MTTR. We find it very strange, disheartening, and hard to explain to a Customer why it takes days to complete a ticket that only took 1 hour and 45 minutes of Tech time. While adding FCR to the mix is great, the contractual obligation is SLA performance, so SLA is still the top KPI for Service Delivery performance. These other metrics, FCR and MTTR, help a service manager know where there's room for improvement within the Team.

Datto: "FCR is the percentage of tickets where the first call solved the problem."

Please do not let the word "Call" throw you. The metric "First Call Resolution" comes from the ITIL and Enterprise IT Support Centers, where the Help Desk Agent (not even a Tech) sits at a desk and reads a script on how to fix the problem (because Enterprise Support Centers see less than 100 different situations that need to be resolved). In their world, most requests come in via a phone call. This is not our world at all, so when the metric asks for "Call", think any "Customer Request."

Datto: "This measures the speed of resolution for your clients."

Really, I see the metric as 1's or 0's, not time to completion. Yes, you would think that FCR would also mean the Tech Engagement SLA (also known as Resolution Plan) was met, and that does enter in an expected time to engagement, but not completion. Here would be an interesting comparison: Tickets that met FCR, but did not meet Tech Engagement SLA, assuming Triage SLA (also known as First Response) was met. 

Tracking FCR compared to Resolve SLA (also known as Resolve), in my mind, will return very little value. There should be no contractual obligation to complete a ticket as promised; we just do not control enough factors to put this commitment in the contracts. Therefore, we put them so far out, that if the first time we engage is after the request should have been completed… well, we have bigger problems than tracking such a lightweight KPI.

Datto: "FCR can also be a great indicator for customer satisfaction, because the more calls or touches it takes to resolve an issue, the more frustrated the client becomes. Keeping a close eye on FCR helps MSPs meet client expectations and deliver great service in a timely manner. "

Now we are on to something -Customer Experience and Satisfaction. While we agree that having a high FCR is a big step towards providing a great Customer Experience, my guess is: Technical Quality, Friendliness, Honesty, and Trust are way more important in providing a great Customer Experience followed by "How quickly are you going to fix my stuff?" Based on this thought, FCR may be more of an internal MSP profit metric than one the Customers care about.

Datto: "This is because you are not only responding fast and hitting SLAs, but you are also delivering a quality of service to resolve issues on the first touch."

Wow, where did "quality" come from? Didn't we just get done saying FCR is a "gotcha" when it comes to "quality"? From our experience, monitoring, measuring, and reporting FCR is going to result in a high Reopen Rate, which means "quality" goes down by using this metric, not up. This is the reason we have shied away from using the metric, but we now see where it would be valuable to the Service Manager to spot areas of improvement. If you want "quality"… do not tell the Techs you are monitoring FCR!

Datto: "Once you start measuring your service quality standards on FCR, you could improve up to 30%." Datto's Source Talkdesk"How to Measure First Call ResolutionIn Your Contact Center", 2018.

FYI: the article is written about actual 'Call Centers," which we are not. I once hired a Service Coordinator with extensive Call Center experience. He (happened to be a male) was lost. He had no script to go by, he did not know how to research a problem or request, and he did not know how to review and assign or dispatch onsite or remote. 

Call Center work is not what we do. We fix problems, Call Centers provide info. That's a big difference. Now, I will tell you that the Employee did actually turn out to be a great Customer Service Representative. The things we needed him to do are the things he wanted to do, but the Call Center environment did not afford him the opportunity. He loved the job and was very good at it.

With that said, I have no doubt monitoring and measuring any metric will help improve the metric. I'm just not sure 30% will work in our environment, and I am not sure we want a 30% improvement. Shoot, we could get 100% just by opening a new ticket every time the Customer called in asking for an update.

Datto: "To accurately track FCR, build a Live Report in Autotask PSA, pull every ticket for the last month, and count the number of time entries. After that, you can filter the time entries that are less than 2 to calculate percentage of service tickets that were resolved on the first touch point."

Except, you do not need to do the filter for Time Entries in Excel, you can easily group the report on tickets with # of Time Entries = 1, and more than 1.

Before we move on, let's look at the Single Time-Entry metric for an MSP. There are many times, in the interest of providing outstanding Service to the Customer, we want the Tech to check back before closing the ticket and walking away. 

For Example:

Take Backups, you fix them when the alert comes in (or wait for 2-3 alerts in a row so you know it will not self or script-heal) and then, after the next backup is scheduled to run, you check back in on it. Or maybe a reboot is needed, and you log back in later in the evening to make sure the script kicked off the reboot and everything came back on its own. And of course, when fixing something, check back in a day or so to make sure everything is running right before closing the ticket. 

Notice in all these cases, the 2nd engagement is less than 30 minutes. So, in the FCR Live Report, we are only going to count the ticket as meeting FCR if the 2nd Time Entry is less than 30 minutes. 

Please Note: FCR does not mean it is best to remove the Triage step and send the calls/emails directly to the Techs.  If this is what you are thinking when implementing FCR reporting, then it is another warning/gotcha.  As a matter of fact, if you want to improve the Customer experience, shorten the time to engagement. More importantly, shorten the time to completion, or improve quality; then the Triage step is the right way to go.  The reason the Triage step does not preclude FCR is that normally, a Service Coordinator is a non-billable person, and the way FCR is tracked for an MSP is by number of time entries.  There is no time entry for Triage, therefore, no dink in the report for Triaging a ticket first.

Datto: "MSPs who are utilizing the FCR metric have a more granular view into how well they're hitting SLAs. You'll be able to see not just the cases that are resolved on the first attempt but segment out those cases that take longer and dig into why. This will help you identify blockers in your process that need to be remedied and eventually increase your FCR rate."

I agree wholeheartedly. As a matter of fact, that is why we have been saying throughout the article and over the last few years, to Improve the Quality of Work-Life, CSat, and Boost Profits, you need to focus on the Support Team's SLA performance and MTTR. 

We now add to the Service Managers' tool belt, the FCR report - all in an attempt to slice the data and cut through the noise to direct where the Service Manager should put their energy and focus.

To get the eBook from Datto, download it here

Service Managers, Take Notice

As a Service Manager, here are the KPIs that are important to benchmark, monitor, track, and use coaching moments to improve the Service Delivery operations:

  • Resource Utilization (RU)

  • Service Level Agreement Performance (SLA)

  • Mean Time To Resolve (MTTR)

  • Reactive Hours per Endpoint per Month (RHEM)

  • Service Delivery Forecast (SDF)

  • Project Availability Forecast (PAF)

  • First Call Resolution (FCR)

  • And Now, Escalations (ESC)

  • Labor Profitability

For a First Call Resolution Live Report you can write for yourself, click here.