Mike HeapMike is an experienced Product Manager who focuses on all the “non-development” areas of My AskAI, from finance and customer success to product design, copywriting, testing and more.
Table of Contents
- Time to first response, in more depth
- How is time to first response measured?
- What's a "good" time to first response?
- Common misconceptions about time to first response
- Misconception 1: a fast TTFR means good support
- Misconception 2: TTFR and resolution time are basically the same
- Misconception 3: an AI auto-reply counts as a first response
- Misconception 4: lower is always better
- What time to first response is NOT, and how it relates to other metrics
- How does My AskAI handle time to first response, and what should you track instead?
- FAQs
Created time
Jun 2, 2026 02:34 PM
Title length (<60)
Author
Ecomm?
Image
Publish date
Jun 6, 2026
Slug
what-is-time-to-first-response
Featured
Type
Article
Ready to Publish
Ready to Publish
Time to first response (TTFR) is the time between a customer sending a support request and getting the first real reply, human or AI, to it.
It's the oldest speed metric in customer support, and for years it measured one simple thing: how long someone waited before a human noticed their ticket. You'll also see it called first response time (FRT) or, if you're on Zendesk, first reply time. Same metric, different label.
TTFR clocks how fast the customer gets a first reply. Whether that reply actually solves anything is a separate metric (time to resolution, which I'll come back to). That gap is the whole reason TTFR is useful and also the reason it's easy to game.
Here's the part nobody on the first page of Google has caught up with. Once an AI agent answers first, the first-reply clock drops to a couple of seconds, and the number stops telling you much about whether your support is any good. We've watched this happen with our own customers, so the back half of this post is about what to track instead.
If you're here, you're probably being measured on TTFR, setting an SLA around it, or trying to work out whether an AI's instant reply actually counts. I'll answer all three.
Time to first response, in more depth
TL;DR: TTFR measures how fast the first reply lands. Whether it solved the customer's problem is a different metric, which is why TTFR is both useful and easy to game.
The clock starts when a customer reaches out and stops when they get the first real reply. It says nothing about whether their problem was solved. That's a different clock (time to resolution), and I'll get to it below.
The naming is all over the place, which trips people up. Geckoboard and Freshworks call it first response time, Zendesk calls it first reply time, and Jira shows it as a "Time to First Response" SLA gadget.
They're all measuring the same thing: how long before the first reply (don't let the label fool you).
The edges are where teams quietly disagree, and where the number gets soft:
- When does the clock start? Usually when the ticket is created, but some teams start it when the ticket is first assigned, which flatters the number nicely.
- Does an auto-reply stop it? An automated "we've got your email" acknowledges the ticket without answering it. Most honest setups say it doesn't count (plenty of dashboards quietly let it).
- Business hours or calendar hours? A ticket that lands at 2am and gets answered at 9am is a seven-hour wait on a calendar clock and near-zero on a business-hours clock.
Two teams both reporting a "one-hour TTFR" can be measuring completely different things. Knowing those edges is the difference between a number you can trust and a number someone's managing.
How is time to first response measured?
TL;DR: Average the gap between each ticket and its first reply, per channel. Use the median over the mean, so a few overnight tickets don't flatter or wreck the number.
The formula is simple. Geckoboard writes it as the sum of first-response times divided by the number of tickets. Measure the gap on each ticket, add them up, divide.
In practice, I'd report it per channel and reach for the median over the mean (the boring-but-effective option here). A handful of tickets that came in over the weekend will drag the average up and make a fast team look slow. The median ignores those outliers and tells you what a typical customer actually felt.
The two choices that matter most are what goes in the top and bottom of that sum:
- The numerator (what counts as the "first response"). A real attempt to answer the question. An auto-acknowledgment that says nothing useful shouldn't count, and this is where TTFR gets gamed most often.
- The denominator (which tickets count). Strip out spam and reopened tickets, and decide up front whether you're on a business-hours or 24/7 clock.
Different platforms make these calls differently, which is why you can't compare two teams' numbers without knowing how each one is set up. Here's how the metric is named and clocked across the tools we see most across our customer base:
Vendor | What they call it | Clock starts, and what counts |
My AskAI | First response (AI answers first) | Ticket arrives, AI's first real reply lands; instant on covered questions |
Zendesk | First reply time (FRT) | Ticket created, first public agent comment; business hours configurable |
Intercom / Fin | First response time | First teammate or Fin reply |
Freshdesk | First response time | First agent response; SLA-driven |
Gorgias | First response time | First agent or automation reply |
What's a "good" time to first response?
TL;DR: It depends entirely on the channel. Under a minute on live chat, under an hour on email and social, around three minutes on phone. A single blended number tells you nothing.
There's no one good number, because customers hold each channel to a different standard. They want a live chat reply in under a minute and happily wait a few hours for an email.
So always say which channel you mean. Here are the bands I'd hold a team to, pulled from public 2026 benchmark data:
Channel | World-class | Solid | Average | Needs work |
Live chat / messaging | under 40 sec | under 2 min | ~1.5 min | over 5 min |
Email | under 1 hr | under 4 hrs | 7 to 10 hrs | over 24 hrs |
Social | under 1 hr | under 4 hrs | 4 to 5 hrs | over 24 hrs |
Phone | under 1 min | ~3 min | n/a | over 5 min |
A few anchors behind that table: the accepted phone standard sits around three minutes, social replies are expected within the hour (most brands take four to five), and email gets a 24-hour grace period in customers' heads even though the best teams answer inside four. On live chat, people start abandoning once the wait creeps past three to five minutes.
The reason TTFR became a headline metric at all is simple. In survey after survey, speed is the thing customers say they value most, with 63% ranking speed of response as the number one factor in a good support experience (ahead of speed of resolution at 57%). So teams optimized for it.
Then AI changed the maths. Once an agent answers first, the world-class floor on covered questions drops to "instant", and a metric where everyone scores a perfect time stops separating good support from bad. Speed got cheap, which sets up the next bit.
Common misconceptions about time to first response
TL;DR: A fast TTFR doesn't mean good support, an AI acknowledgment isn't a real first response, and chasing the number too hard pushes agents into empty holding replies.
Misconception 1: a fast TTFR means good support
I have to push back on this one most weeks. A fast first response paired with a low resolution rate is just fast disappointment.
An instant reply with no answer in it games the metric, and AI makes that worse: you end up with replies in the seconds that look perfect on the dashboard and fix nothing. So I'd never read TTFR without the resolution number sitting right next to it.
Misconception 2: TTFR and resolution time are basically the same
They measure opposite ends of the same conversation. TTFR is the gap before the first reply; time to resolution is the total time until the problem is solved. You can have a brilliant TTFR and a dreadful resolution time, and (trust me) plenty of teams do.
Misconception 3: an AI auto-reply counts as a first response
Only if it's a real attempt to answer. An acknowledgment bot that says "a human will be with you shortly" resets the clock without helping anyone. I'd call it the digital version of putting a caller on hold and counting that as picking up.
Misconception 4: lower is always better
Push a team hard enough on TTFR and they'll start firing off empty holding replies just to stop the clock, which annoys customers and drags CSAT down. What we're all after is a fast first response that's also useful.
What time to first response is NOT, and how it relates to other metrics
TL;DR: TTFR is speed-to-first-reply. Resolution time is the outcome, AHT is agent effort, an SLA is the target, and containment is whether a human was needed at all.
TTFR sits in a family of support metrics that get muddled together. Here's how it differs from its closest neighbors:
Term | What it measures | How it differs from TTFR |
First reply time (FRT) | Latency before the first agent reply | Same metric, just a different vendor's name for it |
Time to resolution | Total time until the issue is fully solved | The end of the conversation, where TTFR is the start |
Average handle time (AHT) | Active agent time spent working a ticket | Agent effort, where TTFR is customer wait |
SLA (service level agreement) | The promised response or resolution target | The target you set, where TTFR is what you actually hit |
Containment / autonomous resolution rate | Share of tickets handled without a human | Whether a human was needed, where TTFR is how fast one replied |
The one worth dwelling on is time to resolution. As AI takes over the first reply, resolution time becomes the metric that still tells you something true, because it measures the outcome instead of the acknowledgment. More on that next.
How does My AskAI handle time to first response, and what should you track instead?
TL;DR: When an AI answers first, TTFR on covered questions goes near-instant and stops being a useful signal. We'd point you at total time to resolution plus time to first human response on escalated tickets.
When an AI agent answers first, TTFR on covered questions goes near-instant. One of our customers, Swytch (an ecommerce business selling e-bike conversion kits, running on Zendesk), saw exactly that. Before us, in their words, "reply times were creeping up, and customers were waiting too long to get answers, sometimes for very simple questions."
After they connected My AskAI, reply times for automated questions dropped to zero and overall response times went from days to minutes, with the AI handling over 4,050 tickets a month at an 81% deflection rate. They told us their first-response-time metric stopped making sense to track once the AI was live. Every covered question got answered instantly, so the number stopped carrying any information.
That's the honest version of what an AI agent does to this metric. My AskAI's value here is plain: a real first answer lands in seconds on the questions the AI can resolve, and the rest hands over cleanly, with a full conversation summary, inside the same helpdesk.
On the counting: we treat a conversation as resolved when it wasn't escalated to a human, and we keep escalation deliberately easy. A customer can ask for a person in plenty of ways, and the AI hands off when it can't answer, when it picks up frustration, or when a ticket hits a topic you've set for escalation. We don't claim to know an issue was truly solved unless the customer tells us so.
So if raw TTFR stops being useful, here's what I'd track instead:
- Total time to resolution. Did you actually solve it, end to end, and how fast? This one survives the AI shift because it measures the outcome rather than the first hello.
- Time to first human response on escalations. Once the AI handles the easy first reply, this is the number that still measures your humans: how quickly a person picks up the tickets the AI couldn't. Skip it and your blended TTFR averages out to "seconds" and tells you nothing.
Our Insights view surfaces resolution time and handover rates directly, which is where I'd start if you're making this switch. One honest caveat: TTFR only collapses on covered questions. Complex or brand-new tickets still queue for a human, but because the handoff carries the full context, that human's clock starts warm instead of cold.
FAQs
What is a good first response time?
It depends on the channel, so there's no single good number. On live chat, aim for under a minute (the best teams answer in under 40 seconds). On email, under an hour is world-class and under four hours is solid. On social, within the hour, and on phone, around three minutes is the accepted standard.
What is a first response time?
First response time (FRT) is another name for time to first response: the gap between a customer reaching out and getting the first real reply. We treat the two terms as interchangeable.
What is first reply time?
First reply time is Zendesk's name for the same metric. If your team is on Zendesk, "first reply time" and "time to first response" mean the same thing.
How is first response time calculated?
Add up the first-response time for every ticket and divide by the number of tickets. Report it per channel, and use the median rather than the mean so a few overnight tickets don't distort the picture.
Does an automated reply count as a first response?
Only if it's a real attempt to answer the question. An auto-acknowledgment ("we've received your message") isn't a first response in any honest definition, since it resets the clock without helping. An AI agent that actually answers does count, because the customer got a real reply.
What is the difference between first response time and resolution time?
First response time measures how long until the first reply (I see these two swapped all the time). Resolution time measures how long until the problem is fully solved. One is the start of the conversation, the other is the end, and you can be fast on the first while slow on the second.
What's the difference between TTFR and an SLA?
TTFR is the time you actually measured. An SLA is the target you've promised, for example "first response within one hour". The SLA is the goal; TTFR is whether you hit it.
Does first response time differ by channel?
Hugely. Customers expect a chat reply in under a minute but tolerate a same-day email reply. Always measure and report TTFR per channel, because a blended number across chat and email is close to meaningless.
Is first response time still a good KPI?
It was historically the single most important speed metric, and it still matters where a human replies first. But in 2026, with AI agents answering first, I'd never track it alone. Pair it with total time to resolution and time to first human response on escalated tickets, or you're optimizing a number AI has already made trivial.
Why does time to first response matter?
Because speed is what customers say they value most, with more than 60% ranking it as the number one factor in a good support experience. A slow first response is the most common and most visible support failure. The catch is that "fast" only counts if the reply actually helps.
