Average Handle Time, and Why It Falls When the Work Gets Worse

Average handle time is the total time your people spend working on tickets divided by the number of tickets they handled. On a phone that means talk time plus hold time plus the notes written afterwards. On an email desk it means the minutes actually worked on a ticket, which is a different thing altogether from how long the ticket sat there open.

That distinction sounds like a small piece of bookkeeping and it is the whole trouble with the metric. Handle time counts work. Nearly every figure anybody quotes as handle time counts waiting as well, on account of waiting being the part a computer can see without being asked, and once the two have been mixed together in one column of a spreadsheet there is no unmixing them later, truth be told.

We sell help desk software and it does not report this number at all, which we will come back to properly rather than leave sitting at the bottom of the page in small print. Worth saying up here all the same, since a page about a metric written by a company that sells you the metric is a page worth reading with one eye half shut.

What average handle time counts, and what it leaves out

It counts work and it counts nothing else, meaning the minutes somebody had the ticket open and was actually doing something about it, summed across however many sittings that took and then divided by the number of tickets handled in the period.

The metric came out of the phone world and it arrived with three parts already named. Talk time is the customer on the line with you. Hold time covers the stretch where they are still on the line and listening to music while somebody goes and finds out, which on a bad morning is the longer half. Then after-call work, and that is the 4 minutes afterwards spent writing down what happened, forgotten by nearly everybody who quotes this metric and frequently the biggest of the three. A call centre has all three of those measured for it by the phone system without anybody lifting a finger, and that is the reason the metric grew up there rather than anywhere else.

On mail there is a rough equivalent of each and it is a good deal messier. You read the thread and work out what is actually being asked, which is frequently not the thing that got typed. Then the finding, whether that means a search, a Slack message to somebody who knows, or 20 minutes inside a system that was never built for you. Writing the reply is the part everybody pictures and it is rarely the longest bit of the job. After that comes the admin, the tagging, the note to the engineer in Jira, the line in the CRM. Add the lot of it up honestly and you have got a handle time. None of it is complicated.

What it leaves out is every minute the ticket spent being nobody’s problem. The overnight, the weekend, the 2 hours it sat unassigned while everyone was in a planning meeting, the day and a half waiting on the customer to send the screenshot they were asked for. None of it is handle time and a great many desks report it as though it were, which is the single most common mistake made with this number and it is made in good faith every time, no two ways about it.

How to calculate average handle time when the unit is not a call

Add up the minutes worked across everything you handled in the period, then divide by the number of things you handled. That is the sum. There is nothing clever in it and the arithmetic has never been the hard part of any of this.

The hard part is the word “handled”, and the phone people never had to think about it, seeing as a call is one interaction and one piece of work and one unit all at once, so the question does not come up. Mail is not so tidy. A single ticket can carry nine replies over 5 days, going back and forth about a refund, and you now have to decide whether you are measuring the ticket or the reply, and the two answers are different numbers describing the very same desk.

Say your desk handles 2,000 tickets in a month and those tickets carry 6,200 replies between them. Divide the same pile of minutes by 2,000 and you get handle time per ticket. Do the division by 6,200 instead and what comes out is handle time per reply, roughly a third of the other figure, and there is nothing wrong with that one either, it is answering a different question is all. Both get called average handle time in reports, funnily enough, both get quoted at each other in meetings, and nobody goes and notices until two people are arguing about a figure and it turns out they were never discussing the same measurement in the first place.

Pick one. Write it on the report where the number appears. Then leave it alone for a year, on account of a unit that changes mid-year making every comparison you own worthless, and the change never gets minuted anywhere either.

Which clock is which on a single ticket

Three clocks run on one ticket and they answer three different questions. Most desks have got a name for all three, and shorten the first one to FRT, and only actually measure one of them.

Now the useful bit, which is the gap between the second row and the third. Take the whole of a resolution time and subtract the handle time out of it, and what is left over is waiting. On the email desks we have looked at, that leftover is nearly all of it. A ticket that took 27 hours to resolve might carry 14 minutes of actual work inside of it, and those 14 minutes are the only part anybody ever tries to shrink.

