First Response Time: 4 Steps to Measure It Before You Cut It

FRT only means something if everyone on your team measures it the same way. An automated "we got your message" ticket confirmation does not count as a first response. The clock stops when a human (or a tool acting on their behalf) sends a reply that actually addresses the customer's question, even partially.

That boundary gets blurry fast once you add channels and time zones into the mix.

• Live chat and social DMs: the first substantive reply, not the typing indicator or canned greeting.
• Email and web forms: the first reply after the initial enquiry, excluding out-of-office autoresponders.
• Phone: time to answer, or time to callback if the call is missed and queued.
• Multi-channel threads: measure from the first enquiry regardless of which channel the customer used, and track the first response on whichever channel they receive it.

Teams running follow-the-sun support measure FRT continuously, while business-hours teams usually pause the clock overnight and resume it when the shift starts, so a Monday-morning inbox does not look artificially slow.

The formula is simple: first response timestamp minus initial enquiry timestamp. Everything else is detail about which timestamps you capture and how you summarise them across hundreds or thousands of tickets.

Average first response time (AFRT) is the mean of all individual FRT values over a given period. Median AFRT, meanwhile, takes the middle value when every ticket is lined up from fastest to slowest. Because a handful of very slow tickets can drag a mean upward, many teams report both, and lean on the median when the data is skewed.

1. Pick the window: a day, a week or a month, matching your reporting cadence.
2. Pull every ticket's two timestamps: when it arrived and when the first substantive reply went out.
3. Subtract to get each ticket's FRT.
4. Sum and divide by the number of tickets for the mean, or sort and take the midpoint for the median.

Two quick examples make this concrete. Say a chat conversation arrives at 10:02 AM and an agent replies at 10:05 AM: that is a three-minute FRT. Say an email arrives at 9:14 AM and the first reply goes out at 1:44 PM the same day: that is a four-hour, thirty-minute FRT. Run that calculation across a week of tickets per channel and you have a baseline worth tracking.

Expectations shift sharply by channel, because customers calibrate "fast" against what the medium normally delivers.

• Live chat: customers expect a reply within minutes, often under five.
• Phone: answered within seconds to a couple of minutes before frustration sets in.
• Social media: typically within the hour during business hours.
• Email: a same-day or next-business-day reply is still considered acceptable by most customers.

