What is first response time?

What it means

First response time, usually shortened to FRT, is the wait a customer experiences between asking and being answered for the first time in a conversation. It is the single most visible service metric you have, because it is the only one the customer can measure themselves while it is happening.

It is also two metrics wearing one name. Calendar FRT counts every minute on the clock, including nights and weekends, and describes the customer experience. Business FRT subtracts the hours your team was not working, and describes team performance. Both are correct. Publishing one and managing to the other is where the trouble starts, because the numbers can differ by an order of magnitude.

The metric matters on both sides of the business. In support it drives satisfaction more reliably than resolution time, because a customer who has been answered knows their problem is being handled even if it is not finished. In sales it is the first component of the sales cycle, and lead-response research has repeatedly found a steep decay in contact and qualification rates once the first attempt slips past the first hour.

The formula, written out

FRT = first_substantive_outbound_at - first_unanswered_inbound_at

• first_unanswered_inbound_at: the timestamp of the earliest inbound message from the customer that has no outbound reply after it. In a burst of three messages, this is the first of the three, not the last.
• first_substantive_outbound_at: the timestamp of the first outbound message from an agent or an answering AI, that is publicly visible to the customer. Automated receipts, internal notes and system events are excluded.

For business-hours FRT, subtract the closed intervals:

BusinessFRT = FRT - sum of the durations of all non-working intervals that overlap the span

• Non-working intervals: everything outside the queue's opening hours, plus declared holidays, expressed in the queue's timezone rather than the server's.

And for reporting, over a set of conversations:

Median FRT = the 50th percentile of the FRT values

p90 FRT = the value below which 90% of conversations fall

Never report the mean. Response-time distributions have a long right tail, so a mean is dominated by a handful of overnight arrivals and describes no conversation that actually happened.

A worked example, end to end

Six conversations across a Tuesday and Wednesday. The queue is open 09:00 to 18:00.

1. Inbound Tue 09:04, agent reply Tue 09:18. Fourteen minutes.
2. Inbound Tue 11:47, reply Tue 12:09. Twenty-two minutes.
3. Inbound Tue 16:52, reply Tue 17:31. Thirty-nine minutes.
4. Inbound Tue 18:40, forty minutes after close, reply Wed 09:06. Calendar: 866 minutes. Business: 6 minutes, because 18:40 to 09:00 is closed time.
5. Inbound Wed 09:12, reply Wed 09:20. Eight minutes.
6. Inbound Wed 10:30, auto-acknowledgement at 10:30:02, human reply Wed 12:05. Ninety-five minutes.

Calendar values: 14, 22, 39, 866, 8, 95 minutes.

• Mean: 1,044 / 6 = 174 minutes, or 2 hours 54 minutes.
• Median: sorted, the middle two are 22 and 39, so 30.5 minutes.
• p90 by nearest rank: 866 minutes.

Business-hours values: 14, 22, 39, 6, 8, 95 minutes.

• Mean: 184 / 6 = 30.7 minutes.
• Median: middle two are 14 and 22, so 18 minutes.
• p90: 95 minutes.

Same six conversations, four defensible headline numbers ranging from 18 minutes to 2 hours 54 minutes. The mean-versus-median gap is entirely conversation 4, and the calendar-versus-business gap is entirely the overnight. Anyone quoting a single FRT without saying which of the four it is has not really told you anything.

The practical reading: business median 18 minutes says the team answers quickly while it is at its desk. Calendar p90 of 866 minutes says a customer who writes in the evening waits until the next morning. Those are two different problems with two different fixes, and only one of them is about how fast agents type.

Three ways the number goes wrong

Counting the auto-acknowledgement. Conversation 6 received a receipt two seconds after the inbound. Treat that as the first response and its FRT becomes 0.03 minutes. Recompute the business-hours set as 14, 22, 39, 6, 8, 0.03: the median falls from 18 minutes to 11 minutes and the mean from 30.7 to 14.8. Now imagine the acknowledgement fires on all six, which is what happens in a real deployment. Every FRT collapses to a couple of seconds, the dashboard turns green, and the metric now measures your mail server's latency. Exclude anything whose author type is a bot or a system rule, unless it genuinely answers the question.

