A support metrics review usually runs on five questions, and every one of them is easier to ask than to answer honestly. Why did it drop? How do we get handle time down? What’s our FCR target? How do we get more survey responses? Can we commit to that? They sound like diagnosis. They let the room skip the decision it was called to make.
I’ve sat through a lot of these meetings in nearly two decades, and the pattern holds whatever the size of the company. The numbers are real and the people are sharp. The questions are the problem, because each one points the conversation at the number instead of at the operation underneath it.
Why did the score drop this week?
CSAT comes in at 82% against 86% the week before, and someone has to explain it. The room finds three escalations that went badly, a coaching session gets promised, and next week the score is 85%. Everyone assumes the coaching worked. I used to think a good manager had an answer for every dip. Now I think a good manager knows which dips don’t have one.
Most of the time 82% and 86% are both normal for the process. That’s common cause variation, the noise a stable operation produces on its own, and chasing it makes things worse. Intervening in a stable process because of a point inside its natural range is called tampering, and it adds variation instead of removing it. I found this out the uncomfortable way: when I finally built a proper control chart for our average handle time, the control limits sat nearly four minutes apart. We weren’t nearly as consistent as I’d believed, and no weekly explanation had ever shown me that.
The better question is whether this is a signal or noise. A point outside the control limits, or eight in a row on one side of the centre line, deserves a real investigation. A point inside them deserves a note and a moving on. I walked through how to build and read the chart in my piece on control charts for support data, and you can do it in Excel in under an hour. The review gets shorter. It also gets more honest.
Before I used control charts, a weekly review was mostly a search for explanations. Some were legitimate. Some were retrofitted to fit the data point, and commitments got made against what was often just noise. Once the question became signal or noise, the reactive churn in my teams dropped noticeably. People stopped inventing reasons, and the real ones got more attention because there were fewer decoys.
How do we get handle time down?
Because it’s the most measured number in the building, someone asks it every week. I once saw a management advisory firm tell a US contact centre to hold average handle time to 480 seconds, taken from a benchmark study. The calls in that business routinely ran longer than that, because of what customers were calling about. Under a strict adherence policy, agents got negative reviews for doing the job correctly.
That’s what happens when a planning input gets promoted to a performance target. Handle time tells you how many agents you need, and it’s a key input to the Erlang C maths. It doesn’t tell you whether the call worked. Put it on an agent’s dashboard and you get wrapped-up calls that aren’t resolved, thin notes, and customers rushed through scripts.
Ask what’s making these calls long, and whether the length is the problem. A long call from a complex account with an upset customer might be the best call you took all day. A long call because the knowledge base is wrong is a process failure with a number attached. If AHT is currently an individual target, try removing it for one team for 90 days while you keep tracking FCR and CSAT. Expect AHT to rise a little at first. Then watch repeat contacts fall.
There’s a second reason to stop reading the number as a verdict. As automation absorbs the routine queries, the contacts that reach your agents skew toward the complicated, the compliance-sensitive and the emotionally charged. Harder work takes longer. A rising handle time can mean your deflection is working, and if you penalise the team for it you’re punishing the one thing that’s going right.
What should our FCR target be?
I don’t think a target is the right place to start, and I’ve watched teams hit a number without fixing anything. A ticket gets closed because the agent ran out of time, the customer stopped replying, or the issue went to another team. None of that is resolution. If you measure FCR from ticket status, you’re almost certainly overstating it.
The only defensible definition is the customer’s: did they have to contact you again about the same thing? Everything else is a proxy, and proxies lie. The HBR study of 75,000 customers found 56% of them had to re-explain their issue, which is exactly the cost a closed-but-not-resolved ticket hides. Agents can’t fix what they aren’t allowed to fix, so a manager-approval policy on a simple exception caps your FCR before anyone picks up the phone.
So the question that earns its place in the review is what’s stopping us resolving this the first time. The answer is almost always upstream: routing, authority, tooling, a knowledge base that describes the product as it was designed rather than as it behaves. That’s why I call FCR a leadership metric, not an agent metric. Agents don’t own the policies. Leadership does.
Pick one honest way to measure it and stay with it. Repeat contacts about the same issue within a defined window in your CRM works, so does a post-contact question that asks directly whether the issue was resolved, and so do QA reviews that score the outcome rather than the compliance. Be explicit about the edge cases: channel switching, several issues in one contact, follow-ups that are genuinely new problems. If people are still arguing about the definition, the metric isn’t ready to be a target.
How do we get more survey responses?
Response rates fall, someone proposes a shorter survey, and the next step is usually to bundle NPS and CSAT into one question set to reduce friction. It looks efficient. In practice you blur two different questions and end up with numbers that look familiar and explain very little.
The drop-off is rarely a wording problem. Customers get asked the same NPS or CSAT questions after support interactions, milestones and renewals, and the most engaged voices answer again and again while the quieter majority leaves. They stop responding because they don’t see evidence that responding changes anything. That’s a trust problem, and no survey redesign fixes it. I’ve built Voice of the Customer programs at three companies, and the ones that held up were built around a single purpose: reducing uncertainty at the point of decision.
The replacement question is which decision this feedback will change, and who owns it. If nobody can name the decision, more responses won’t help. In that case, I’d rather see a narrow program, or none at all, than a broad one that teaches everyone to ignore it politely.
There’s a worse outcome than fading away, and I’ve seen it. The data stays, but it gets used selectively: a customer quote or a survey segment pulled out to justify a decision that was already politically favoured. Teams spot that quickly. Engineering stops engaging, support managers get defensive, and frontline staff start treating the program as something done to them. At that point you can keep sending surveys, but the program has already lost its value.
Can we commit to that?
This one comes from the boardroom, not the review. An executive agrees to answer email within 30 minutes, or to an 80/20 target where 80% of calls are picked up within 20 seconds, because it sounds right in a negotiation. Nobody asks at what staffing level, in what hours, against what volume. The commitment gets made in a boardroom and the consequences arrive in a queue. What happens to that 30 minutes when two agents are out sick, a release spikes volume, and it’s a Monday morning in peak season? If you can’t answer that, you haven’t made a promise yet. You’ve made a guess with a signature on it.
Run the numbers and the commitment gets very concrete. At 96 calls an hour and a three-minute handle time, you’re carrying 4.8 Erlangs of work. The Erlang C result for an 80/20 target is that seven agents reach 78%, just short, and it takes eight to clear it. One agent either side of that is the difference between keeping the promise and writing an apology.
The harder part is the chain behind the promise. A customer’s four-hour commitment is only as good as the internal teams under it, and when the critical issue lands at 6pm on a Friday and the engineer starts at 9am on Monday, that’s 63 hours against a four-hour promise. I took that apart in the internal and external SLA chain. The question to ask before signing is what has to be true for us to keep this, and who has said yes to each of those things.
Next review, pick whichever of these five your team asks most often and swap in its replacement for one meeting. It will feel slower for about ten minutes. After that you’ll notice how much of the old version was the meeting protecting itself.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
