Customer support resolution time is how long it takes to solve a customer's problem, measured from their first message. Most teams don't measure that. They measure how long until the conversation was closed, and the gap between those two numbers is where repeat contacts come from.
A team can cut its resolution time in half by closing sooner. Nothing in the number says whether the customer's problem went away.
Coming soon: Supportman will show whether a closed conversation's problem came back, next to the median time to close and CSAT it already posts to Slack. Get notified at launch.
What are the different resolution times?
Four clocks get called resolution time. Pick one on purpose and write it down.
| Clock | Starts | Stops | What it tells you |
|---|---|---|---|
| First response time | Customer's first message | First human or bot reply | How fast someone showed up |
| Time to close | Customer's first message | The conversation's last close | How fast the queue moves. This is the one Intercom reports |
| Time to resolution | Customer's first message | The problem is actually solved | What the customer experienced. Rarely measured |
| Time to stay resolved | The close | The end of your window with no return on that issue | Whether the close held |
Time to close is easy to pull. Time to resolution is the one you care about, and the two are equal only when nothing comes back. The fourth clock is really a yes/no check, which is why it's the one that catches the difference.
One detail worth knowing: Intercom measures time to close up to the conversation's last close, so a customer who replies to the old thread pushes that number out. A customer who starts a new conversation about the same problem doesn't. The first conversation stays fast and the second starts its clock from zero. See reopened support tickets for why that gap matters.
How do you calculate resolution time?
Median resolution time = the middle value of (closed at − first customer message at) across the conversations closed in the period.
Use the median, not the mean. One 50-hour escalation drags an average around and tells you nothing about a normal Tuesday.
A hypothetical week, seven conversations, in hours:
| Conversation | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Time to close | 0.5 | 1 | 1 | 2 | 3 | 6 | 50 |
- Mean: 63.5 ÷ 7 = 9.1 hours
- Median: the fourth value = 2 hours
Report the median, then report the tail next to it: how many closes took longer than, say, 24 hours. The median tells you about the queue. The tail tells you which customers had a bad week.
How can a fast close hide an unsolved problem?
Three ways, all common, none visible in the number.
The answer went out and the conversation got closed. The agent replied with the fix, the customer went quiet, the thread was closed. Whether the fix worked is unknown. It's counted as resolved.
The customer gave up on the thread. People who are still stuck rarely go hunting for the old conversation. They open a new one.
A bot closed it on silence. Fin can count a conversation as resolved when the customer simply stops replying. That's an assumed resolution, and it produces a very fast close. See Fin resolution states for how to separate those from confirmed ones.
What does a faster team look like next to a slower one?
Two hypothetical teams, same 200 problems each. The numbers are made up to show the arithmetic. They aren't benchmarks.
| Team A | Team B | |
|---|---|---|
| Median time to close | 2 hours | 5 hours |
| Customers back on the same issue within 7 days | 36 (18%) | 12 (6%) |
| Closes that held | 164 | 188 |
| Conversations handled to finish 200 problems* | 236 | 212 |
*Assumes each returning customer needs exactly one more conversation.
On the speed dashboard, Team A wins by three hours. It also handles 24 more conversations than Team B to solve the same 200 problems. If you reward the first number, you're paying for the second.
Neither number is the answer on its own. The pair is. A fast median with a high came-back rate means closes are premature. A slow median with a low came-back rate means the team is thorough and probably short on capacity. Only one of those is fixed by hiring.
How do you review resolution time each week?
- Set the window. How many days count as "came back"? 3 days suits a chat question. 7 to 14 suits anything involving engineering or a refund. Write it down and don't move it when a number looks bad. The method is in repeat contact rate.
- Segment before you compare. Split by intent or tag, channel, team, and Fin versus human. A blended median across a password reset and a billing dispute isn't a number anyone can act on.
- Read the median and the tail together. Median for the queue, share over your threshold for the unlucky.
- Read the ten fastest and the ten slowest. The slow ones show process problems. The fast ones show early closes. Most teams only look at the slow ones.
- Add the came-back column. For each closed conversation in the sample, check whether the same customer contacted you again about the same issue inside the window. Manual for now. It takes about an hour on a 50-conversation sample.
- Set targets as a pair. "Median time to close under X and came-back rate under Y", where X and Y come from your own last eight weeks, not someone else's benchmark.
What should you do when the number moves?
| What you see | Likely cause | Check first |
|---|---|---|
| Median drops, came-back rate rises | Closing before the fix is confirmed | Read the ten fastest closes. Do they end with a question or a confirmation? |
| Median rises on one intent only | Docs gap or a product bug | Tag volume on that intent, and the macro or help article behind it |
| Median rises after a launch | Volume spike, new question types | Compare against the same intent before launch, not the whole queue |
| Median drops on Fin threads | Assumed resolutions | Split confirmed from assumed, then check who came back |
| Tail grows, median flat | A handful of stuck escalations | List every close over your threshold and who owns each |
Where does this fit with CSAT?
Customers rate the close. By the time they can rate it, the fix hasn't been tested yet. A high rating on a fast close is a good sign about the conversation and no evidence about the outcome. Keep observed and predicted CSAT labelled separately when you put them next to resolution time, and read why average CSAT misleads before you build a target on it.
What can you see in Intercom and in Supportman today?
Intercom's reports give you time to close, and every Intercom metric explained covers where to find it. The came-back column is manual for now.
Supportman's Friday report puts median time to close and median first reply next to a 7-day CSAT summary in Slack, and each rating posts as it lands. Its AI evaluation scores how a closed conversation was handled, including whether the issue was resolved within that conversation. It doesn't yet follow the customer into their next one. That's the gap this page is about, and it's coming soon. The weekly support report template and the resolution time tracking page show where the shipped numbers sit.
Frequently asked questions
What is a good customer support resolution time?
There isn't a portable target. It depends on product complexity, channel, and issue type. Set yours from your own last eight weeks, per intent, and pair it with a came-back rate so a lower number can't be reached by closing early.
What's the difference between resolution time and response time?
Response time is how long until someone replies. Resolution time is how long until the problem is solved. A team can respond in two minutes and take three days to fix anything.
Should I use average or median resolution time?
Median. A few very long conversations pull the average up and hide what a typical customer experiences. Report the share of closes over a threshold next to it.
Does time waiting on the customer count?
Decide in writing. Whether snoozed or waiting time counts changes the number a lot, and tools handle it differently. Check how yours treats it before comparing across tools or teams.
How do I reduce resolution time without more repeat contacts?
Never track it alone. Set a target for time to close and a target for the came-back rate together, and review the fastest closes as often as the slowest. Related: first contact resolution.