Help desk KPIs come down to two clocks: how fast you respond and how fast you resolve. They are different numbers, owned by different teams, and mixing them up is the quickest way to build a dashboard that looks healthy while customers wait. Tier 1 and Tier 2 each get their own pair, and the targets should never match.
I wrote the original of this in 2008, as part of a post on what a help desk is. The measurement half deserved its own page, and I’ve spent the years since watching the same mistakes repeat. If you haven’t read the basics of how a help desk and its tiers work, start there. This piece assumes you know the difference between an incident and a problem.
Why does each tier need different help desk KPIs?
Tier 1 applies band-aids. Its job is to fix it, fix it fast and move on. Tier 2 does the surgery, and surgery takes longer because you don’t want the surgeon rushing. Put both teams on the same speed target and one of them will either fail it every week or game it.
I thought for years that a single average handle time target was a clean way to run a support floor. It isn’t. It rewards the agent who closes the easy ticket and punishes the one who stays on the line to fix the real problem. A metric has to match the work the team does, or it measures something else.
So build the set per tier. Four numbers cover most of what you need: Tier 1 response time, Tier 1 resolve time, Tier 2 response time and Tier 2 resolve time. Anything beyond those should earn its place by answering a question someone is actually asking.
What is a good response time target?
Be aggressive at Tier 1. I like the 80/20 rule: 80% of incidents responded to in 20 seconds. That’s a phone number, and it assumes you have the people. If you don’t, try 20 minutes. Run an email queue and 20 hours still sits inside a day, which can be perfectly fine. Twenty days is a number nobody should write down.
The point isn’t the 20. The point is that you pick a specific goal for how quickly customers hear from you, and you pick it by channel. Phone, chat and email deserve three different targets. A single blended response time hides the fact that your email queue is fine and your phones aren’t.
Watch the percentage as much as the time. “20 seconds on average” tells you nothing about the customer who waited four minutes. “80% in 20 seconds” tells you how many people got a good experience and, by subtraction, how many didn’t. The industry body HDI publishes plenty of benchmarking for support centres if you want an outside reference point before you set yours.
How is resolve time different from response time?
I separate them on purpose. Response time is how long until a human engages. Resolve time, sometimes called MTTR for mean time to repair, is how long until the customer’s problem is actually gone. A fast response with a slow resolution is a polite way of keeping someone waiting.
You’d love every issue resolved on first contact. It won’t happen, and chasing 100% will push agents to close tickets early. What you can do is set a resolve target that treats the band-aid as the goal and make it easy to hit. That depends on your knowledge base. If the system puts the common fixes in front of the agent, first-contact resolution climbs. If it doesn’t, your Tier 1 team becomes a customer of Tier 2, and the numbers start to bend.
Notice what that implies. A weak resolve time at Tier 1 is rarely a Tier 1 problem. It’s usually a documentation problem, and it shows up in your KPIs long before anyone complains about it in a meeting. Show me a help desk whose resolve time keeps slipping and I’ll show you a knowledge base nobody has updated since the last product release.
What should you measure for Tier 2 and problem management?
These are your more senior staff. You’d love them available around the clock, and unless you run a very large organisation they won’t be. So set response times around their real availability, not the availability you wish they had. A Tier 2 response target of 30 minutes in business hours and a callback window overnight is honest. A 24/7 promise you can’t staff is a number you’ll miss on the first long weekend.
Resolution is longer too, because the issues that reach Tier 2 are the ones that weren’t easy. Pick intervals that meet your customers’ commitments, and tie them to your SLAs. I’ve laid out how to do that in a worked tiered SLA example, and the distinction between the two disciplines is covered in incident management versus problem management.
There’s one more measure here that doesn’t fit a stopwatch. Count how many repeat incidents a closed problem still generates. If Tier 2 closes a problem and the same incident keeps arriving, the fix didn’t hold. That’s the number that tells you whether surgery actually happened.
Reporting cadence matters as much as the targets. Review Tier 1 numbers daily, because a bad morning on the phones is fixable by lunchtime. Review Tier 2 numbers weekly, because one big problem can distort a single day and tell you nothing. I’ve seen managers run both on the same weekly slide and wonder why Tier 1 always seemed to be in trouble a week after it happened. Match the review rhythm to how fast the team can actually change the result.
One last habit: write the target next to the number, every time. “Response time 87%” means nothing. “Response time 87% against an 80% target” tells the room whether to worry. It takes five seconds and it stops half the arguments.
What is the update-time rule?
Tier 2’s most important obligation isn’t speed. It’s communication, and I’ll say it three times because teams forget: communication, communication, communication. Your customer-facing agents need to know what the issue is, what’s being done and when it should be fixed. When nobody can give an estimated resolution time, Tier 2 must give Tier 1 an estimated update time.
You can measure this directly. Track how many open escalations have a stated next-update time, and how many of those updates actually landed on time. It’s a simple pair of counts and it rarely gets reported. It’s also the one that predicts how many angry callbacks you’ll take on Friday afternoon.
Measure the handoff, and the rest of the dashboard gets easier to read.
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.
