Customer Support metric

Time to Resolution. What the customer actually came for — and the metric that breaks the moment a ticket becomes a bug.

Time to Resolution is how long from a customer raising an issue to it being genuinely solved. A fast first response opens the relationship, but this is the one that keeps it — customers want acknowledgment, but they want the problem fixed, efficiently. The honest target is same-day, or 24 hours measured by severity. But here's the hard part almost nobody talks about: a lot of support tickets aren't things support can fix. They're real bugs that get handed to engineering and sit. Support can't resolve what it can't repair, so the real discipline of resolution time is what you do when the fix lives with the product team — and most companies have no answer for that.

What it is

The time from a ticket opening to the problem being genuinely solved — not just the ticket closed. Measured by severity. A password reset and a production-down bug are different animals; blending them into one number tells you nothing useful about either.

Measurement period

By severity.

Same-day is ideal; 24 hours is a healthy target for normal issues. A true production-level problem affecting all customers is a different clock entirely — that's an immediate hotfix, not a 24-hour SLA.

Formula

Genuinely resolved − Ticket opened

Track median alongside mean — a few stuck bug tickets blow up the average. Resolved means solved, not closed-and-hoped.

When to review

Weekly.

Review resolution weekly — and review the support-generated bug count at the leadership level on the same cadence, because that's where slow resolution actually hides.

Why it matters

When the bug count got too high, we stopped the roadmap.

At PipelineCRM, same-day resolution was the ideal — and for most tickets, achievable. But the genuinely hard part of resolution time, the part that isn't talked about enough, is what happens when a ticket isn't something support can fix. A real bug gets handed to engineering and then it's out of support's hands entirely. Support can't resolve what it can't repair. And if you don't have a discipline for those tickets, your resolution time quietly rots while everyone points at someone else.

Here's the discipline we built, and I'd put it on any leadership team's wall: we tracked support-generated bugs at the leadership level, weekly. Not buried in an engineering backlog tool nobody opened — surfaced to leadership every week, so the tickets that turned into bugs got handled efficiently instead of disappearing. And when that bug count climbed too high, outside our goals, we did the thing most companies won't: we stopped product roadmap work and engineering projects to clear it. New features waited. Because a pile of unresolved customer bugs is a louder problem than a late feature, even if it doesn't feel that way in a planning meeting.

That's the real lever on resolution time for a SaaS company, and it's a leadership decision, not a support one. Support owns the front line; leadership owns whether engineering capacity flows to fixing what's broken or only to building what's new. Most orgs default to new — it's the trap that runs through the whole product side of this business — and customer bugs rot in a backlog while the resolution-time number gets blamed on the support team that never had the power to fix them. Tracking the bug count where leadership has to look at it, and being willing to halt the roadmap, is how you actually keep resolution honest.

When the support-generated bug count climbed too high, we stopped product roadmap work to clear it. A pile of unresolved customer bugs is a louder problem than a late feature — even if it never feels that way in the planning meeting.

Worked example

Three tickets, three clocks. Severity decides what "fast" means.

A single blended resolution-time number averages these three into mush. Split by severity and each one has its own honest target — and the third shows where resolution time actually goes to die.

Routine

Same day

IssueHow-to / config
OwnerSupport
TargetSame day
ReadSolvable on the front line

A question support can answer directly — settings, how-tos, account changes. Same-day resolution is the ideal and very achievable. The bulk of tickets live here, and a well-staffed desk clears them fast.

Production-down

Hotfix

IssueAffects all customers
OwnerEngineering, now
TargetImmediate
ReadDrop everything

A true production-level problem isn't on a 24-hour clock — it's an immediate hotfix, everything else stops. Rare, but the one severity tier where speed beats every other priority. Don't average this against routine tickets.

Bug, handed off

Rots

IssueReal bug, not urgent
OwnerEngineering backlog
Target…someday?
ReadWhere resolution time dies

Support can't fix it, so it goes to engineering — and sits, because the roadmap takes priority. This is the silent killer of resolution time. The fix is tracking the bug count at leadership and halting the roadmap when it climbs.

Benchmarks

The bands — by severity, not blended.

Resolution time only means something split by severity. A blended average buries the production-down emergency and the rotting bug in the same number as the same-day how-tos. These bands describe what healthy looks like for normal-severity tickets at a $1–10M SMB SaaS — with the explicit carve-out that production-level issues are a separate, immediate clock.

Ideal Same business day

The target to aim for on anything support can resolve directly. Same-day says the desk is staffed, empowered, and clearing issues on the front line. For the bulk of tickets — how-tos, config, account changes — this is both achievable and what customers remember.

Healthy Within 24 hours

A solid, defensible standard for normal-severity issues. Most things resolved inside a day keeps customers feeling taken care of and is realistic for a well-run SMB desk. The right default SLA before you layer severity tiers on top.

Watch Multi-day · bugs accruing

Resolutions stretching past a day, usually because more tickets are becoming engineering bugs that aren't getting fixed. The number itself is a symptom — the cause is the bug backlog. Surface the bug count to leadership before the median quietly drifts into days.

Backlog rot Bugs rotting / unmeasured

Customer bugs sitting in an engineering backlog while the roadmap takes priority — or resolution time not tracked by severity at all. This is where support gets blamed for a number only leadership can fix. Track the bug count where leadership sees it, and be willing to stop the roadmap to clear it.

When resolution is slipping

Three plays that actually move it.

Slow resolution is usually two different problems wearing one number: front-line tickets support could clear faster, and bug tickets stuck with engineering. The plays separate them — split by severity, fix the front line, and apply the leadership discipline to the bugs.

— 01 Split by severity before you do anything

A blended number hides both real problems.

You can't fix resolution time as one figure, because the same-day how-to and the month-old bug have nothing in common. Split tickets by severity first: routine issues support owns, production-down emergencies that need an immediate hotfix, and real bugs handed to engineering. Each has its own target and its own fix. The blended average is the enemy — it lets a pile of rotting bugs hide behind a wall of fast routine resolutions, so the number looks fine while specific customers suffer.

— 02 Track the bug count at the leadership level

Put it where leadership has to look at it, weekly.

The tickets that become bugs are where resolution time dies, and they die in silence inside an engineering backlog. The fix is to surface support-generated bugs to leadership every week — not in a tool nobody opens, but on the weekly review where decisions get made. We did exactly this, and it's what kept those tickets moving. What gets seen by leadership gets handled; what stays buried in a backlog rots. Make the bug count a leadership number, not a support one.

— 03 Be willing to stop the roadmap

When bugs climb past your threshold, new features wait.

This is the lever most companies won't pull, and it's the one that matters. Set a threshold for the support-generated bug count, and when it climbs past it, stop product roadmap and engineering project work to clear the backlog. We did this whenever the number got too high, outside our goals. It feels wrong in a planning meeting — you're delaying features for bug-fixing — but a pile of unresolved customer bugs costs more in churn than a feature costs in delay. Resolution time is ultimately a capacity-allocation decision, and it's leadership's to make.

Common mistakes operators make with Time to Resolution.

Letting bug tickets rot in the engineering backlog.

The biggest one, and the least discussed. A real bug leaves support's hands and goes to engineering, where it sits because the roadmap takes priority — and resolution time quietly rots while everyone blames everyone else. The fix is structural: track support-generated bugs at the leadership level, weekly, and be willing to stop roadmap work to clear them when the count climbs too high. Support can't resolve what it can't repair; only leadership can reallocate the capacity that actually fixes it.

Blending all severities into one number.

A single resolution-time average is nearly meaningless. A production-down emergency, a month-old bug, and a same-day password reset have completely different clocks, and averaging them hides all three. Measure by severity: routine issues against a same-day or 24-hour target, production issues against an immediate-hotfix standard. The blended number lets fast routine tickets paper over the bugs that are actually hurting customers.

Optimizing first response while resolution lags.

A fast "we're on it" buys goodwill, but the customer came to get their problem solved. It's entirely possible to hit a great first-response number while customers stew for days on the actual fix. Care about both — acknowledgment opens the relationship, resolution keeps it — and weight resolution higher, because it's the one that determines whether the customer's problem actually went away.

Tracking mean instead of median.

A handful of stuck bug tickets will blow up your average and make the whole desk look slow, or — depending which way you squint — a wall of instant routine closes will drag the mean down and hide the stuck ones. Track the median alongside the mean so you see the typical experience, not just the one distorted by outliers. The gap between the two is itself a signal: a big spread means a few tickets are stuck badly.

Treating resolution time as a support-only problem.

When resolution time slips on bug tickets, it's not a support failure — support did its job by escalating. It's a capacity-allocation decision that belongs to leadership: does engineering fix what's broken or only build what's new? Blaming the support team for a number they have no power to move is both unfair and useless. The real owners of resolution time, for anything that becomes a bug, sit in the leadership meeting.

Closing tickets that aren't actually resolved.

Marking a ticket resolved because the customer went quiet, or closing-and-reopening to reset the clock, games the number while leaving the problem alive. Resolved has to mean the customer's issue is genuinely solved, confirmed where you can. A closed ticket and a solved problem are not the same thing, and a resolution-time metric built on closures rather than actual fixes is just another vanity number.

Read alongside

Resolution time lives or dies on the bug backlog.

The tickets that become bugs are where resolution time goes to rot. The size and age of your engineering bug backlog is the upstream number — watch it at the leadership level, because a growing backlog is a resolution-time problem you haven't felt yet. (A dedicated Bug Backlog guide is coming soon.)

First Response Time guide →

How Upbeat helps

Resolution time and the bug count, on the same leadership scorecard.

Resolution time slips where leadership can't see it — in an engineering backlog of support-generated bugs nobody's tracking at the top. Upbeat puts resolution time by severity and the support-generated bug count on your weekly scorecard, side by side, so the moment bugs start accruing you can make the capacity-allocation call — clear the backlog or keep building — with the real tradeoff in front of you, not buried two tools away.

See how it works → See pricing

Related metrics

Resolution is the goal. These surround it.

A late feature is cheaper than a pile of unresolved bugs.

Upbeat puts resolution time by severity and the support-generated bug count on your weekly leadership scorecard — so when bugs start to accrue, you make the call to clear them or keep building with the real tradeoff in view, before slow resolution turns into churn.

Email Nick directly →