Top Goals and Metrics for Customer Service
20 Feb 2024 · 20 min
Dave Kellogg breaks down customer support through three pillars: resolving cases, deflecting them, and preventing them from happening. Cases-per-agent matters, but only if post-case CSAT hits 4.5 or higher. An environment-checker tool eliminated 20% of support calls by catching configuration errors upfront.
Chapters
Live from snowy Schenectady, New York, it's SAS Talk with the Metrics Brothers, Growth and CAC.
And I'm Growth, better known as Ray Reich, founder and CEO of Benchmarkit.
And I'm CAC, better known as Dave Kellogg, independent consultant, EIR at Balderson Capital, and author of Kellogg.
And together we are the Metrix Brothers.
And we go together like SpongeBob and Patrick.
Wait, wait, we have a SpongeBob reference on a SaaS book?
I was gonna do Dory and Nemo, but I wasn't sure you'd get it, Ray.
Well, I know we said we weren't going to use food metaphors anymore because, you know, it makes me hungry, but when I think of SpongeBob, I think of Krabby Patties.
Oh, maybe you're food obsessed, Ray. We may have identified the real problem here. So, in any case, let's be drink obsessed. What's on tap for this week, Ray?
Well, it's not a sponsorship with Kelly O'Byrnes and Schenectady, but since we were discussing CCO metrics, and then last episode we dove into professional services, let's talk about customer support and the metrics that matter in that function.
Okay, I think it's a great topic and part of our little miniseries here on the CCO, it looks like. I actually have some background in this area, Rais. I think we talked about it in the first episode, but my first job out of college was in technical support. So I've actually done the job on the phone, did it for a couple of years, in fact. And then about 25 years after that, I ran the Service Cloud at Salesforce, which is their, let's say, family of customer service applications. So it's an area I know something about and really have always been interested in.
Well, good.
So I'm going to lean upon you because even though I have ran a lot of the other go-to-market functions, customer support, I always had someone who knew it a hell of a lot better than I did, and I stayed out of their way. But before we dive in, let's hear a word from our presenting sponsor.
The Metrics Brothers is proudly sponsored by Benchmarkit, the B2B AI and software industry's largest, broadest, and most contextualized benchmarking index. Dave Kellogg and Ray Groth Wright have put the Metrics Brothers podcast on hiatus for remainder of 2026. All episodes we have ever recorded are still available on your favorite podcasting app. You can reach Dave at Kellogg and Ray on LinkedIn at Ray Reich. Thank you so much for listening to the Metrics Brothers podcast.
Okay, Dave. So, off we go with customer support metrics. So, first of all, I think we should start like we did professional services, kind of at a high level. What's the strategic vision of a customer support organization? What do they do?
Yeah, so, and we'll tend to use the terms customer support and customer service interchangeably here. I tend to say support more, although a lot of people call it customer service. So, I would say that the job is really 3 things. It's to resolve cases, I.e., somebody calls and says they have a problem. I forgot my password, I gotta get that resolved. And then people realized that just efficiently resolving cases wasn't enough, that wouldn't it be nice if we had fewer of them? Because as it turns out, they're expensive to resolve, and it would be nice if we could have fewer of them. So this whole concept of deflection came into case, which is, you know, the best case is the case that never was. So why not send you— and certainly this changed radically when the internet took off 20 years ago, right? Because it became a lot easier to deflect cases. cases, say, hey, go to our self-service portal, type in a search box, get a knowledge base article, and did this help resolve your issue? Yes, no. And boom, a case has been deflected. Now, today, obviously, chatbots are huge for deflection. We'll come back to that in a minute. But the whole idea is, our first job is to resolve the cases that get through. Our second job is to deflect cases to say, hey, can we prevent this case from happening? Do I have to put an agent on the phone talking to somebody? And by the way, even just chat-based customer service, It's not really a deflection, but it's an intermediate ground between the two. And then finally, the most strategic take on this is prevent cases. Very hard to measure. We'll come back to how to measure it. But, you know, the best case, it turns out, isn't the one that we deflected in the self-service portal. It's the one that never happened because the product was better, or the training was better, or something was fundamentally better, so we never had the case in the first place.
Well, I'm gonna take the customer's perspective for the next 15 or so minutes here, because this whole deflection of cases, which means means put the work back on me in a self-service environment I'm not a big fan of. But let's go into the resolved cases. What I love as a customer and you love as a customer support leader, what are the metrics that we really want to hold us to on resolving cases?
Yeah, I'm going to take the bait on deflection, Ray, because I'm very passionate about customer service as well. And I literally just had to try and change my cable TV this morning. So if you think I'm wound up about customer service today, I really am. I got deflected a lot. And like, they basically— my cable TV provider only lets you upgrade online. Their chatbot only does add-ons. And when you go to product configuration, it only does expansion. There is no way online to drop. In this case, I was trying to drop TV and just go back to internet. You can't drop anything online. You can't even see the pricing of the other packages. So that was rough. So then I went to the self-service portal. It couldn't help me. Then I went into the phone system and it tried to deflect me.
Right.
And, and it was just very— so by the time I got through to an agent, I was actively angry, right?
Hey Dave, let me ask, because we're going to get into the resolution measurements in just a minute, but if we're deflecting so many of the inbounds via chatbots, etc., when does the case actually get open? Because I know we're going to talk about cases per agent as a critical measurement. That's not even a case yet, is it?
Yeah, look, I believe a, a A case being done by an agent via chat is a case. So if you're actually talking to a human via chat, if the chatbot can deflect it, right? Chatbots today typically try to handle your case inline, and then if they can't, they'll connect you to an agent. That's what a good chatbot does. It escalates to you. It becomes a case at the moment there's an agent on the other side of it. Now, the nice thing about chat-based support is I might be running 5 cases in parallel, right? So in theory, I can get a lot of productivity out of it. But in any case, let's just agree that deflection is a polarizing issue because When it's done correctly, it can be cheaper and faster. It's actually a true win-win, right? Just imagine you go to that portal, it works, you resolve your issue. I dropped TV in 3 clicks. There was no phone call. I actually like my provider and I'm okay. So I'm still a believer that deflection can deliver the holy grail, which is, you know, more efficiency and happier customers. But often it turns into a Kafkaesque nightmare. And that is bad. At some level, I wanna add a new CSAT question, Ray. I was thinking about this this morning, which is— Are you emotional about your vendor, right? Like, I'm emotional about TDS. I don't like them. I'm angry, right? And it actually takes something to do that. Like, I'm not emotional about my bank. I'm not emotional about a lot of things. My cable provider, I'm emotional.
You know, it's funny, I'm a Type A person and I only yell 2 times in my life. One is when I'm in New York traffic and someone's driving not very well, and I was like, get out of my way, right? The other time was on a Verizon call deflection the other day where you have the, you know, voice tree, and I'm like, agent, agent! And then I screamed at the top of my lungs. My wife ran in, it's like, are you okay?
Yes, such is customer support. So let's dive into this. So we preempted ourselves on deflection, so we'll speed up that section of the, uh, of the episode. But on resolution, so the cases that get through when we're actually dealing with an agent, in my mind The metric, there's one metric, which is cases per agent, and you want it continually improving. So if we did whatever, N cases per agent last quarter, I wanna do N plus 5% or N plus 3% this quarter, and just always getting better. And that one is subject to a constraint, which is I can always drive more cases per agent if I let CSAT plummet, right? I can just, you know, resolve the case. Hey, Ray, no, hang up. And I've resolved the case, I get credit for it. But when you do the post-case CSAT on that call, you're gonna give me a bad rating. So, so I often quip that the job of the head of customer support is to continually increase cases per agent subject to a post-case CSAT of 4.5+. And if you can do that, you're doing a good job.
Now, a high correlation to cases per agent is mean time to resolution or resolution time. So do you think that's another pretty good metric?
I do. I want to go back on one more thing on cases per agent since we've talked about deflection. The better you get at deflection and the better you get at self-service resolution, The harder the cases get. So I just want to put a little asterisk on the cases per agent metric, because if you're actually really good at deflecting cases and resolving cases before they happen, the only ones that get through are going to be the hard ones. So you may not be able to drive productivity up as much. But, but yes, resolution time. Let's talk about resolution time because you asked. The only thing I'd say on this metric is if there was ever a metric not to look at the mean, it's this one.
Okay.
Which is, I don't actually care if my average resolution is 1 or 2 days, right? The people who hate you for life are the ones where the resolution time was 20 days or 30 days, right? So you wanna put some sort of tail metric on this and say, I mean, you can track the mean, but you really need to have some maximum acceptable amount in your mind. I don't know how long it is, and some of this is gonna depend on how we handle cases with bugs, because all of a sudden, they're gonna go from days to weeks, maybe months, right? But let's just say they're standard cases, there are no bugs, usually you want them resolved in a couple of days, tops. And we want, like, 90%, because we kind of assume that anybody who's not resolved is not gonna like us. So typically, 95% within a few days would be a good resolution time metric, in my opinion.
Now, we also discuss separate reporting for case types, like bugs versus non-bugs. The other thing I've traditionally used in enterprise class, whether it's enterprise software or SaaS, was SEV 1, SEV 2, SEV 3. Which we had to, of course, well-defined. So let's go to the, it's a bug versus it's a how-to or administrative issue. Are those kind of the 2 primary segmentations you see?
Yeah, I mean, you can set different goals for the type. There's usually 2 dimensions on a case, right? One is, there's basically a how severe do we think it is and how severe do they think it is? And it's good to track both. And in general, people prioritize by how severe they think it is. But there will be cases where it's like, this is a modest bug, it causes a brief performance hit, it's not a huge issue for us, But for them, for whatever reason, they're telling us it's critically important. And in the end, if you wanna get high ratings and high scores and have customers love you, you respond based on a kind of severity. I can't remember the buzzword, but kind of severity versus importance, and you look at both. And you should segment your reporting that way. The thing we only touched on briefly, Ray, was just cases involving bugs. I wanna come back to that for one minute, which is just, you need to figure out— Look, one thing I don't like, is when an agent goes, can I close your case now, Ray? Because I want it closed. And it's like, well, I'm not resolved. I reported a bug and you said you're going to fix it next quarter. And, you know, I guess you can close the case if it makes you feel better, but my issue is not resolved. So personally, I like a status where that's not closed, it's still open, and then it closes when I am— when, you know, I call you up and say, Ray, you know, are you happy? And you go, yes. That's a little bit idealistic on my part. Most people like to close them out, but I like when there's another status there. The other one you didn't ask about yet is just first call resolution. I know this is one you like. Look, it's an important metric. A lot of people track it. How often have I kind of resolved the case on the first call, right? Because as soon as you're going to multiple calls, then things get hard. It takes much longer, costs you much more to deliver it. The argument I have against this metric going forward is in this world of knowledge bases and chatbots and AI, I mean, hopefully any possible first call resolution case is deflected or resolved online.
Yeah.
So I think it's not a kind of go-forward big metric because hopefully it'll be, it'll be trending towards zero kind of perversely.
Well, let's move on to deflecting cases. And I know we said we're going to keep that shorter, but I actually was on a call just yesterday and an AI agent who sounded very calm, a very soothing voice, but it was very obvious after 2 or 3 sentences it was an AI agent trying to get me to Tell them exactly what was wrong so they can send me to the right online asset. But again, this isn't about me, it's about customer support metrics. How do you measure deflecting cases and whether it's adding or hurting your performance?
Yeah, I think this is actually a super interesting conversation, Ray, because we're both getting emotional about support, as we do, as humans do. And this is the thing we have to measure. Ultimately, we wanna be looking at CSAT as a high-level metric and customer service CSAT. Do you just say, hey, you're a customer, especially in the SaaS world where you're an ongoing relationship, what do you think of our service? How do you like it or not? How do you feel about us as a vendor, which is largely gonna be impacted by service, to find out net-net, how are we doing? Is that chatbot doing a great job at deflecting cases, or is it doing a great job at making customers hate us? And we need to concede the possibility that both are there and that people do get emotional about this stuff. So I think, Look, when we talk about deflection rate, yes, it's emotional. Second, there are 2 types, explicit and implicit, where I know I resolved your case, right? You said, I forgot how to log in. We say, go click here and click forgot password. You do that. We ask if we resolved your issue. You say yes. That to me is a win-win opportunity. I didn't need to go to a call center. I didn't need to go to an ACD. With a couple of clicks, you got me an answer. I didn't have to take a call. You got your answer quickly. So, so I am a believer that this stuff can work for positive. It can also, to your point, work for negative, right? That the goal— this is my joke on the— so I always tell marketing people, saying no is a key skill for a CMO. Just don't get too good at it, right? It's the same thing with case deflection. Case deflection is key for running an efficient call center. Just don't get too good at it, right? Because reductio ad absurdum, you deflect every case, no one gets through at all. No one's ever calling. It's like, that's probably not a good place to be, right? So we wanna get some people through. So we also look at implicit metrics for case deflection. Explicit ones are either off the chatbot, did we resolve your issue? Or we see you in the knowledge base, you read an article on the bottom, did this help you, yes or no? You click no. Okay, well, we didn't resolve that one. But if you click yes, maybe we did. So the implicit are more just look at the page views of the self-service content. If a lot of people are hitting an article, We could assume, especially if they're all saying, yes, it resolved my issue, yes, it was helpful, you start to be able to say, yeah, this is helping us reduce cases per agent. So just remember, the goal at the high level is, you know, be good at deflection, but not too good, and always look more broadly at CSAT and customer service CSAT.
Yeah, you know, another one that people should use for me? How many times did Ray go to Reddit after he left our site to find out how to solve the problem?
That's a good one. That is actually a good metric. You could see it directly too, in theory. Your weblog will show you leaving and show the URL you went to, I believe. Yeah, that's a funny one. So look, it's a controversial issue, but deflection is part of life in call centers. Look, we haven't talked too much about it. I have several friends running companies in AI customer service, and obviously chatbots are huge, people like Drift, for example. And then my friends are in internal customer service, where it's more IT help desk, HR help desk. Companies like Moveworks and companies like PeopleRain would be examples of people who are doing basically internal case deflection. This is not external customer service, but somebody calls HR about benefits, somebody calls IT about their laptop, people are building dedicated chatbots to handle those.
Well, let's go, we got about 4 minutes left here. Let's go to the holy grail of customer support metrics, to me, is that How many cases can you prevent? I would have never even thought of that without this discussion, Dave. So can you dive into that a little bit?
Yeah, so, so quickly, the most strategic thing I ever did in my 2 years in tech support was I wrote an environment checker with my friend Ed, and it either resolved calls entirely because we just put in the instructions, after you unload the tape and do the install, run the environment checker and it's going to tell you what's wrong. So it either prevented calls entirely or Or at bare minimum, people would call us and we'd say, hey, did you run the environment checker? They'd say, no. We'd say, run it. And literally, that, I don't know, 20% of our calls were related to environment variables at the time, right? It was a huge source of customer dissatisfaction and calls. And the reason I bring this example up is just to say, if you wanna know the number one thing I ever did in customer support, it wasn't the day I resolved 30 calls, which I think was my record. It was the day that Ed and I wrote this thing because it resolved thousands of calls. So the idea is the single best case is the case that never happens. You can You can get there either through deflection in a portal, or you can get there by basically making the product better. In this case, we added a utility to the product that made the product better, that eliminated the case. You can go one more level, and this is why I began my journey towards product management from tech support, was, hey, I could actually just fix the product so this particular problem doesn't happen. Like, I'll remove the ambiguity in the command or the user interface so people don't get confused, or change the semantics of a function to make it clear. So, Basically, the most strategic thing tech support could do to prevent calls is make the product better. And it's very hard to measure. Most support people are deeply motivated by it because they wanna make the product better. They want these cases not to happen. So you could build utilities, you can work with PM to build utilities, you can work with PM to enhance the core product. The only way I know to measure this is just cases per customer over time. And you're just watching how much inbound does our product generate It's relatively hard. I mean, you could probably do more detailed tracking, but I like that metric anyway. I like to know how many cases per customer do we get over time. And ultimately, if I can reduce that, that's a really good thing.
Well, I think there should be 2 other members of the executive team or of the leadership team that should share that. The head of product R&D, man, it would be a great thing for them to say, hey, my job is to have less, you know, call-ins and bugs, and even professional services, if they're doing the deployment, they should be measured on this as well. What do you think?
So, definitely on product, right? Product, to me, I view as a hub-and-spoke model, and they're the hub, and there are a lot of spokes coming in, and one of them is customer support. And part of their job is to work with customer support to make the product better. So, I agree radically there. On PS, less so. Because often PS takes their own support calls. If it's really on the implementation, they'll call the PS person. So I'd be less enthusiastic about it. I get where you're coming from. But for product, absolutely, reducing the support burden is a strategic thing for the product. Ultimately, gross margin, right? You wanna talk about metrics? Where's that gonna show up? It's gonna improve gross margins because subscription gross margins are better than— well, these are in subscription gross margins, so it's gonna reduce subscription COGS.
Yeah.
Here we are at the end of the episode. We started it with kind of what's the primary responsibilities of customer support? And you said resolve cases, deflect cases, and prevent cases. And I'm just going to reframe that. Resolve cases, deflect cases without pissing off your customer, and then prevent cases.
Never get emotional about a stock, Ray. Remember that Gordon Gekko? Never get emotional about support, Ray.
Okay.
People always do.
I won't. Only when I'm the customer.
Okay, everyone.
Dave, thank you. And thank you for people listening to our Not only the insights, but of course our funny humor today.
All right.
Thanks, guys. See ya.
The Metrics Brothers: AI, SaaS, and More is a production of the Metrics Brothers Growth and CAC and a member of the Benchmarket Podcast Network. By accessing this podcast, you acknowledge that the Metrics Brothers make no warranty, guarantee, or representation as to the accuracy or sufficiency of the information provided or the humor content of the jokes told. Ray? Information, opinions, and recommendations presented are, according to our spouses, probably wrong, and provided for information purposes only. This podcast should not be considered professional or, for that matter, unprofessional advice. We disclaim any and all liability for any direct, indirect, indirect, misdirect, incidental, special, ordinary, consequential, inconsequential, or other damages arising out of any use of, or God help you, reliance upon the information presented here. Ray Grothreich is based in New York City and available on X @RayReich. Dave Kellogg is based in Silicon Valley and available on X @DaveKellogg. Kellogg. Schedectity, which is French for unspellable, is not our actual production location. Thanks for listening.
Bye-bye.