High-resolution timing standards such as those documented in PerformanceResourceTiming show how precisely modern systems can timestamp events (in that case, the moment a web server's response starts to arrive, not a reply to a customer), which matters when a chat widget or booking form is doing some of the replying for you. Priority tickets (a payment failure, a safety issue) deserve tighter internal targets than a general question. Set targets your team can hit consistently before layering on an aspirational stretch goal.

Before you fix FRT, work out which of four categories is actually responsible.

• Volume spikes and staffing gaps: a promotion, a seasonal rush or an unfilled shift leaves enquiries stacking up faster than agents can clear them.
• Routing and triage inefficiencies: tickets sitting in the wrong queue, or waiting for manual sorting before anyone sees them.
• Tooling gaps and channel fragmentation: five inboxes and no shared view mean a message can sit unseen in a channel nobody is watching.
• Deliberate policy choices: some teams intentionally prioritise resolution quality or first-contact resolution over speed, which is a legitimate trade-off as long as it is a choice rather than an accident.

Pro Tip: Pull a week's worth of tickets and tag each slow one with its likely cause before changing a single process: the fix for a staffing gap looks nothing like the fix for a routing problem.

Reliable tracking starts with the right fields on every ticket: creation timestamp, first agent reply timestamp, every status change in between, and a channel tag. Without those four, you cannot calculate FRT consistently, let alone compare it across channels.

Once the data is captured, report more than a single average. AFRT tells you the overall picture, but median, P75 and P90 reveal how your slowest tickets behave, which matters because FRT distributions usually have a long tail of delayed replies dragging the mean upward. SLA breach rate, the share of tickets that missed your target entirely, is often the number that leadership actually cares about.

A team that only watches its average FRT can look healthy while a tenth of its customers wait hours longer than everyone else.

Most help desk platforms let you build a dashboard around these fields without writing custom code: group tickets by channel and day, calculate the time difference between the two timestamps, and chart the distribution rather than a single line. Set an SLA alert that flags any ticket approaching its breach threshold while there is still time to act, not after the fact.

A handful of changes tend to produce most of the improvement, in roughly this order of effort versus payoff.

1. Fix routing first: priority tags and simple rules that send tickets to the right queue immediately remove the slowest part of the process, the wait before anyone even looks.
2. Build a template library: common questions deserve a reply agents can personalise in seconds rather than compose from scratch.
3. Add automated acknowledgements that hand off cleanly: an instant "we're on it" that still routes to a human keeps customers from feeling ignored while the real reply is drafted.
4. Rework shift coverage: staggered shifts, part-time cover for peak hours, or a follow-the-sun handoff close the overnight and lunchtime gaps that quietly inflate FRT.
5. Invest in self-service: a knowledge base that answers the most repeated questions reduces how many tickets need a first response at all.

Pro Tip: Test routing changes on one queue before rolling them out everywhere, and watch CSAT alongside FRT: a faster reply that reads as rushed can cost you more than it saves.

An AI receptionist like subba answers web chat the moment it arrives, and phone calls too with the phone add-on, every hour of the day, which removes the overnight and lunchtime gaps that usually inflate FRT. For contact forms it drafts replies in the business's tone, so teams can review responses before switching to full automation, keeping control over quality while cutting the wait.

• Instant replies in web chat, and on calls with the phone add-on, close the gap between enquiry and first response to seconds.
• Draft-first workflows for contact forms let owners approve the tone before anything goes fully automated.
• Automated booking and reminders reduce the follow-up messages that would otherwise add to the queue, which particularly suits appointment-heavy businesses like dental practices and veterinary practices.

First response time and response rate sound related but answer different questions. FRT measures how long a customer waits for the first reply, down to the minute or hour. Response rate measures what share of enquiries receive any reply at all, regardless of how long it took.

A team can have a strong response rate, replying to nearly every enquiry eventually, while still running a slow FRT if those replies routinely arrive after a long delay. The reverse is also possible: a team that replies within minutes to the enquiries it handles, but quietly lets a portion of messages go unanswered, will show an excellent FRT alongside a weak response rate.

Both numbers matter, but they point to different problems. A low response rate usually signals a process gap: messages falling into an unmonitored channel, a form nobody checks, a social DM that gets missed entirely. A high FRT, by contrast, usually signals a capacity or routing problem among the enquiries you are actually seeing. Tracking only one metric hides the other's failure mode, so a team obsessed with speed can still lose customers to messages that never got a reply at all, while a team obsessed with coverage can still frustrate customers who wait hours for that reply to land. Report both side by side, and treat a gap between them as the first thing worth investigating.

The pattern across booking-driven businesses is consistent: when the time between an enquiry and a reply shrinks, more of those enquiries turn into booked appointments rather than silence. A salon that used to let web form enquiries sit until the next quiet moment, for instance, loses a share of those customers to whichever competitor replies first. Close that gap and the same volume of enquiries converts at a noticeably higher rate, simply because the customer is still waiting rather than already booked elsewhere.

The mechanism is straightforward: a customer messaging a business about a haircut, a boiler repair or a dental checkup is usually comparing a short list of options at the same time. Whoever answers first often wins the booking, independent of price or reputation, because the enquiry itself signals readiness to buy right now. A roofer who replies within minutes to a storm-damage enquiry is far more likely to get the job than one who replies the next day, by which point the homeowner has already called someone else.

This is why booking-heavy trades, from roofers to counsellors and therapists, tend to see the clearest link between FRT and revenue: every delayed reply is a potential no-show or a customer who found someone faster. The lesson generalises beyond any one trade: when speed is the deciding factor in a purchase decision, first response time stops being a support metric and starts being a sales metric.

Training for speed works best when it treats FRT as a skill, not just a target on a dashboard. New agents should see real examples of fast, substantive first replies alongside slow ones, so they understand the difference between a quick acknowledgement and an actual answer.

Give agents permission to send a short, honest holding reply when a full answer needs research: "Checking this now, back to you within the hour" protects FRT without sacrificing accuracy. Build template libraries agents can personalise rather than compose from scratch, since typing speed is rarely the bottleneck, decision paralysis is. Review a sample of each agent's first replies regularly, not to police them, but to spot where hesitation or unclear ownership is adding minutes.

Rotate ownership of peak hours so no single agent is left absorbing a volume spike alone, and make the SLA target visible on the floor rather than buried in a monthly report. Teams that treat FRT training as a one-off onboarding module tend to see it drift back up within a quarter. The ones that keep it steady treat it as an ongoing coaching habit, built into regular one-to-ones rather than an annual refresher.

Chasing FRT in isolation is a trap. A small team with one or two agents should prioritise FRT when enquiries are pre-sale and time-sensitive, like a booking request, and prioritise resolution quality when the issue is already complex. Fix routing and acknowledgements first, then tackle resolution time once replies are consistently fast.

Roland

A booking enquiry answered in seconds converts far more often than one left waiting, and this is the exact gap we built our AI receptionist to close: instant replies in web chat, and on calls with the phone add-on from £29.99 a month, in your business's tone, with contact-form drafts you can approve before anything runs on autopilot.

Plans start at £9.99 a month on our Starter plan, with Pro and Studio tiers available as your enquiry volume grows. Explore how it fits your trade on our solutions page, or read how it works for car garages and MOT centres.