Support metrics

First Response Time, and Why the Average Is Not What Anybody Waited

31 Aug 2026·15 min read

First response time is the gap between a customer’s message arriving and a person replying to it. Not the automatic acknowledgement, a person. You work one out by taking the arrival time off the time of that first human reply, and you get the desk’s figure by averaging them all together, and it is that last step where nearly every desk we have looked at goes and loses the run of the thing.

Because an average is one number and a queue is not one number. A queue is a spread, a long uneven scatter of waits running from a few minutes at one end to most of a morning at the other, and the second you flatten that into a single figure for the top of a slide you have thrown away the only part of it any customer ever actually experienced. Nobody decided to do that, mind you. It is simply what averaging goes and does, and there is no warning label printed anywhere on the report to tell you, and that is the most of it.

We sell help desk software, so weigh the rest of it accordingly. And no two ways about it, our own dashboard reports this very number in the same flattened way as everybody else’s, which is a thing far better said up here at the top than discovered by you somewhere down the far end of the page.

What first response time actually measures

Two timestamps and a subtraction, and the entire argument lives in which two you went and picked.

The first one is easy enough and hardly anybody gets it wrong, truth be told. The clock starts when the message lands, meaning the moment it arrives in the mailbox, not when somebody opens it, not when it gets assigned to a person, and certainly not when whoever is on the desk that morning gets down that far in the pile. The second timestamp is the one that goes and undoes the whole of it. That one is meant to be the moment a person said something back to the customer, and on a great many desks it is quietly the moment the system said something back instead, and those two are not the least bit the same measurement even though they sit in the same column of the same report with the same heading over them.

You will also see this called first reply time, or shortened to FRT in a report, and there is no difference worth arguing about between the two names. Some tools say response, some say reply, and both mean the gap at the front of the ticket. What they do not always mean is the same thing about what qualifies as one, which is the part of it worth your attention.

What counts as a first response, and what does not

An acknowledgement is not a response, mind you, though your reporting will happily take it as one if you let it.

Say a customer writes in at half nine and gets a mail back at half nine saying thanks, we have your message, somebody will look at this shortly. That is a genuinely useful thing to send and we would not talk a single person out of sending it, on account of a customer who knows they have been heard waiting far better than a customer shouting into nothing. What it does not do is answer them. And if it stops the clock, then your first response time is measuring the speed of your mail server, which is a number somewhere under a second, and which has nothing whatsoever to do with your desk nor the people sat on it, none of it.

The very same goes for the canned reply that fires off a rule, and for the bot that offers a knowledge base article before handing over to a human, and for the internal note somebody leaves on the ticket for a colleague. That last one catches people out more than you would think, seeing as it looks exactly like a reply in the ticket history, sat there in the same thread with a timestamp and an author on it, only the customer never saw a word of it and never will.

So the rule worth having is the plain one. The clock stops on the first message a person wrote, that went to the customer, that was about the thing they wrote in about. Everything else is furniture, mind you. Set it up that way once, at the start, and the number you get back will be worse than the one you have now, and it will be the first honest version of it you have ever had in front of you.

How you work out first response time

The arithmetic is not the hard part of it and it never was, though it is worth writing down plainly because three of these four get skipped.

What you are working outThe sum
One ticket's first response timetime of the first reply a person wrote, minus the time the message arrived
The desk’s mean (the average)all the first response times added up, divided by the number of tickets
The medianthe middle value once you have sorted them smallest to largest
The 90th percentilethe value that 9 tickets out of every 10 came in under

Nearly everybody works out the first two. Almost nobody works out the second two, and the second two are the ones your customers are actually living inside of. That is the whole of this page, truth be told, and the rest of it is just showing you the shape of what gets lost in between.

Why the average is the wrong number to be reporting

Take ten tickets off an ordinary morning and line up what each of them waited. Made-up figures, mind you, though the spread across them is the ordinary sort you would find on any desk, and every step of the sum below is yours to check your own self.

Ticket, sorted by waitFirst response time
14 minutes
26 minutes
37 minutes
49 minutes
511 minutes
613 minutes
718 minutes
826 minutes
994 minutes
10222 minutes
Mean41 minutes
Median12 minutes
90th percentile94 minutes

The report says 41 minutes. Not one single customer waited 41 minutes. The nearest anybody came to it was the one who waited 26, and after that the next person up the list waited 94, which is more than twice the figure sitting on your slide. Eight of the ten were answered inside half an hour and would tell you the desk is quick if you asked them. Two of them waited more than an hour and a half, and one of those waited 222 minutes, which is 3 hours and 42 minutes of a working day, and it is those two who are going to remember the morning.

So the mean went and got dragged upwards by the two long ones and it now describes nobody at all. It is not wrong exactly, it is just not about anybody, and a number that is not about anybody is a poor thing altogether to be steering a desk with. The median says 12 minutes, which is the honest answer to what a typical person waited. Then the 90th percentile puts 94 minutes on what a bad morning actually looks like from where the customer is sat. You want the pair of them, and you want them sitting next to each other, on account of the gap between the two being the actual thing you are managing.

