Verified

Chatbot First Response Time· Customer-service metric

First response time (FRT) is how long a user waits between sending a message and receiving the first reply. For the bot's own turn the answer is almost always 'instant', which is exactly why the raw number flatters every chatbot deployment. The figure that actually decides the customer experience is the FRT of the human side: how long someone waits for a person to pick up after the bot escalates. Read chatbot FRT as two numbers, not one — the trivial bot reply and the meaningful handoff wait — and never let the instant bot figure stand in for the second.

By Chatbotscape Editorial· Methodology· Published 18 June 2026· Updated 18 June 2026

Chatbot First Response Time — Definition, Formula, and Healthy Ranges (2026)

Quick answer: First response time is the gap between a user's message and the first reply they get back. For a chatbot the bot's own first response is near-instant by design, so the raw FRT looks spectacular and tells you almost nothing. The number that matters is the human first response time — the wait after the bot hands the conversation to a person — because that is where customers actually queue. Track FRT as two separate figures: the bot turn (which should be sub-second and is rarely the problem) and the post-handoff wait (which is the real service-level metric). A bot that answers in 200 milliseconds but leaves escalated users waiting eleven minutes for an agent has a great FRT chart and a bad customer experience.

What it is

First response time measures the wait before the very first reply in a conversation. In a traditional support queue it is one of the oldest service-level metrics there is: a customer sends a message, and FRT is the clock from that message to the agent's first answer. Drop a customer-service chatbot into that queue and the metric splits in two, because there are now two "first responses" worth measuring:

Bot FRT       = time from user's message → bot's first reply
Human FRT     = time from escalation → first human reply (after handoff)

The bot's first response is, in almost every case, immediate — that is the entire point of automation, and a well-built bot answers in well under a second. So the bot-side FRT is real but uninformative: it will read "instant" on every dashboard whether the bot is excellent or useless. The human-side FRT is the one that carries weight, and it is the number most naive FRT reports quietly bury by averaging the instant bot replies in with the slow human ones.

Why the blended number lies

Here is the trap. If your analytics computes a single average first response time across every conversation, the flood of sub-second bot replies drags the average down to something that looks superb — a fraction of a second — even when the customers who needed a human waited ten minutes. The metric that should expose a staffing or routing problem instead hides it, because the bot's speed is mathematically drowning out the human delay.

This is the same hazard that runs through the rest of the metric stack: a volume-flattering average that conceals the cases that actually hurt. It is why our containment-rate entry warns against numbers that look good precisely because failures drop out of view. With FRT the fix is to refuse the blended figure: report bot FRT and human FRT as two columns, and watch the human one. A rising human FRT is an early sign that escalations are outpacing agent capacity — often a side effect of a bot that escalates too much, which is exactly what the escalation rate is for.

First response time versus resolution time

FRT is a speed-to-acknowledge metric, not a speed-to-solve one, and confusing the two leads to the wrong optimization. First response time stops the clock at the first reply; it says nothing about whether that reply helped. A bot can post a perfect FRT by firing an instant "Thanks, I'm looking into that!" and then take six turns to actually resolve anything — or fail to resolve it at all.

Resolution time (sometimes time-to-resolution) measures the full arc from first message to a genuine answer or handoff, and it is the better proxy for whether the customer got help. Read the two together. A fast FRT with a slow resolution time describes a bot that is quick to greet and slow to deliver — common with flows that acknowledge instantly but stall on the actual task. A fast FRT and a fast resolution time is the genuine win. FRT on its own is necessary but never sufficient; it is the front door, not the whole house.

What counts as healthy (2026)

There is no single published FRT benchmark that separates bot replies from human replies, because most vendors report a blended average that is dominated by the bot turn. The ranges below are editorial working figures, split by which "first response" you are measuring, and they assume you are reporting the two separately rather than as one number. Treat them as directional:

What you are measuring	Healthy first response time	Reading
Bot first reply (automated turn)	Under 1-2 seconds	Effectively instant; anything slower points to a latency or integration fault, not a service problem
Human first reply after handoff, live hours	Under 1-2 minutes	The real service-level target while agents are staffed; this is the number customers feel
Human first reply after handoff, off-hours	Set by your SLA, stated up front	Acceptable if the bot clearly tells the user the wait and offers an async option
Blended "average FRT" across all chats	Ignore as a headline	Mathematically dominated by instant bot replies; useful only if decomposed

