Customer support metrics matter. They’re something you should be paying attention to. There is a wealth of information just waiting for you to explore and glean information from.
A lot of attention is paid to response times and handle times. We go to a lot of effort to run complicated NPS surveys or send out CSAT surveys after support interactions. This is all valuable. But… what kind of data can you find in your other metrics? If you have great data just sitting there waiting to be explored, don’t you want to be exploring it?
What about average number of replies? It’s one of the best metrics to get a handle on the amount of effort your customers are going through to get help from your team.
It can tell you if particular team members might need a bit of extra training. Or if certain parts of your software are confusing and are causing a lot of back-and-forth communication. It’s not a silver bullet, but when used in concert with other metrics it’s going to help expand your view into what your customers are experiencing.
It might be something you’re already collecting, but it’s waiting for you to go and take a look at.
What’s the big deal with average number of replies?
Your average number of replies says a lot about the amount of effort your customers are going to in order to get their questions answered.
It tracks how many replies both your customers and your team make before a case is resolved. This could be because of multiple follow-up questions, clarifications, or general confusion. Or it could be because of unrelated follow-up questions. Sometimes you’ll need to dive into the actual case to figure out which is which.
These numbers matter because they tell you how many times your customers need to interact with you to get their problems fixed. Was it just one email and a solution was found? Or did they need to email back repeatedly saying, “No, that wasn’t what I meant!”
What you’re looking for are larger numbers than you’d expect. Two to four interactions are likely understandable, but you’re going to know the numbers that matter, and the numbers that would be unusual. What you’re looking for is what you deem an excessive number of replies.
What you’re looking for is what you deem an excessive number of replies.
What’s the best way to track average number of replies?
Average number of replies is one of those metrics that you need to look at both in aggregate and a bit more in detail. Unfortunately, it can’t be just a number on a report.
This is because it can be skewed by a large percentage of cases that are closed on the first reply or frequently re-opened cases when a customer emails in with unrelated questions and reopens a ticket. Start by removing any outliers.
What I do is:
- Get a 30-day snapshot of all tickets in a spreadsheet and sort by number of replies.
- Remove all first contact resolutions (you should be tracking the number of cases solved on the first reply separately and that’s another important metric to keep an eye on, for other reasons).
- Individually look at any huge outliers on the other end. You’ll need to decide for yourself what’s an outlier. It might be ten replies is far out of the norm, or twenty.
- Skim over those tickets and see why they may have had such a large number of replies.
- Sometimes it’s a case of a customer asking lots of unrelated questions and those I’ll pull from the spreadsheet. If all replies are related to the same issue I’ll leave them in, but I might add extra labels about troubleshooting or bugs for later identification if they weren’t already there.
From there I’ll figure out my average number of replies for the team as a whole and per team member.
Generally, the team number is going to look good. If your team as a whole was struggling you’d likely already know it. However, if you think the number could use improvement, it might be time for a team-wide conversation about good troubleshooting, or ways to followup and anticipate what the customer needs before they ask.
The best support sometimes gives the illusion of being psychic. If you think your team could use some practice anticipating then the average number of replies is a good metric to concentrate on reducing.
Most of the time, though, what you’re looking for are individual outliers:
- Is any one individual number off from the team average?
- Or, if you track case labels is there one particular label that drives a higher number of replies?
Those are the numbers you’re looking for and from there you want to dive into individual examples and figure out what might be going on.
How can you find out what might be causing problems?
If you see specific examples of averages that are unusually high, here are the questions you need to be asking yourself.
- Is this a newer team member?
- Could this be a case of them needing more training in specific areas? Perhaps they need someone to pair with them on better troubleshooting. Take a look at what types of tickets are getting the most replies and see if there is a theme.
- Is it someone on your team who takes the tougher cases?
Some cases are just going to require more back-and-forth due to complexity.
If you have a sacrificing team member who is repeatedly jumping on grenades for everyone. You want to make sure they aren’t burning themselves out and are getting the appropriate care they need.
Make sure they have the time they need for those intense cases as well. Have a chat with them and make sure there aren’t underlying reasons that they’re taking those complex cases rather than other team members.
What kinds of labels are applied to those cases?
Are the higher number of replies related to bugs or major troubleshooting? Perhaps it’s explainable by that.
Is a specific part of your software causing problems?
Again labels or tags might help here. If you label cases by area do you see a particular area coming up a lot in those larger number of reply cases? This is something you’ll want to make note of and perhaps bring up to your product team. If one particular area causes a lot of back-and-forth, that’s a clue that it might need some extra attention.
What do you do with that information?
If you’ve spotted some potential problem areas, it’s time to start working on them. If a member of your team is struggling go talk to them. What are they struggling with? Will more training help? Do they need to slow down and think things through more? You’ll know what to do now that you know what’s going on!
If it’s a part of the software that might be more confusing, do what you can with the product team long term,and in the short term take a look at your documentation.
Bandaids aren’t always the best, but sometimes you might be able to clarify a bit of confusion in your self-service areas now that you know some areas cause a lot more back-and-forth communication. If you know it’s a problem, it’s time to look for solutions.
How do you know it’s helping?
This is going to depend on what you want to track and what you identified as a problem. Overall the best metric to track is going to be the one you started with. See if it starts to go down or if other problems crop up.
If you decided that your team as a whole could use a little improvement then this is where metrics like NPS or CSAT come. Try tracking them together with your average number of replies.
As you move the bar on one, are you moving the bar on the other?
Did trying to take your overall team average number of replies down help improve customer satisfaction?
No metric is the killer metric that will give you all the data you need. It’s always going to be a journey to figure out what’s the most meaningful data for you to track. But don’t ignore your number of replies. It’s going to give you a good look into areas where your team or your software might need some improving. It’ll give you a look into where you might need better escalation policies. And it’ll tell you if your customers are having to work too much to get great support. Don’t make your customers work too much, that’s a recipe for disaster.
Go out there and improve their experience. You’ll be glad you did.