First Response Time

What a waiting customer experiences is not the problem itself but the silence around it. Someone who writes in to say they were charged twice has no way of knowing whether the message even arrived. So they send the same thing through chat, and when that stays quiet too, they call. One question turns into three, and the support team gets busier.

Inside the team there was no answer either. Someone would say support felt slow lately, the person handling tickets would insist everything gets answered the same day, and the conversation stopped there because neither side had evidence. Nobody could say how many of yesterday's questions were still sitting without a reply.

First response time (FRT) turns the length of that silence into a number. The deliberate choice is measuring whether anyone reacted, separately from whether anyone solved it. A question that takes two days to diagnose is bearable if "we're looking into it" arrives in ten minutes. Reacting and resolving are different jobs, and reacting can improve immediately without anyone getting better at the product.

For each question, take the gap between the moment it arrived and the moment the first human reply went out, then collect those gaps over a period and pick a representative value.

The unit being counted is one support ticket — a single incoming question wrapped in an id, an owner, and a status. Without that wrapper, a customer's third email can't be told apart from a new question, and the number blurs.

The calculation has three steps.

1. Fix the start time. This is when the customer sent the email or typed the first line into chat.
2. Fix the end time. This is when an agent first replied to that ticket. An automated "we've received your message" does not count. Counting auto-replies makes every first response time one second, and the metric stops measuring anything.
3. Take the difference per ticket, gather a month of them, and pick a representative value. Given 10 minutes, 25 minutes, 40 minutes, 2 hours and 9 hours, the middle value is 40 minutes.

Use the median rather than the mean. A mean gets dragged around by one extreme case: those five tickets average out to 2 hours and 27 minutes, which is far worse than what four of the five customers actually experienced.

Decide up front how business hours are handled. A question that lands at 7pm on Friday and gets answered at 10am on Monday is 63 hours on the clock and 1 hour if only weekdays from 9 to 6 count. Teams that promise round-the-clock support count clock time; teams that staff business hours count business hours. Mixing the two makes last month and this month impossible to compare.

The baseline depends on the channel. In a chat widget the customer is sitting in front of the screen, so anything past two minutes feels like the conversation dropped. Email answered hours later feels normal. One minute in chat and four hours over email can both be good numbers for the same team.

Attainment against a promise matters more than the raw value. A support SLA is a service level agreement stating in advance how fast the first reply will come. If the team promised four hours, the number to look at isn't a two-hour average but something like "94 percent answered within four hours." A good average still hides the one ticket in ten that runs past a day, and that ticket becomes a refund request.

So look at the distribution too. A median of 40 minutes with a 95th percentile of 9 hours means most people are served quickly while one ticket in twenty sits untouched for half a day. The long tail usually collects in predictable places: weekends and nights, languages covered by a single agent, and ambiguous questions nobody considers theirs.

When the number is bad, look at incoming volume before hiring. If the same question keeps arriving, one article in the help center removes those tickets entirely, which is faster than answering them. If the replies keep coming out similar, save them as macros — stored response templates an agent edits for the specific customer before sending.

"The median is 30 minutes but the 95th percentile is 8 hours. Overnight tickets are all sitting in that tail."

The headline number looks fine while one time window is being left unattended.

"Can you pull that again using the time a person replied, not the auto-acknowledgment?"

The current figure is counting system replies instead of real responses.

"We held first response this month but missed the target on resolution time."

The team reacted quickly and then took a long time to finish the job.

At Pagedeck, Sofia brings this number to the Monday review. The chat median went from 3 minutes to 11 minutes one week because a bug produced a burst of questions and one agent spent the day on nothing else. Rather than asking for another hire, Sofia asked Theo when the fix would ship.

Enterprise tickets get looked at separately. When a customer whose contract specifies a response time is sitting at the back of the queue, that isn't just slow — it's a commitment being broken, so it sits on the list Grace checks each quarter.

The most common mistake is reading a short first response time as good support. It's the first number the customer experiences, so the assumption is natural. But the value measures reaction speed only, and says nothing about whether the problem got solved. Make it the target on its own and agents start sending "I'll look into this and get back to you" first and beginning the actual investigation later. Six months on, first response time has dropped from 40 minutes to 8 while complaints are flat or worse. That's why this number is always read next to resolution time.

Blaming the support team for a bad number is the other one. Slow replies look like slow repliers, but the queue usually grows from the intake side. If one confusing checkout screen generates thirty questions a day, staffing against it barely moves the number even at double the headcount. Unless the content of repeat questions gets handed to the product team, the metric stays a support-only chore.