First Response Time vs. Resolution Time

We recommend defining first response time as how long a customer waits for the first useful reply. A vendor report may count the first public agent reply instead, so check the event your tool uses. Resolution time measures how long the customer waits for the issue to be solved. You need both metrics because they describe different parts of the support experience.

A fast first reply tells the customer that the request reached your team. A short resolution time shows that the team moved the issue to an outcome. One does not prove the other.

First response time definition

For one ticket under this recommended operating definition, first response time is:

Time of first useful team reply - time the ticket was created

Define “useful team reply” before you report the metric. A receipt message such as “We got your request” may confirm delivery, but it does not show that a person reviewed the issue. Many teams exclude automatic acknowledgments for that reason.

For a group of tickets, an average is:

Sum of first response times ÷ number of tickets with a first response

Also review the median and the oldest waits. One very old ticket can raise an average. A median can hide a smaller group of customers who waited much longer.

Resolution time definition

For one ticket, resolution time is:

Time the issue was resolved - time the ticket was created

Your team must define the end state. Some workflows use “resolved” when the team believes the issue is fixed and “closed” after a later confirmation or waiting period. Use the same event across reports.

Decide how reopened tickets work. You may measure the first resolution, final resolution, or both. Final resolution gives a fuller view when the first answer did not hold.

Freshworks defines first response time and resolution time as separate measures of the wait for a response and the time to complete an issue. Your exact calculation still depends on your ticket states, business hours, and exclusions.

A worked ticket example

Consider this fictional ticket:

The first response time is 1 hour and 30 minutes. If the team marks the issue resolved when it provides the fix, resolution time is 26 hours. If the policy waits for customer confirmation, resolution time is 28 hours.

Neither method is automatically correct. The team needs a written rule and consistent reports.

Calendar time vs. business time

Calendar time counts every minute. Business time counts only the hours when the support team is available. Both can be useful, but they answer different questions.

Calendar time reflects the customer's full wait. Business time helps the team compare work with a published schedule. State which method you use. Also define holidays, weekends, and requests that arrive outside support hours.

For example, a ticket sent Friday evening may have a short business-time wait and a long calendar-time wait. A customer-facing policy should make that difference clear. Use the response time policy template to document it.

What each metric can hide

First response time can look good when agents send quick acknowledgments but leave the real work in a queue. Resolution time can look good when teams close simple tickets fast while complex or old tickets remain open.

Review related signals:

• Age of open tickets
• Time waiting for the team and time waiting for the customer
• Reopened tickets
• Repeat contacts about the same problem
• Resolution by issue type and priority
• Customer feedback after the interaction

Use the customer support QA checklist to review answer quality. Speed alone does not show whether the guidance was correct or whether the ticket record is complete.

Set targets from your own baseline

Do not copy a public benchmark without checking your channel, hours, issue mix, staffing, and customer promise. Start with your own recent data.

1. Choose a stable four- to eight-week period.
2. Remove test and spam tickets with a written rule.
3. Calculate the average, median, and a high percentile.
4. Split the data by channel, priority, and issue type.
5. Read a sample of the fastest and slowest tickets.
6. Set an initial target that the current team can staff.
7. Review misses and adjust the process or promise.

Treat the target as an operating rule. If urgent account-access requests need faster review than general product questions, state separate priorities and make sure the intake process can identify them.

Use both metrics in one weekly review

A small team can review a compact table each week:

Support Station includes reports for first response time and resolution time, with team and agent breakdowns. Review the current Support Station features, then use the help desk setup guide to make ownership and ticket states consistent before you compare the numbers.