Want help applying this guide?Ask the DripTell team
An agent answers a customer, then spends six minutes in another chat before returning. A dashboard may call those six minutes inactive. That does not automatically mean the agent was idle, distracted, or avoiding work.
Inactive time in customer support is the period when a conversation remains open but the agent is not actively focused on it. In digital support, that can happen because the agent is serving another assigned customer, researching the answer, waiting for the customer, or dealing with a routing or notification problem. The number becomes useful only after you identify which of those situations occurred.
Inactive time is not idle time
Microsoft defines average conversation inactive time as time when an open conversation is not the agent's current focus, especially when an agent switches between concurrent chat or messaging sessions. Its conversation metrics documentation also separates active time by session participant. That distinction matters. A conversation can be inactive while the employee is actively helping someone else.
Idle time usually means an available person has no assigned work. Inactive conversation time belongs to a conversation, not to the person's whole shift. Treating the two measures as synonyms turns a routing signal into a performance accusation.
Customers care less about the internal label than what they were told and when useful help resumed.
Start with the event clock
Do not begin with the daily average. Reconstruct a few long inactive intervals from event data. You need the last customer message, the last meaningful agent message, changes in assignment or status, other conversations accepted by the agent, and the next useful action.
- 1Define the clockUse the last useful customer and agent events rather than automatic acknowledgements.
- 2Find the next actionSeparate customer waiting from an agent, internal dependency, or system delay.
- 3Match the workloadCompare the interval with accepted sessions, work complexity, and concurrency settings.
- 4Review the tailInspect the longest waits by channel, queue, shift, and work type instead of one mean.
- 5Fix the causeRepair routing and capacity first, then coach only when the system evidence supports it.
An automatic acknowledgement or repeated holding message does not prove progress. The clock should show when someone read, investigated, answered, reassigned, or asked for information.
| Observed pattern | What it may mean | Evidence to check | Safer action |
|---|---|---|---|
| Inactive time rises when concurrent work rises | The workload limit may be too high | Accepted sessions, focus changes, reply gaps | Test a lower concurrency limit |
| The customer's last message promises more information | The customer may hold the next action | Last speaker, requested evidence, follow-up time | Use a waiting state with a clear reminder |
| Inactivity begins after assignment | The agent may not have seen or accepted the work | Offer, acceptance, notification, and presence events | Repair routing or alerts before coaching |
| A few complex cases create most of the delay | Research or approval may be the constraint | Case type, internal dependencies, status updates | Add expertise or a visible escalation path |
This view is more honest than ranking agents by one average. It shows whether the remedy belongs in workload design, communication, system reliability, or coaching.
Find out whose turn it was
Every long pause should answer a simple question. Who had the next action?
If the customer was gathering a receipt, testing a fix, or waiting until they could reply, the conversation was open but the agent may not have been able to move it forward. A defined waiting state prevents that time from looking like silent neglect. The policy should say what the customer was asked to do, when the team will check again, and what happens if no reply arrives. The same discipline applies when deciding whether to pause a support SLA while waiting for a customer.
If the agent held the next action, ask what blocked it. They may have been researching, waiting for an internal owner, handling another assigned chat, or unaware that the conversation had returned. Those causes require different fixes.
Concurrency changes the meaning
Digital messaging is often designed for parallel work. Microsoft documents capacity profiles that define the amount and type of work a representative can take, including concurrent limits and whether one channel affects another. Concurrency is a system configuration, not a personal habit.
Some inactive time is therefore expected. Ask whether the workload creates unsafe reply gaps or lost context. Compare intervals with conversation capacity assumptions, accepted sessions, and work complexity. A password reset and a disputed invoice do not consume the same mental capacity merely because both arrive as messages.
Review the upper tail, not only the average. Two teams can share the same mean while one delivers predictable short pauses and the other leaves a small group of customers waiting far too long. Segment by channel, queue, work type, shift, and concurrent load before drawing conclusions.
Correct the system before coaching the person
When inactive time is high, check the operating system in this order:
- Confirm that assignment and notification events were delivered.
- Compare accepted work with the configured concurrency limit.
- Check whether the conversation was waiting on the customer or an internal dependency.
- Review whether ownership changed without a clean handoff.
- Read the actual conversation before discussing individual performance.
Related metrics complete the picture. An availability audit shows whether someone could receive work. Next reply time shows the customer's wait between messages. Average handle time shows active work and wrap-up. Review workload distribution too. No measure should stand alone.
If an agent repeatedly misses visible work while capacity is reasonable and notifications are healthy, coaching may be appropriate. But coaching is the final branch of the investigation, not the first.
Keep the customer promise visible
The best control is not a lower inactive-time number. It is a clear promise. Tell the customer when the team is researching, when another specialist owns the next step, and when they should expect an update. Do not send empty messages merely to reset a timer.
In a shared inbox, the practical requirement is simple: the current owner, waiting reason, next action, and promised update should be visible to the next person. That preserves continuity even when an agent moves between concurrent conversations.
Inactive time is therefore a diagnostic clue. Use it to find waiting, overload, missing context, or broken routing. Do not use it as shorthand for effort.
Frequently Asked Questions
Is inactive time the same as agent idle time
No. Inactive conversation time describes an open conversation that is not the agent's current focus. The agent may be actively working on another assigned conversation.
Should lower inactive time always be the goal
No. Forcing constant activity can create rushed answers and pointless holding messages. The goal is a reasonable, explained wait with reliable ownership and follow-up.
How should inactive time be compared across channels
Compare channels separately and account for their concurrency rules, customer response patterns, case complexity, and expected service promise. A voice call and an asynchronous message should not share one threshold.
When does high inactive time justify coaching
Only after routing, notifications, workload, waiting states, dependencies, and conversation evidence have been checked. If the system is healthy and visible assigned work is repeatedly missed, individual coaching can then be fair.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy