Metrics · SupportRoadmap Docs
First response time versus resolution time
First response time (FRT) measures how long it takes support to send the first meaningful reply. Resolution time measures how long it takes to resolve the issue. Fast first replies do not guarantee fast resolutions, and slow resolutions are not always a support failure.
By Tom Ulman · Published · Last reviewed
These two timers are easy to mix up in stand-ups and SLA reviews. Software support needs both: customers want a prompt acknowledgement and a real path to resolution.
Definitions
| Metric | Generic meaning |
|---|---|
| First response time (FRT) | Elapsed time from ticket creation (or assignment, depending on policy) until the first meaningful human or approved automated reply. |
| Resolution time | Elapsed time until the issue is considered resolved or closed under your team’s definition of done. |
Vendor-specific rules matter: business hours versus calendar hours, whether macros count as a first response, whether “pending customer” pauses the clock, and whether reopen resets resolution time. Check your helpdesk documentation rather than assuming a blog definition.
Realistic SaaS example
A customer reports webhook deliveries failing after a secret rotation. You reply in twelve minutes with a checklist (FRT looks healthy). Confirming the signature mismatch, validating a test event, and waiting for the customer’s engineer to redeploy takes six hours (resolution time is longer). That pattern is normal for integration tickets. A chat password-reset ticket may reverse the pattern: slow first reply because of queue backlog, then a two-minute resolution once someone picks it up.
Practical application
- Use FRT to watch intake and staffing.
- Use resolution time to watch investigation quality, backlog age, and engineering dependency.
- Segment by ticket type before comparing agents or teams.
- Pair timing metrics with CSAT and the overview in customer-support metrics explained.
- Work the skill inside Support Metrics that Matter.
Limitations and common mistakes
Sending an empty “looking into this” macro to protect FRT without next steps frustrates customers.
Closing tickets early to protect resolution time corrupts the metric and the relationship.
Incident-driven spikes are product events; do not treat them as silent agent performance failures.
Related concepts
Primary sources
Prefer an ordered path? Open the related roadmap skill and work through it with the curated resources.
Learn this in order