Measuring from ticket creation. If the clock starts at ticket.created_at rather than at the customer's message, every agent-created record reports an FRT near zero, since the agent typically writes the first message moments after creating the ticket. In a queue where a third of records are created by agents following up on phone calls, this alone can pull the reported median down by half while nothing changes for any customer. Anchor to the inbound message and exclude conversations that have no inbound message before the first outbound.

Anchoring to the last message in a burst. A customer writes at 09:04, adds context at 09:05 and again at 09:07, and gets an answer at 09:18. Anchored to the first unanswered inbound the wait is 14 minutes; anchored to the most recent message it is 11. The error is small per conversation and systematic in direction, and it is largest for the customers who write most often, who are usually the most frustrated. Use the first unanswered inbound.

How FRT is actually derived from CRM data

The computation needs three things and a calendar:

• The conversation record, with the channel, the queue, and whether it was customer-initiated or agent-initiated.
• The message table, with direction (inbound or outbound), author_type (contact, agent, AI, bot, system) and a visibility flag distinguishing a public reply from an internal note.
• Precise timestamps stored in UTC, with the display and business-hours arithmetic done in the queue timezone.
• A business calendar per queue: opening hours per weekday, holidays, and any temporary closures.

The edge cases that separate a real implementation from a demo:

• Internal notes. An agent writing a note to a colleague produces an outbound-looking row that the customer never sees. If it stops the clock, FRT becomes a measure of internal chatter.
• Reopened conversations. A resolved ticket that receives a new inbound three days later should start a separate next-response-time measurement, not overwrite the original FRT and not create a second FRT for the same conversation.
• Merged conversations. When two records are merged, two inbound anchors exist. Keep the earlier one, since that is when the customer first asked.
• Transfers between queues. The clock belongs to the conversation, not the queue. Attribute the result to whoever answered, and count transfers separately.
• Weekend and holiday boundaries. The business-hours subtraction has to walk the calendar interval by interval. A message arriving at 17:58 on the Friday before a public holiday spans three closed periods, and a naive "subtract 15 hours per night" approximation will be wrong by a day.
• Channel mixing. A live chat message and an email arriving at the same second carry different expectations. Compute one FRT per conversation but always report it split by channel, because a blended median across chat and email describes a conversation type that does not exist.

Why it matters

FRT is the earliest controllable moment in any customer relationship. Everything downstream, satisfaction, resolution rate, churn, is influenced by whether the first message got an answer while the person was still paying attention. It is also unusually actionable: unlike most quality metrics it can be improved by staffing, routing and alerting, without changing how anybody does the substantive work.

On the sales side it is the first slice of the sales cycle, and by far the cheapest to remove. Days saved between an inbound arriving and a rep touching it come straight off the denominator of pipeline velocity, which is the one variable in that formula with more than linear leverage.

Common mistakes

• Reporting the mean. One overnight message moves it by hours. Use the median and the p90 together.
• One number across all channels. Chat and email expectations differ by two orders of magnitude.
• A target on the median only. A team can hit a great median while abandoning the slowest ten percent entirely. Target the p90.
• Business hours in the wrong timezone. A workspace configured in UTC while the team sits in Istanbul will misattribute three hours of every day.
• Excluding conversations that were never answered. A conversation with no reply has no FRT, so it silently drops out of the report. Count them separately and prominently.

Related concepts

• CSAT: the satisfaction score FRT moves most reliably.
• Lead routing: the system that decides who is supposed to answer.
• Round-robin assignment: an immediate owner is what starts the clock running against someone.
• Pipeline velocity: response delay is sales cycle length in disguise.
• NPS: the relationship-level counterpart to a conversation-level score.
• Omnichannel CRM: why FRT has to be computed per channel and compared across them.

How Pinlyx handles it

Pinlyx stores every message with its direction, author type and visibility, so automated acknowledgements and internal notes never stop the clock. Business hours are configured per workspace with a real timezone and holiday list, both calendar and business FRT are available side by side, and unanswered conversations are surfaced as their own queue rather than quietly dropping out of the average.