The formula is simple. The important work is defining which events start and stop the clock and which cases enter the report.
The operational formula
First response time measures how long a customer waits for the first valid public reply from the team. Zendesk documentation uses ticket creation as the start and the first public agent comment as the end. That definition is useful, but it must be adapted to your workflow and recorded before calculation.
Set reporting rules first
| Decision | Recommended rule |
|---|---|
| Start | First intake that creates work for the team. |
| Stop | First public reply that informs or directs the customer. |
| Automation | Report separately from a human reply. |
| Calendar | Choose elapsed or business time per SLA. |
| Reopen | Measure next reply as another metric. |
| Agent-created | Exclude or define an alternate start event. |
Service queues are commonly ordered by goals or SLAs, as Atlassian documents. The clock must match the calendar used in the customer promise. If an SLA pauses outside business hours, the compliance report should pause too.
Do not let the average hide the queue
Show median for typical behaviour and percentiles for the tail. Segment by channel, priority, hour, and team. A single average across chat and email combines different operating rhythms. Include volume and still-unanswered conversations; open work must not disappear because it lacks a final value.
- Start and stop events have documented names
- Automatic acknowledgements do not become human replies
- Time zone and business calendars are consistent
- Open conversations remain visible in backlog
- Tests and spam have explicit rules
- A ticket sample matches the calculation
Use the metric to act
When response time rises, inspect queue and age before pressuring individuals. The cause may be demand above capacity, routing, an uncovered shift, or unowned work. Connect the calculation to the SLA and metrics guide, backlog prioritisation, and department routing.
Turn this guide into an operating routine
Start with a small, observable pilot for “First response time: formula, rules, and common mistakes”. Select one team, one channel, and a defined period. Record the baseline: volume, queue age, ownership, exceptions, and complaints connected to the process. Then write a short rule, name the decision owner for ambiguous cases, and document how to return to the previous flow if something fails. This design prevents an unmeasured broad rollout and creates a fair before-and-after comparison.
- An operating objective stated as one verifiable sentence
- An execution owner and a supervisor for the review
- A conversation sample covering normal cases and exceptions
- Start date, duration, and a fallback rule
- A primary metric, a safety indicator, and event sources
- A final decision: keep, adjust, expand, or retire
During the pilot, review real conversations rather than trusting the dashboard alone. Confirm that state, owner, history, and next action match what the customer experienced. Separate process failure, tool limitation, integration failure, and execution error; each cause requires a different correction. At the end, publish the approved rule where the team works, retire old instructions, and schedule another review. The desired result is not only a better number. It is an operation that can explain why performance changed and reproduce the improvement without depending on one particular person.