Which tells you where to go looking, mind you. If handle time is 14 minutes and resolution time is 27 hours, then getting your people to work 2 minutes faster does nothing whatever for the customer, and moving the ticket off somebody’s desk 4 hours sooner does a great deal. The clock at the front of the ticket has its own page as first response time, and the targets and the promises made about those hours belong to your SLA compliance policy, which we have set out separately. This page is about the 14 minutes.

The ITIL and wider ITSM crowd have a fourth clock, MTTR, which measures a service being broken rather than a person being unanswered. That is a different world from this one, though the warning about what a clock gets started on carries straight across to it.

Why a call-centre number does not survive the move to email

A call has two edges. It starts when somebody picks up and it ends when somebody hangs up, and the phone system stamps both of those without needing anybody’s cooperation, so the measurement is a fact rather than an estimate, plain and simple.

An email ticket has not got edges. It has got a person opening it at twelve past nine, reading half of it, going to Slack or Teams to ask a colleague whether this account is on the old plan, getting pulled into a stand-up, coming back at twenty to eleven, re-reading the whole thing from the top because the context is gone, and finally sending a reply at five to. So what did that ticket handle. It was open for an hour and forty three, the person was elsewhere for the most of it, they read it twice, and the second reading is real work that only happened because of the interruption.

Neither Gmail nor Outlook stamps a start and a stop on a piece of work, seeing as neither of them knows a piece of work was happening at all. There is no honest answer to that question and there is no system anywhere that produces one, ours included, and that is a thing we would rather have written down than left for you to find out. What there is instead is a set of stand-ins, and every organisation quietly goes and picks one and then stops mentioning that it picked.

What counts as handling, and what is the ticket sitting in a queue

Four stand-ins do the rounds, and it is worth knowing which one is behind your own number before anybody takes a decision off it.

Created to closed is the commonest of the lot, and it is not handle time at all, it is resolution time wearing the other one’s name, since it counts the overnight and the weekend and the wait on the customer. Then somebody suggests measuring from assignment instead, which is better and is still mostly waiting, on account of a ticket being assigned to a person the moment it arrives and then queueing behind everything else that person is holding. Closer again is the time a ticket spends sitting in an “open” or “in progress” status, and closer is not close, seeing as that one counts lunch along with the whole afternoon somebody went and left the thing open on a second tab while doing something else entirely. The fourth is a real timer that the agent starts and stops, accurate as anything and used by nobody past about week three, since it asks a person to do bookkeeping about their own work while doing the work.

So every email handle time is an estimate. That is not a failing of any one product, it is a property of the medium, and the honest move is to name the stand-in on the slide where the number appears rather than let a room assume it is a measurement. “Assigned to closed, business hours only” is a caveat that takes four words and saves an argument in March.

Fair is fair, there is one more option and hardly anybody takes it, which is to sample the thing by hand. Take 30 tickets, have the people who worked them note honestly what each one took, and settle for a rough figure off a small pile instead of a precise figure off a proxy that is measuring the wrong quantity altogether. It will not automate and it does not need to, seeing as 30 tickets is a Tuesday afternoon rather than a project.

Why the average falls fastest when the answers get worse

Now the part that matters more than the rest of it put together, and it is the reason we would put handle time near the bottom of any list of numbers to run a desk by.

Take one ticket, a genuine question that needs an answer with some thought in it. Done properly it takes 18 minutes. Somebody reads the whole thread, works out what the customer is actually after rather than what they typed, checks the account, writes a reply that closes the subject, and the customer goes away satisfied and does not come back.

Now do the very same ticket on a desk where handle time is the number on the wall. It gets 9 minutes. The reply is not wrong, it simply answers the question asked and not the question meant, which is a thing people go and do when they are being timed and it is not cheating, it is responding sensibly to what was asked of them. The customer comes back the next morning. That arrives as a new ticket, gets picked up by somebody else, and takes 11 minutes, a good chunk of which goes on reading the previous thread from the start of it.

