KoltrixFirst response time vs resolution time: which to optimize
First response time is easy to game and resolution time is what customers feel. How to define both, measure them honestly, and know when speed really matters.
On this page(8 sections)
A customer doesn't care that you replied in four minutes if the reply said "Thanks, we're looking into it" and the problem took nine days to fix. Yet first response time is the number most support dashboards put front and center, mostly because it's the easiest one to move.
Both metrics matter. They just answer different questions, and optimizing the wrong one can make your support look better on paper while customers feel worse.
The two definitions
First response time (FRT) is the time from a customer's message arriving to the first human reply. It measures how quickly someone engages.
Resolution time is the time from the customer's first message to the point the issue is actually solved: the question answered, the bug fixed, the refund processed. It measures how long the customer lives with the problem.
There are variants worth knowing:
- Next response time: the wait between each customer message and your reply, after the first. Long gaps mid-conversation frustrate people as much as a slow start.
- Time to close: when the ticket was marked done. This is related to resolution time but not identical; teams close tickets that aren't resolved, and leave resolved tickets open.
Write down which definitions you use, especially what counts as a reply and what counts as resolved. Without that, the numbers drift as people interpret them differently.
How first response time gets gamed
FRT is easy to improve without improving anything. The common ways it happens, usually without bad intent:
- Empty acknowledgments. "Thanks for reaching out! We'll get back to you soon." Sent fast, counts as a response, tells the customer nothing new.
- Auto-replies counted as responses. Some setups count the automated acknowledgment as the first response. That makes FRT effectively zero and meaningless.
- Cherry-picking easy tickets. Answering the quick questions first keeps the average low while hard problems sit.
- Replying with a question you didn't need to ask. "Can you tell me which browser you're using?" when it doesn't matter for the issue starts the clock and resets the customer's patience.
The fix is definitional: only count a reply as a first response if it moves the conversation forward. A practical test is that the reply either answers, asks for specific information you actually need, or gives a concrete next step with a time.
How resolution time gets gamed
Resolution time has its own failure modes:
- Closing tickets prematurely. "I'll close this for now; reply if it's still an issue." The clock stops, the problem doesn't.
- Splitting tickets. A follow-up question becomes a new ticket with a fresh clock.
- Excluding "waiting on customer" time inconsistently. Pausing the clock while you wait for the customer is reasonable, but only if everyone applies it the same way.
Tracking reopen rate (how often a closed conversation gets a new customer reply about the same issue) is a good counterweight. If resolution time drops but reopens rise, you're closing too early.
Why resolution matters more to customers
From the customer's side, the problem exists until it's fixed. A fast, empty first reply might reduce anxiety for a moment, but it doesn't change their situation. Ask anyone about a support experience they remember, good or bad, and they'll usually describe how long it took to get sorted and whether they had to chase.
That said, resolution time is partly outside the support team's control. A bug fix depends on engineering. A refund depends on finance processes. So treat resolution time as a company metric, shared by everyone involved in fixing problems, and FRT as a support-team metric that reflects engagement.
When fast first response genuinely helps
Speed of first response isn't vanity in every case. It matters most when:
- The customer is blocked. Can't log in, payment failed, data missing. A fast, real reply ("We see the issue, here's a workaround, next update by 3pm") changes their day.
- The answer is quick. For how-to questions, the first response often is the resolution. Fast FRT and fast resolution are the same thing here.
- The customer is deciding whether to buy. A prospect asking a pre-sales question may be comparing options right now.
- There's an incident. Early, honest acknowledgment reduces the flood of follow-ups.
For a feature request or general feedback, a reply in one day versus one hour makes little difference. Don't spend urgency on it.
Measure medians and the slow tail
Averages hide what customers experience. One ticket that waits a week can drag the average up, and many instant auto-replies can drag it down.
Report at least two numbers for each metric:
| Metric | What to report | Why |
|---|---|---|
| First response time | Median and 90th percentile | Typical experience and the slow tail |
| Resolution time | Median and 90th percentile, by tier | Urgent and low-priority work have very different shapes |
| Reopen rate | Share of resolved conversations reopened | Catches premature closing |
| Oldest open conversation | Age in hours or days | Shows what's falling through the cracks |
The 90th percentile is often more actionable than the median. If most replies are quick but one in ten waits two days, find out what those have in common: a topic nobody owns, a time of day nobody covers, a dependency on another team.
A balanced approach
For most small teams, a sensible setup looks like this:
- Set an FRT target per tier, with a strict definition of what counts as a response.
- Track resolution time per tier and review it as a team, including people outside support who affect it.
- Watch reopen rate so neither metric is improved by closing early.
- Review the slowest cases weekly, not just the averages.
- Pair numbers with reading. Pick a few resolved conversations each week and read them end to end. The numbers tell you where to look; the threads tell you what happened.
Bottom line
- First response time measures engagement; resolution time measures how long the customer has the problem.
- Only count replies that move the conversation forward, and never count auto-acknowledgments.
- Resolution time matters more to customers, but it's a shared metric that depends on more than support.
- Fast first response is most valuable when customers are blocked or deciding to buy.
- Report medians and the slow tail, and use reopen rate to keep everyone honest.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
