Skip to content

Time to First Response: how fast customers get a reply

Time to First Response (FRT) is the time from the creation of a request/ticket to the agent's first response. The metric directly affects how the service is perceived and SLA compliance, and correlates with CSAT, NPS, and repeat contacts. It is important to clearly define the "clock" (calendar or business hours), the start/stop points, and exceptions.

What the metric measures

How quickly interaction with the customer begins across phone/chat/email/in-app channels, broken down by priority, team, language/region, request topic, and queue. Separate automatic auto-replies and bot responses.

Calculation

  • FRT = Time of the agent's first response − Time the ticket/request was created
  • Median (P50), P90 FRT — baseline stability metrics
  • FRT SLA Compliance, % = Tickets with FRT ≤ target / All relevant × 100
  • For telephony: ASA (average speed of answer); for chat — "the agent's first message"
  • Agree on rules for pauses (Waiting for Customer), business hours, time zones, and holidays

Do not count auto-replies as the agent's first response unless this is specified in the SLA policy.

Calculation example

120 tickets came in a day: half were answered within 10 minutes, but a few that arrived in the evening waited until morning. Average first response time is 58 minutes, the median 10 minutes. Set the target as the share of replies within an hour, not only the average.

Data sources

CRM/Helpdesk/ITSM (Zendesk, JSM, ServiceNow), telephony/ACD/IVR, chat and messaging platforms, in-app/web widgets, priority and working calendar reference data.

Interpretation

  • FRT↓ — better experience; check that it is not a "cosmetic" response without a resolution
  • FRT↑ — queues/capacity shortage, uneven shift scheduling, peak hours
  • Compare with TTR, FCR, CSAT, and backlog age to avoid gaming the metric

Useful breakdowns

  • Channel: phone / chat / email / in-app
  • Priority/Severity; request topic (reason code)
  • Team/agent/shift; region/language/time zone
  • New vs. repeat requests; hours/days of the week; peak periods

Dashboard visualizations

  • Trend of P50/P90 FRT and FRT SLA Compliance
  • Histogram/density of the FRT and queue distribution
  • Heatmap of FRT by channel/hour/team
  • Funnel: created → in queue → first response → resolved
  • Correlations FRT ↔ CSAT/FCR/TTR

How to set targets

Examples: chat — ≤ 1–2 min, phone (ASA) — ≤ 20–60 s, email — ≤ 1–4 h, priority P1 — ≤ 15 min 24×7. Agree on targets by channel/segment, on-call shifts, auto-triage/bots, and the escalation policy.

Common mistakes

  • Counting auto-replies as agent FRT
  • Mixing business and calendar hours; unclear start/stop points
  • The same SLA for different channels and priorities
  • Ignoring time zones/holidays and peak loads
  • Focusing on FRT without monitoring TTR/FCR/CSAT

Questions for discussion

  • Where are the queue bottlenecks, and what impact will auto-triage/bots have?
  • How can shifts be redistributed for peak hours without a drop in quality?
  • What effect will a targeted response for VIPs/P1–P2 priorities have?
  • Are business hours and time zones configured correctly?

Questions and answers

What is Time to First Response?

The time from a customer contact arriving to the first reply from a person (automatic replies usually do not count).

How do you calculate first response time?

For each ticket take the difference between arrival and first reply, then the average, the median and the share within the target. Account for business hours.

How do you shorten first response time?

Set up queues and priorities, staff shifts for peak hours, use reply templates and alerts for new tickets.