Two things move these bands more than the platform does. First, staffing: human FRT after handoff is a function of how many agents are online against how many conversations the bot escalates, so an over-escalating bot can wreck human FRT without anyone touching the agent rota. Second, expectation-setting: a stated wait the user agreed to ("an agent will reply within 5 minutes") is experienced very differently from the same wait with no warning. The honest target is a sub-second bot turn, a human turn inside a minute or two during staffed hours, and a clearly communicated SLA for everything else — never a single blended average passed off as the headline.

How platforms expose it

Where FRT lives, and whether you can split it, depends on the platform class. Support-desk products such as Intercom and Tidio report first response time natively and let you separate bot-handled from agent-handled conversations, which is what makes a decomposed FRT possible without exporting transcripts — you read the human FRT against the bot's resolution and escalation figures in the same view. Flow-first builders like Manychat and SendPulse treat the bot reply as a flow step, so the bot turn is instant by construction; the human wait surfaces only once you connect a live-chat inbox or human-takeover layer, and you usually assemble the FRT reporting around that yourself. Developer-grade builders such as Botpress let you instrument explicit timestamps on the escalation event, which is the clean way to measure post-handoff FRT as its own metric rather than inferring it.

Whatever the surface, the question to ask a platform is not "what is your average first response time" — every bot will answer "fast" — but "can you show me the first response time after a handoff, separately from the bot's own reply." A tool that only reports one blended FRT is telling you the bot is quick, which you already knew. A tool that reports human FRT by handoff is telling you whether your customers are actually being answered, and that is the number worth a place on the dashboard.

Chatbot escalation rate — the volume of handoffs that determines whether your human FRT holds up under load.
Chatbot containment rate — the self-service number that, like a blended FRT, can look good while hiding the cases that hurt.
Human handoff — the moment the meaningful FRT clock starts; a clean handoff is what keeps the wait short.
Customer service chatbot — the bot category FRT applies to.
Live chat — the human layer whose staffing sets your post-handoff first response time.

FAQ

What is a good chatbot first response time?

Split the question, because there are two answers. The bot's own first reply should be effectively instant — under a second or two — and anything slower is a latency or integration fault rather than a service issue. The human first reply after a handoff is the meaningful target: under one to two minutes during staffed hours, and a clearly stated SLA off-hours. A single blended average across all chats is not a useful headline, because the instant bot replies mathematically swamp the human waits.

Why is my chatbot's first response time so fast but customers still complain?

Almost certainly because your reported FRT is the bot turn, which is instant by design, while the complaints are about the wait after the bot escalates. A blended FRT average hides that human delay. Decompose the metric: report the post-handoff human FRT separately, and you will usually find the number that matches the complaints. Slow human FRT is typically a staffing-versus-escalation mismatch, not a bot-speed problem.

Is first response time the same as resolution time?

No. FRT stops the clock at the first reply; it says nothing about whether the user was helped. Resolution time measures the full arc to a genuine answer or handoff. A bot can post a perfect FRT with an instant "I'm looking into that" and still take many turns — or fail — to resolve the request. Read the two together: fast FRT with slow resolution time means quick to greet, slow to deliver.

How do I measure first response time after a handoff?

Timestamp the escalation event and the first human message, and report the gap as its own metric, separate from the bot's reply. Support-desk platforms like Intercom and Tidio expose this split natively; flow-first builders usually need you to instrument it around the live-chat takeover. The goal is a human FRT column that is never averaged together with the instant bot turns.

Does a fast first response time mean my bot is good?

Not on its own. A fast bot FRT is table stakes — every automated reply is fast — so it cannot distinguish a strong bot from a weak one. What distinguishes them is resolution time, CSAT, and the human FRT after handoff. Use FRT to catch the failure case (a slow bot turn signals a technical fault, a slow human turn signals understaffing); do not use it as evidence the bot is working. The metrics guide shows where FRT sits in the full KPI stack.

Sources

Intercom. Documentation — first response time and conversation analytics. intercom.com/help (verified 18 June 2026).
Tidio. Help center — response time reporting. tidio.com/help (verified 18 June 2026).
Zendesk. Customer Experience Trends Report, 2026. zendesk.com/customer-experience-trends (verified 18 June 2026).
Chatbotscape Glossary. Chatbot escalation rate. /glossary/chatbot-escalation-rate (verified 18 June 2026).
Chatbotscape evaluation methodology. /methodology (continuously updated).