The KPIs that Matter in 2020 (Part One)
Aug 05, 2020 • Features • White Paper • Aquant • Leadership and Strategy
In this first article in a series of excerpts from a recent white paper published by Aquant, Edwin Pahk, VP Product Marketing and Business Development, Aquant explained why now more than ever what we measures matters. Now in the next feature in this series we look at the first two of five crucial KPIs that field service organisations must monitor
Would You Like to Know More? www.fieldservicenews.com subscribers can access the full white paper on the button below. If you are yet to subscribe join 30K of your field service management peers and subscribe now by clicking the button below...
Sponsored by:
Data usage note: By accessing this content you consent to the contact details submitted when you registered as a subscriber to fieldservicenews.com to be shared with the listed sponsor of this premium content, Aquant who may contact you for legitimate business reasons to discuss the content of this white paper.
KPI#1 FIRST TIME FIX RATE
What is it?
First time fix rate (FTF) is one of the most popular metrics for workforce measurement. It’s simply how often someone is able to fix the issue in question on the first try. This is typically referenced in both a contact center and field service scenario.
How it measures workforce performance
Generally, it’s assumed that the higher the first time fix rate, the more competent or skilled the technician is.
How it impacts customer experience
FTF makes a big impact on great customer experience. Customers want resolution quickly, and they don’t want to have to place a service ticket two days later because the issue was never properly resolved. Solving issues correctly the first time boosts a brand’s value and acts as a competitive differentiator, making it just as important as the quality of the initial product or service.
Challenges to measuring first time fix rates
- Service costs can increase: Service organizations often throw a lot of money at the problem to increase first time fix rates. The problem? First time fix rates alone do not represent the skill level of your workers. For example, a technician tends to swap costly parts for a new one every call instead of digging deeper into how to fix the root issue. Stats will show a high FTF, but doesn’t take into account that a cheaper option could likely have fixed the problem
- First time fix doesn’t reflect technician skill: Not all issues resolved on the second attempt reflect technician error. Often, failure to achieve FTF happens in tandem with an accurate diagnosis. If the dispatcher didn’t provide insight into the situation, a tech may arrive onsite, quickly diagnose, but need to come back later that day or days later with the right part. Understanding the context of what the metric represents is just as important as measuring first time fix rates.
- Properly defining and tracking first time fix is a challenge: This is especially problematic depending on how an organization tracks the KPI. If each new ticket is measured in a vacuum, a first time fix rate may be high. But what if tech thinks they fix the issue on the first visit, only to be called back a week later because of a different problem with the same machine? If the tech makes another quick fix, you record that as another FTF. Go team!
But wait a minute. What if a third ticket is issued a week later and a different tech arrives on-site to realize the first tech was simply putting a band-aid on a more complex root issue? A deeper analysis of these common miss measurements finds that service organizations really have more chronic repeat visit problem than they realize.
How to measure first time fix:
It’s not an exact science, but a much more accurate approach is to measure whether there was a visit for that same asset or issue that occurred within X number of days of the previous visit. While this isn’t a complete solution, it addresses the major fallacy of the first time fix rate.
KPI#2 MEAN TIME TO RESOLUTION:
What is it?
Mean time to resolution (MTTR) refers to the time it takes to resolve a customer issue. This is typically defined as the time between the case creation date and its closure date. Similar to the pain of staying on hold when trying to resolve a personal issue, minimizing MTTR is a key factor in increasing positive customer experiences and reducing costs. Organizations with high MTTR often have techs who find themselves in escalation black holes.
How it measures workforce performance
MTTR has an inverse relationship to first time fix rate. As your FTF rate goes up, MTTR should go down. How so? That’s usually related to service heroes resolving issues (really resolving the root cause) on the first visit, with the right parts and tools to make quick work of the problem.
How it Impacts Customer Experience
Consumers and B2B clients want immediate service. Amazon Prime, overnight shipping, Netflix, and more all represent the demand for immediacy. MTTR is a critical part of that customer service experience, and if your customers don’t receive the attention and quick resolution they want, they’ll seek out a competitor.
Challenges of measuring mean time to resolution
- Poor data collection or lack of uniform data: This is the biggest issue related to measuring MTTR. While case creation/creation date is a fairly consistent data point across organizations, case resolution time or date is much less reliable due to poor data collection. The biggest issue here is a lack of compliance among users -- technicians often forget to close out cases until days after the problem is resolved.
- Dependence on first time fix measurement: MTTR is highly dependent on how FTF is measured. Failed visits have a profound impact on MTTR, and the stats are grim. Issues not resolved the first time require, on average, another 14 days to resolution. The reason is often attributed to the need to order additional parts, scheduling issues with customers. MTTR suffers from the same challenge as FTF if the root causes of failure aren’t addressed.
- Mean time to resolution is a measure of process and people: It’s tough to separate the two. MTTR can be used to measure workforce productivity, but it’s also a measure of capacity and process. Sometimes when MTTR slumps, that’s the result of lack of enough headcount versus workforce performance.
How to measure mean time to resolution:
There are several approaches to mitigate some of the challenges faced when measuring MTTR.
- Measure the difference in mean time to resolution rather than overall rate. Instead of looking at MTTR as a single unit, focus on the aspects of MTTR that reflect workforce performance. For example:
- This can be identified in the difference in MTTR between individuals when a failed visit occurs. Service professionals who often require multiple customer visits will generally have greater MTTR rates versus your best experts who seldom make repeat visits.
- Use only open dates to measure mean time to resolution. Given the lack of quality in measuring accurate resolution dates, using open dates and visit dates to define the MTTR threshold is a way to identify MTTR. This eliminates the inconsistency in resolution or close dates, and will only work on customer issues with failed visits.
In the next feature in this series we will look at three more crucial KPIs, Mean Time between Failure, Cost Per Service Per Technician and Net Promoter scores. Alternatively, subscribed now for access to the white paper above and the rest of our premium content library @ www.fieldservicenews.com/subscribe
Further Reading:
- Read more about Leadership and Strategy @ www.fieldservicenews.com/blog/tag/leadership-and-strategy
- Read more about Managing the Mobile Workforce @ www.fieldservicenews.com/blog/tag/managing-the-mobile-workforce
- Read more news and articles featuring Aquant @ www.fieldservicenews.com/hs-search-results?term=aquant
- Connect with Edwin Pahk on LinkedIN @ https://www.linkedin.com/in/edwin-pahk-8a066515/
- Find out more about the solutions Aquant offer to help field service companies @ www.aquant.io/
- Follow Aquant on Twitter @ twitter.com/Aquant_io
Leave a Reply