Average handle time tells you how much team effort one case consumes: reading the message, looking up information, writing the reply, then adding a note and changing the status. In chat it is easy to confuse with conversation length, because one agent runs several threads and customers reply with gaps. If you shorten the wrong number, you speed up closing cases rather than the work itself. This guide shows how to measure handle time on a sample and cut each part without making answers worse.
You do not need a dedicated metric in your tool: a spreadsheet, a few dozen finished cases and an honest split by case type are enough. How long a customer waits for the first reaction is a separate topic, covered in the guide to first response time in chat.
What counts as handle time for one case
Handle time is the sum of active work on a case, not the time between opening and closing a conversation. In chat it has three stages: reading and working out what the customer needs, writing the reply, and documenting it with a note, tag, status change or handover. Gaps while the customer searches for an order number are not agent work, even though they make the conversation longer.
Microsoft Dynamics 365 Customer Service documentation describes average handle time as the average active time of a closed conversation, and for voice it derives talk time by subtracting hold and after-call work. That is one product's definition, not an industry standard or a target value for your team. Microsoft Learn.
That is why an average of chat durations usually says little. Meetlead does not calculate a separate handle time metric, so you collect the baseline manually and treat the available response reports as background. How to count time to resolution while a case waits for the customer is covered in the guide to ticket resolution time.
Measure a sample by case type
An average across all cases mixes a question about opening hours with a complaint about a damaged parcel. Start with three or four types that together make up most of your contacts and measure each one separately. If you use tags, pick sample conversations by tag; if not, mark the type by hand in the spreadsheet.
- Choose the case types.Name them the way your team talks about them, for example order status, rescheduling or product fit.
- Agree the stopwatch rules.Count only the time an agent is actually working on that case. When they switch to another conversation, they pause the timer and resume it on return.
- Record three segments.For each case, note the minutes spent looking up information, writing the reply and documenting separately.
- Add the case outcome.Mark whether the case ended in this contact or needed a handover, and whether the customer came back with the same problem within your agreed window.
- Measure in an ordinary week.A week without promotions or holidays gives a fairer picture than one hand-picked day. After making changes, repeat the measurement with the same method.
Ask at least two people to take part, because the difference between them often reveals missing shared knowledge rather than who works more slowly. The results are not for rating staff. If the team believes otherwise, they will start shortening answers instead of work.
Split the time into research, writing and documentation
After a week you have three numbers per case type instead of one. A fictional bike parts shop shows that the same average can have entirely different causes.
Scroll the table sideways to see all columns.
| Part of the work | Symptom in the sample | First change |
|---|---|---|
| Looking up information | The agent asks for details the customer already gave or switches between systems | Customer context and case history inside the conversation view |
| Writing the reply | The same text is written from scratch several times a day | A macro with variables or a draft to review |
| Documenting | Decisions end up in a separate file or messenger | An internal note and tag on the conversation itself |
In the fictional shop, order status questions were mostly research, because tracking numbers lived in another system, while part-fit questions were mostly writing. Change one part at a time so the next measurement tells you what worked.
Cut research time: keep customer context in view
Most time disappears while an agent reconstructs the customer's situation: which page they are on, whether they wrote before and what they were promised. In Meetlead customer support the conversation, a preview of the customer's page, visit history and earlier tickets sit in one view, and the contact profile shows the customer journey across previous visits. Before asking a question, check whether the answer is already on screen.
The other half of research is company knowledge: return conditions, delivery times, exceptions. Collect answers to frequent questions in one current place and name the person who maintains them. With many parallel conversations, switching attention also stretches research; how many threads make sense is covered in the guide to concurrent chat limits.
Cut writing time: macros with variables and AI drafts
A macro saves time only when it fits the question and does not need half its text rewritten. In Meetlead, macros can be private or shared with the team, have categories and variables such as the customer's name or the agent's name, and show an editable preview before sending. The guide to customer service response templates explains how to build a solid structure.
Hi {{customer.name}}, I have checked order [NUMBER]: the parcel status is [STATUS] and the carrier expects delivery on [DATE]. If the address is wrong, send the correct one here and I will pass the change to our warehouse. Best regards, {{agent.name}}
When the answer depends on company knowledge rather than a single template, a draft helps. Copilot in the Meet AI app prepares a private suggestion based on the active knowledge base; the agent inserts it into the editor, edits it and only then sends it, because a suggestion never sends itself. For a message containing several questions, check that the draft answers each one, as described in the guide to several questions in one message.
Cut documentation: a note on the conversation instead of a separate file
Documentation grows quietly. An agent finishes the reply, then copies the outcome into a spreadsheet, messages a colleague and changes the status by hand. Record outcomes as an internal note on the conversation and tag the person who needs to check something with an @mention; they get a notification linking to that exact note.
A note should let the next person continue without questioning the customer again, so a short pattern works better than free text. You will find a ready layout in the guide to internal support notes. Repetitive follow-up actions can be added to a macro: a tag, a ticket status change or an assignment.
Make sure faster does not mean worse
Handle time can be cut in harmful ways: a shorter reply missing key information, closing a case before confirmation, or handing it over too early. The customer then comes back, and total work on the case grows even though a single contact looks faster. Alongside handle time, track the share of cases solved at first contact, explained in the guide to first contact resolution, and reopened cases. In Meetlead tickets, a new customer message reopens a pending or resolved case, so these returns show up on the event timeline.
- Handle time fell, and the share of cases solved at first contact did not drop.
- Customers do not return more often with the same problem within the agreed window.
- Replies built from macros and drafts still cover every customer question.
- Handovers to another person did not rise without a clear reason.
- You compare the same case type, measured with the same method.
If any item fails, roll back the latest change or narrow it to one case type. Saving fewer minutes while keeping quality beats showing a nicer average that your customers end up paying for.
Questions about chat handle time
What is a good handle time for one chat case? No single value fits every business, because a question about opening hours and a complaint require different work. Compare each case type with the same type in your previous measurement.
Do AI drafts always reduce handle time? Not always. A draft saves writing, but if the agent spends a long time editing it or checking its facts, the gain disappears. In your sample, record writing time separately for replies with and without a draft, and when the knowledge base lacks an answer, add it there instead of fixing every draft by hand.