Two tickets, 20 minutes of work between them, and an average handle time of 10. The number came down from 18 to 10, which reads as a 44% improvement on any dashboard you care to build. The desk did 2 minutes more work than it would have. The ticket count went up by one, which flatters the tickets-per-agent figure as well, so two numbers improved at once. And the customer waited an extra day.

Nobody in that story did anything wrong and nobody gamed anything, truth be told. Somebody asked for shorter, they got shorter, and the cost of it turned up on a number sitting on a different report that nobody happened to be watching that quarter.

Which number has to be read beside it

Handle time on its own is not a number anybody should be moving deliberately, and there are two or three others that want reading in the same breath as it.

The number that catches the trouble above is the reopen rate, meaning the share of tickets that come back after being closed, and beside it the count of second contacts inside 48 hours, which catches the ones that arrive as a fresh ticket rather than a reopen and are therefore invisible to the first measure. On most systems, ours as well, a customer replying to a closed thread the next day starts a new ticket, so the reopen rate on its own will tell you everything is fine.

Better again is contacts per issue, which is the total tickets divided by the number of distinct problems underneath them. Almost nobody computes it, on account of it needing somebody to look at the tickets rather than the report, and it is the truest number of the three, mind you. Two contacts to sort one problem is twice the work and twice the annoyance however brief each contact was. Twice the risk of a wrong answer as well.

Then read it beside CSAT as well, seeing as speed and satisfaction disagree with each other more often than the vendor blogs let on, and the full set of what else is worth watching sits on our page about customer satisfaction metrics. What we would keep in mind, rather than write up on a wall anywhere, runs roughly like this. Handle time falling while the reopen rate climbs has not improved anything, it has moved work from one place to another and counted it in the better place. Where the reopen rate holds and satisfaction holds and the handle time still came down, then something did genuinely get better, and it is usually the tooling or the knowledge behind the answers rather than the people, who were doing their best either way.

What a good average handle time is, and why there is no figure on this page

There is no figure on this page. Not because we could not find one, since there are plenty of numbers floating about with confident decimal places attached to them, but because a good handle time for your desk is a fact about your tickets rather than a fact about support.

Think about what goes into the average. A desk where 7 in 10 tickets are password resets and address changes will produce a small handle time, and a desk debugging integrations against somebody’s ERP will produce a large one, and both teams could be equally good or equally hopeless without the number moving to tell you which. What handle time measures, mostly, is the mix. It gets around to measuring the team only once you have held that mix still, and the mix never holds still for a good long while, seeing as a new release goes out and the questions go and change shape the same week.

That is why the direction is ambiguous too, and it is the only support metric we know of where the good direction is genuinely a question. First response time going down is good and there has never been an argument about it. Nobody has had to think twice about satisfaction climbing either. Handle time coming down might mean the knowledge base is finally answering things, it might equally mean the tickets got easier this quarter, and it might mean the answers simply got shorter, and the number on its own has no way of telling you which of the three it was.

So the only comparison worth making is your own desk against your own desk, quarter to quarter, with the mix checked before you draw any conclusion at all. And if somebody hands you a benchmark for your industry, ask them where the sample came from and how big it was, and watch how quickly the conversation turns into something else. We have kept to that rule across the whole of this site, and if we are being honest it costs us a nice quotable statistic every single time.

A Thursday in March, and the eleven minutes that were not real

Say the quarterly report lands and handle time has come down from 14 minutes to 11 across three months. That is a good-looking slide and, to be honest with you, there is a temptation to take it at face value, seeing as somebody has clearly been working on it and nobody wants to be the person picking holes in the one number that improved.

The check takes about an hour, and here is how it goes. Export the tickets to CSV, both quarters. Count them. In our invented case the count went from 2,000 to 2,600, which nobody went and flagged at the time, on account of more tickets closed reading as a good quarter as well.

Now multiply back out. The first quarter is 2,000 tickets at 14 minutes, so 28,000 minutes of work. The second is 2,600 at 11, so 28,600 minutes. The desk did 600 minutes more work in the quarter the number improved, which is 10 hours, which is more than a day of somebody’s life.

Then the part that settles it. Sort the second quarter by customer and by date, and count the tickets that arrived from the same customer within 48 hours of a previous one being closed. If that count went up by roughly the 600 tickets the volume went up by, then the problems did not increase at all, the tickets did, and each of those 600 customers had to come back a second time to get sorted out. Per actual problem the desk went from 14 minutes to 14.3. The per-ticket figure meanwhile went from 14 to 11, and both of those are correct arithmetic done on the very same tickets, which is worth sitting with for a minute before anybody picks which of them goes on the slide.

That is a Thursday afternoon with a spreadsheet and there is no cheaper quality check available to a support desk anywhere. It is also the check missing from every page we have read about how to reduce this number, which is the page nearly everybody writes.

Where the number genuinely earns its keep, which is the staffing sum

None of the above means throw it away. It means stop using it to judge people and start using it for the one job it is genuinely good at, which is working out how many people the queue needs.

The sum runs like this. 2,000 tickets a month at 14 minutes each is 28,000 minutes, which is 467 hours of work sitting in the queue. Then the other half of it, which desks get wrong far more often than the first half. A person on the desk does not give you 8 hours of ticket work in an 8-hour day. Between stand-ups, the mail that is not tickets, breaks, the training somebody booked, and the couple of minutes of nothing between one thing and the next, 5 hours of real ticket work day in, day out is a fair figure and some desks would call it generous, mind you. Across 21 working days that is 105 hours a month from one person. 467 divided by 105 is 4.4 people. Call it four and a half.

Now the bit worth the whole section. Suppose your 14 minutes was really 17, because the stand-in you used was undercounting the second and third sittings on a ticket. The same 2,000 tickets are now 34,000 minutes, which is 567 hours, which is 5.4 people. 3 minutes of measurement error went and moved the answer by a whole person, and a whole person is the sort of decision that gets made once a year and lived with for the rest of it. The money side of that same arithmetic is worked through separately as cost per ticket, since the hours are here and the money is there.

That is the honest use of it. Capacity questions will tolerate a rough number so long as the error bars get said out loud, and this is a capacity question. The place it goes wrong is somebody’s review. Put it on an individual scorecard and you have measured which tickets that person got handed, since the one who quietly takes the gnarly integration questions will look slow beside the one clearing address changes, and everybody on the desk will work out inside a fortnight that the way to a good score is to leave the hard ones for somebody else. Which is the opposite of what anybody wanted.

What our own dashboard reports, and the one number it does not

Plainly said, and up front rather than buried at the foot of the page. Maxdesk does not report average handle time. There is no timer on the ticket, there is no time-in-status report, and there is no handle time on the dashboard, so if you want this metric out of us today you are exporting to CSV or pulling tickets over the API and doing the arithmetic your own self in a spreadsheet.

What the dashboard over here does show is an average first reply, the open ticket count, how old the backlog is getting, and SLA breaches counted live. Your SLA policy holds two targets, both of them set by priority, one for the first reply and one for the resolve, and until you put your own numbers in it defaults to a first reply inside 1 hour with a resolve inside 8 hours. The countdown runs on the ticket its self, which means whoever is holding the thing watches the time go rather than reading about it in a deck a month later.

The things that genuinely move handling time are worth naming, and none of them are a report. A knowledge base with real answers in it goes and turns composing into finding, which is the biggest single lever there is and it is a writing job rather than a software one. Automation rules that tag, route and send the acknowledgement take the admin minutes off the top, and admin minutes are pure handle time with no customer value inside of them at all. The AI support agent sitting on Elite, which is the $99 tier, drafts a first version for a person to read over and correct before it goes anywhere, which is AI copilot behaviour, and the allowance up there covers 5,000 AI responses in a month spread across 2 agents. That does move handle time and does nothing whatever about whether the answer was right. Watch the reopen rate beside it for a month, the very same way you would watch it beside any other change.

One more thing about the bill, said once. Maxdesk charges per workspace rather than per agent, so the headcount that falls out of the staffing sum further up does not change what you pay us. Whether that is a point in our favour is your call, we simply would rather have said it than had you work it out.

The parts of this we would argue with ourselves

If a desk could keep only three numbers, handle time would not be one of ours. It would go first, ahead of the fancier ones, on account of it being the easiest to move in the wrong direction and the hardest to interpret once it has moved.