The part of it that costs money is that those three numbers move independently of one another. Put an extra person on the early shift and the median goes and drops nicely, on account of the easy mail getting cleared faster, while the two hard tickets at the bottom of the list wait exactly as long as they waited before, seeing as what held them up was never staffing at all, it was that nobody on the shift could answer them. Your average improves. The slide looks better than it did last quarter. The two people who had the worst morning of anybody had precisely the same morning they would have had otherwise, and nothing anywhere in your reporting will ever go and tell you that.

What counts as a good first response time

We are not going to print an industry average at you, and it is worth saying why rather than just leaving the section out.

Every benchmark figure you will read on this subject traces back, if you follow it, to a vendor’s own customer data or to a survey with no published sample, and it gets quoted onwards by everybody until it goes and stops having a source at all and starts being simply a thing that is known. We have gone looking for one we could stand over more than once and we have not found it, and that is the honest part of it. So there is no band on this page. We did the same on our page about customer satisfaction metrics and we would sooner keep being unhelpful in that particular direction than hand you a figure that would not survive somebody asking where it came from.

The benchmark that actually works is your own last month, and it is better than a borrowed one in every way that matters. Work out your median and your 90th percentile over the last four weeks, write both of them down, and that is your baseline. A target set off that is a target about your desk, with your queue and your staffing and your kind of customer sat inside it. Lift one off somebody else’s blog instead and you are managing to a company you have never met.

The only other thing worth saying about good is that it is relative to what the person is waiting on. 9 minutes on a password reset is slow, seeing as the answer is written down already and the person is locked out and sat there waiting on you. A complicated billing dispute answered in 9 minutes is frankly excellent and nobody was expecting it. One average sitting over the top of both of those is telling you very little, which is why cutting the number by what the ticket was about is worth more than tightening the target on all of them together, and we walked through how the priority got set on a separate page.

How the number gets better while the desk gets worse

Nobody cheats at this. That is what makes it worth a section, on account of every one of the four coming about by somebody doing a sensible thing on a Tuesday.

The first is the acknowledgement, which we have already been through, and it is the big one. Switch on an auto-reply in Gmail or Outlook on Monday and your first response time on Tuesday goes and drops under a minute, and you have not answered a single person faster than you did the week before. It is not even that anybody is trying it on. Somebody turns on a useful feature and the report goes and rewards them for it.

Business hours are the next one along. A clock set to run 9 until 6 on weekdays is running 45 hours of the 168 in the week, which is the sensible way to set it and is what more or less everybody does, and it does mean the mail that lands at ten past six on a Friday is recorded as a short wait and experienced as a long weekend. Narrow the window further and the number improves again, mind you. That argument is made properly over on SLA compliance, so we will leave it sitting where it is.

Then there is the denominator, which is the quiet one of the four. Spam, duplicates, out-of-office bounces and the mail that arrives already answered are all tickets as far as the count is concerned, and they all get closed in seconds, and the lot of them drag your average down while representing nobody at all who was waiting on anything. A desk that gets a rough fortnight of duplicate mail after an outage can post its best first response time of the year off the back of it, and the report will not carry a single word of explanation as to why.

And the fourth is the one this whole page is about. Report the mean when the median is what moved, or the median when the tail is what moved, and you can show improvement in a quarter where the people who waited longest waited longer than ever. The two numbers do not disagree because either of them is lying to you. They disagree on account of them only ever answering two different questions, and the desk gets to pick which question goes on the slide.

Half nine on a Wednesday, and where the long waits came from

Say a shipping integration goes odd overnight. Not dramatically, orders just stop confirming for a share of customers, and by half nine you have a queue with twenty two mails in it and they keep arriving while you read.

Most of them are the same mail. Where is my confirmation, I paid, nothing came. Whoever is on the desk answers those quickly and correctly, one after another, because the answer is the same answer and it is written down already, and inside forty minutes eighteen of the twenty two have had a proper reply from a person. That is a good morning’s work and it deserves to be counted as one.

The other four are not that. One customer’s order confirmed and then charged them twice. There is a business account wanting to know whether their whole batch went through. Then somebody perfectly polite has asked a question about tax that nobody on the desk has ever been asked in their life, and the last one is furious in a way that wants reading twice before anybody replies to it. Every one of those needs somebody who is not currently on the desk. So they sit. They go and sit through the morning while the easy eighteen get cleared, and they sit while the person who could answer them is in a meeting about the outage, and two of them are still sitting there at lunchtime.

Your mean for that morning lands somewhere pleasant, on account of eighteen quick ones outvoting four slow ones every time. Your median lands lower still and looks genuinely excellent. And your 90th percentile, the one nobody printed, is sitting up around 3 hours where the four hardest tickets of the day are. Nobody did a thing wrong. The desk worked the queue in exactly the order a sensible person would work it. It is only that the report of it describes the eighteen and says nothing at all about the four, and the four are the ones who will be telling somebody about this next week.

The bit where we have something to sell you

