Of all the numbers a support team tracks, first response time (FRT) is the one customers experience most directly. Resolution time matters more to the outcome, but FRT is what they feel in the anxious gap between hitting send and hearing back — the silence where they wonder if their message vanished into a void. Get FRT right and you have bought goodwill before you have fixed a single thing. Get it wrong and even a perfect resolution arrives to a customer who already decided you don't care.

What it actually measures

First response time is the elapsed time between a customer's first message and the first human, substantive reply from your team. That definition has two load-bearing words.

Human. An automatic "we got your message, ticket #4821 created" acknowledgment is not a first response. It is useful — it closes the void — but counting it as your FRT is the most common way teams lie to themselves. If your dashboard shows a 90-second FRT and your customers feel ignored, you are almost certainly counting the autoresponder.

Substantive. A reply that says "looking into this" is better than silence, but a holding message and a real answer are different things. Decide which you are measuring and be consistent. Many teams track both: a first response (a real human acknowledging the specific issue) and a separate first meaningful response (the first reply that actually advances the resolution).

Stop the clock honestly

FRT is only meaningful if the clock respects reality. Two adjustments separate an honest number from a flattering one.

Business hours. A message that arrives at 11pm should not accrue response time against you overnight if you don't staff overnight. Measure FRT against your published SLA business hours, or you will punish yourself for promises you never made — and you will be tempted to game the number by quietly redefining it later.

Customer waits don't count. This is about first response specifically, so the "pending customer" problem matters less here than for resolution time — but if you reopen FRT measurement after a customer reply (some teams track every response time, not just the first), pause the clock while you are waiting on them. The delay is theirs, not yours.

What good looks like

There is no universal target, but there are defensible anchors. For email and web tickets, a same-business-day first response is the floor and an under-one-hour median is genuinely strong. For live chat, the expectation collapses to minutes or seconds — a channel customers chose because it is fast. Treating chat like email is the fastest way to make a real-time channel feel broken.

The more useful move than chasing an industry benchmark is to measure your own P50 and P90, set a target near your current P90, and ratchet it down as you get faster — the same discipline that keeps SLA targets honest. A median tells you the typical experience; the P90 tells you how bad your worst-served tenth has it, which is where churn hides.

The levers that actually move it

FRT is a staffing-and-triage problem far more than a "type faster" problem. The things that move it:

  • Triage on arrival, not on reply. The single biggest FRT killer is unclaimed tickets sitting in a pile. Assign on receipt — by human triager or AI auto-routing — so no message waits simply because nobody owned it. This is the same discipline that fixes a shared inbox.
  • A real holding response, deployed deliberately. A fast, personal "I see what's happening with your export — digging in now, back within the hour" buys enormous patience. Make it a macro the agent edits, never a robotic auto-reply masquerading as human.
  • Coverage that matches arrival. Plot when tickets actually land and staff to the peaks. An FRT that looks fine on average can hide a brutal 9am Monday spike where the queue blows out for two hours.
  • Deflection upstream. Every question your self-service layer answers is a ticket that never competes for an agent's attention — which lowers FRT on everything that does reach a human.

Don't optimize it into a lie

FRT is dangerously easy to game. A team rewarded purely on FRT learns to fire a "thanks, looking into this!" within seconds and then let the ticket rot — the number looks spectacular while the actual experience degrades. Guard against this by always reading FRT alongside resolution time, reopen rate, and CSAT. A fast first response that leads nowhere is worse than an honest "this will take a day," because it teaches the customer your speed is theater.

The honest test

If your first response time is excellent but your customers still describe support as slow, you are measuring the autoresponder or rewarding empty acknowledgments. A first response that earns its name proves a real person read the real message and is genuinely on it. That is the impression FRT exists to create — and the only one worth optimizing for.