It cannot be measured properly on mail either, and we said so at length above rather than hiding it, and that applies to anything you build out of our own export just as much as to anybody else’s product. Nearly every figure in this business is a proxy carrying a caveat somewhere behind it, and the caveat goes and gets left off the end of it more often than not, ours included, which is a habit rather than a conspiracy.

Mail is also the only channel we ship. Somebody who rings up, or who walks over and asks you in person, leaves nothing behind here for anybody to put a clock against, so whatever handle time you get out of us covers the written half of your support and leaves the spoken half unmeasured entirely.

And the comparison problem has a plan-shaped edge to it, which is fair to flag on our own page. Handle time is only readable against the same desk’s earlier handle time, so the length of your history window is the length of the comparison you are allowed to make. On the free workspace that window runs 3 months, which gets you last quarter and no further. Pro at $20 a month holds 12, Elite at $99 holds 24, and it is 24 that lets you ask whether the same March is busier than the March before it. The free plan also runs supporting ads, puts our name on outgoing mail, and caps how many automations you can have switched on at once. Those plan figures were right as of 31 August 2026, and we have put a re-check of them in the diary for January 2027.

Under about four people none of this applies. A desk of three already knows which tickets are eating the week, on account of them saying so out loud to each other by about Wednesday, and they know it their own selves more accurately than any report would put it, and the hour spent building the report is an hour not spent answering anybody.

How to get an honest handle time out of a desk with no timer

Five steps, one week, no project plan and no budget. Do the lot of them in order.

1. Pick the unit and write it on the report. Per ticket is the sensible default; per reply is defensible; mixing them is not.
2. Take one ordinary week rather than a quarter, since a week you can check by hand and a quarter you can only trust.
3. Sample 30 tickets across the whole spread of what you handle, easy and hard both, and have whoever worked them note the real minutes including the second and third sittings.
4. Work out resolution time on the same 30 tickets, subtract the handle time, and look hard at what is left over, because that leftover is where the customer's wait actually lives.
5. Before you celebrate any drop at all, count the tickets that arrived from the same customer within 48 hours of a close, both this period and the last one.

The fifth one gets skipped more often than the other four put together. It is also the only step that would have caught the trouble in the quarter further up this page, so if the week is tight, do that one and leave step three for another time.

Common questions about average handle time

What is average handle time?
Average handle time, or AHT, is the total time your team spends actively working on tickets divided by the number of tickets handled in the same period. On a phone it is talk time plus hold time plus after-call work. On an email desk it is the minutes actually worked on the ticket, and it does not include the hours the ticket spent waiting in a queue or waiting on the customer.

How do you calculate average handle time?
Add up the minutes worked across every ticket in the period and divide by the number of tickets handled. The trap is the unit: a ticket can carry many replies, so dividing the same minutes by tickets and by replies gives two different numbers that both get called average handle time. Pick one, print it beside the figure, and do not change it mid-year.

What is a good average handle time?
There is no useful cross-industry figure, because handle time is a property of your ticket mix rather than of your team. A desk doing password resets will always beat a desk debugging integrations, and neither number says anything about either team. Compare your own desk with itself quarter to quarter, and check the mix has not changed before drawing a conclusion.

What is the difference between average handle time and resolution time?
Handle time counts only the minutes somebody was working on the ticket. Resolution time counts everything from arrival to close, including overnight, weekends and waiting on the customer. On most email desks handle time is a small fraction of resolution time, so a ticket resolved in 27 hours might contain 14 minutes of work.

Does lowering average handle time hurt customer satisfaction?
It can, and the mechanism is specific. Closing early splits one problem across two tickets, so each ticket looks shorter, the ticket count rises, and the average falls while the customer waits an extra day. Always read handle time beside the reopen rate and the count of second contacts within 48 hours.

Does Maxdesk report average handle time?
No. There is no timer on the ticket, no time-in-status report and no handle time figure on the dashboard. Maxdesk reports an average first reply, open ticket count, backlog age and live SLA breaches. To get a handle time today you would export to CSV or use the API and work it out yourself.