Maxdesk is ours, and what it does is take the mail landing on one support@ address and make a queue out of it, with a shared inbox so nobody is guessing who picked up what, and an SLA policy holding a first response target and a resolution target apiece by priority. The part of that which genuinely moves a first response time is not the policy though, it is the place the countdown lives, and ours sits on the ticket in front of whoever has it open rather than in a report read on a Friday afternoon. A target nobody can see until the month is over does not change what anybody does on a Tuesday. It arrives set at 1 hour for a first reply and 8 hours to resolve, defaults you will want to move once you know your own week, and they do at least mean something is being measured before anybody has configured a single thing.

The rules that route and tag are the other half of it, on account of most of what makes a long wait long being a ticket sitting with somebody who cannot finish it, and routing it correctly the first time takes more minutes off the front of a ticket than hurrying anybody ever will.

The bill lands on the workspace instead of on the heads, and that is the thing we are genuinely different about. There is a free tier which carries ads and our own branding on the mail going out, and keeps your history back 3 months, and there are two paid ones above it, and on not one of the three does anybody anywhere count how many of you there are. The plan figures move about between currencies and packages, so take them as of the day you read them off our own pricing page rather than off a blog post. Which matters on this particular page a good deal more than it reads like it does. Go back to those four hard tickets sitting in the Wednesday queue. What they needed was never speed, it was one more person with the answer in their head, and on a per-head licence that person arrives at the meeting with a price tag on them and the conversation about adding them goes an entirely different way.

What a first response time will not tell you, said plainly

Start with our own, since it is the one we are responsible for. The Maxdesk dashboard reports an average first reply, next to open tickets and how old the backlog has got. An average. Not a median. There is no 90th percentile in there either, and nothing at all splitting the number by what the ticket was about. So a page that has spent this long telling you the mean is the weakest of the three is a page written by people whose own product currently shows you the mean, and if you want the other two today you will be exporting your tickets to a CSV, or pulling them over the API, and working them out your own self in a spreadsheet. That is the honest state of it and we would rather write it down here than have you go looking for the feature.

It also tells you nothing whatever about whether the reply was any good. A fast wrong answer scores beautifully on this number and badly on every other one you have, which is why it wants reading beside your CSAT and the rest of your customer satisfaction metrics rather than on its own. It says nothing either about how long the answer took to write, which is average handle time, or AHT, and a different page again.

And it stops where the first reply stops, which leaves the second wait entirely uncounted, meaning the gap between being answered and being sorted out. That is frequently the wait a customer would actually describe if you asked them, and it is a different page.

The last one is ours as well, and fair is fair, we may as well say it plainly. Mail is the only road we read. A question asked on the phone or across a desk carries no clock with us and none anywhere else in your building either, so a first response time out of here is describing the written part of the promise and nothing at all besides it. Worth knowing which part that is before the figure goes into a board pack.

Where to start, if the average looks fine

Export one month of tickets, and only one month, and only the closed ones so you are not measuring waits that have not finished yet.

Sort them by first response time, longest at the top. Then read the top tenth of that list, just read them, one after another, and do not do any arithmetic at all for the first pass. Nearly everybody who sits down and does this turns something up in the first 20 minutes of it, and what turns up is rarely the thing they went in braced for. The long ones tend to have something in common, and the something is rarely that the desk was busy. It is one type of question. Or it is one customer, always the very same one. Or there is one hour in the week where the only person who could have answered was never sat there to begin with.

Then work out the median and the 90th percentile for the whole month and put them beside the average you have been reporting. If the three of them sit close together your queue is an even one, and there is nothing further on this page you need. If the 90th is several times the mean, then the shape of your desk is a long thin tail, and the work in front of you is down at that end of it rather than in the middle where you have been looking all along.

Common questions about first response time

What is first response time in customer service?
It is the gap between a customer’s message arriving and the first reply a person sends them about it. Automatic acknowledgements, canned rule-based replies and internal notes do not count, even though many desks let them stop the clock without meaning to.

How do you calculate first response time?
For one ticket, subtract the time the message arrived from the time of the first human reply. For the desk, add all those gaps together and divide by the number of tickets for the mean, or sort them and take the middle value for the median.

What is a good first response time?
There is no benchmark worth quoting, because the widely repeated figures trace back to vendor samples that are never published. Use your own median and 90th percentile from the last four weeks as the baseline, and set the target from those.

Is first response time the same as first reply time?
Yes, the two names describe the same measurement and tools use them interchangeably. What differs between tools is what each one accepts as a response, so check whether auto-replies and internal notes stop the clock before comparing any two figures.

Why is my average first response time different from the median?
Because a handful of very long waits drag the mean upwards while leaving the median alone. On ten tickets waiting 4, 6, 7, 9, 11, 13, 18, 26, 94 and 222 minutes, the mean is 41 minutes and the median is 12, and nobody at all waited 41.

Does an auto-reply count as a first response?
No, and letting it count is the single most common way this metric gets broken. If the automatic acknowledgement stops the clock, the number you are reporting is your mail server’s speed rather than your desk’s, and it will read as under a minute forever.