First response time

First response time, often shortened to FRT, measures the gap between the moment a support request arrives and the moment your team sends the first meaningful reply to the customer. It answers a simple question: how long did this person wait before a human acknowledged their problem and started to help?

The key word is meaningful. A first response is a real human reply that engages with the request, even if it only asks a clarifying question or sets expectations. An automatic message that says nothing more than your email has been received is not, on most definitions, a first response, because the customer has not yet been answered by a person.

First response time is a waiting metric, not a workload metric. It says nothing about how hard the issue is or how many replies it will take to close. It captures the part of the experience customers feel most sharply, which is the silence before anyone answers.

At its simplest, first response time is the first reply timestamp minus the request received timestamp. The detail that matters is where you start and stop the clock, and whether the clock keeps ticking outside working hours.

When the clock starts

The clock starts when the request lands in your support system: the time the email arrived in your support address, not the time anyone happened to open it. Starting from when an agent first looks at the queue would flatter a slow team, so the arrival time is the honest starting point.

When the clock stops

The clock stops at the first genuine human reply that is sent to the customer. Internal notes between teammates do not count, because the customer never sees them. Neither does a templated auto-acknowledgement on its own. The first reply that actually goes out to the customer is what stops the timer.

Calendar hours versus business hours

There are two common ways to count the time in between. Calendar-hours first response time runs continuously, including overnight, weekends and bank holidays. Business-hours first response time only counts time inside your published working hours, so a request that arrives at 6pm and is answered at 9am the next morning may show as a short wait rather than fifteen hours. Both are valid; the important thing is to state which one you use and apply it everywhere.

Average, median and worst case

How you summarise many tickets matters too. An average first response time is easy to skew with a few very slow outliers, so a median (the middle value) often describes the typical experience more fairly. It is also worth watching your slowest tickets, because the customer who waited longest is the one most likely to complain or churn.

First response time	Time from request arriving to the first human reply being sent.
Average FRT	Mean wait across all tickets in a period; easily skewed by outliers.
Median FRT	Middle wait value; usually a fairer picture of the typical experience.
Business-hours FRT	Wait counted only inside your working hours, pausing overnight and at weekends.
Calendar-hours FRT	Wait counted around the clock, including overnight, weekends and bank holidays.

There is no single correct number, because expectations differ by channel and by what you have promised customers. That said, a few reference points help when you are setting a target for email support.

• Same business day is a common baseline that most small teams can meet without staffing around the clock.
• Within two to four working hours is a strong target for a focused team that watches its queue through the day.
• Under one working hour is achievable for higher-priority requests, but it usually needs a clear ownership routine and saved replies for common questions.
• Next business day is acceptable for low-priority or out-of-hours requests, as long as customers know to expect it.

The right target is the one you can hit consistently. A promise of one hour that you miss half the time damages trust more than an honest promise of one business day that you always keep. Set the target against your real working pattern, then measure against that pattern rather than the wall clock.

It also helps to vary the target by priority. An urgent account problem and a general enquiry do not deserve the same wait, so many teams hold a tighter first response target for high-priority tickets and a more relaxed one for everything else.

For a team that does not run a 24-hour support desk, measuring first response time against business hours is usually the fairer and more useful choice. It judges the team on the time it was actually open, rather than penalising it for hours when nobody was meant to be working.

To measure against business hours you need to define them once: your working days, your start and finish times, and which dates are holidays. In the UK that means accounting for bank holidays, which differ across England and Wales, Scotland and Northern Ireland, so a desk that treats every weekday as a working day will mis-measure the days around a bank holiday weekend.

A worked example shows the difference. A request arrives at 4:30pm on a Friday, before a bank holiday Monday, and is answered at 9:30am on the Tuesday. On calendar hours that is roughly 89 hours of waiting. On business hours, with a 9am to 5pm working day and the bank holiday excluded, it is closer to two working hours. Same emails, very different numbers, which is why the definition you choose has to be clear before you compare teams or periods.

First response time is a strong proxy for whether customers feel looked after. The longer the silence after someone asks for help, the more anxious or annoyed they become, and the more likely they are to chase, escalate or simply give up. A prompt first reply, even one that only acknowledges the problem and sets a realistic next step, changes the tone of the whole exchange.

It is also a useful early warning for the team. A first response time that is creeping up often means the queue is growing faster than the team can clear it, that ownership is unclear, or that a particular topic is generating more questions than usual. Watching the trend, not just today's figure, tells you when to add a saved reply, rebalance work or look at the root cause.

For small businesses, a dependable first response time is a genuine competitive edge. You may not be able to match a large rival on opening hours or headcount, but you can answer quickly and personally inside the hours you do work, and customers notice when a small team replies faster than the big one they expected to wait on.

First response time sits alongside a handful of other support metrics. Understanding how they differ keeps your reporting honest.

Resolution time	How long the whole issue takes to close, across every reply, not just the first.
SLA	A service level agreement: the response and resolution targets you commit to, often with a clock that tracks them.
Response time	A broader term that can mean the first reply or the time between any reply and the next; first response time is the specific first-reply case.
Handle time	The active time an agent spends working a ticket, which is a workload measure rather than a waiting measure.

Solves is an email-first support desk, so first response time is a metric it is built to track. Incoming support email becomes an owned ticket the moment it arrives, which gives a clean start time, and the first public reply you send to the customer gives a clean stop time. Internal private notes are kept separate, so they never get mistaken for a customer reply.

First-response and resolution SLA timers in Solves carry per-brand or organisation targets, and a breaching view surfaces overdue tickets so the work due soonest is easy to find. The reports then show first response performance over time, so you can see whether you are meeting your target and spot a queue that is starting to slip before customers feel it.