Agent Idle Time Audit Checklist: What Counts as Idle Time, How to Measure It, and Which Thresholds Are Acceptable

What counts as idle time and what does not

An agent's idle time is the period during which they are connected to the service tool but are not available to take new conversations and are not working on an existing conversation. It is not the same as being offline: an agent can appear as 'online' and still be idle if there are no messages to handle or if they are doing a task that is not customer service.

For the audit to be useful, you need to separate three concepts that are often mixed up: connected time (the agent has the session open), productive time (they are replying to messages, reviewing histories or following up on a case) and real idle time (there is no work available or the agent is not taking it). An agent can be connected for eight hours and have only four productive hours without that indicating a problem: it depends on the message flow, not just on the agent's willingness.

Legitimate idle time is considered to be: waiting for messages to arrive during a low-volume schedule, the time between closing one conversation and being assigned the next one, and scheduled breaks. Problematic idle time is considered to be: an available agent with conversations waiting without taking them, an agent who does not close resolved conversations and leaves them occupying their capacity, and long periods without activity during schedules where volume is high.

How to measure idle time: a four-step method

Measurement requires data that every WhatsApp service tool should be able to export or query: the timestamp of each message, the agent assigned to each conversation and the agent's status changes if the platform records them. If your tool does not export this information, the audit is limited to what you can reconstruct manually, and that changes the scope.

1. 1Define the analysis window: a full week is the reasonable minimum, because a single day has peaks and valleys that distort any conclusion. If the operation is seasonal, you need at least one week of high season and one of low season.
2. 2Calculate connected time per agent: add up the minutes between the first and last activity event of each day, subtracting registered breaks. If the platform does not record breaks, use periods without activity longer than 15 minutes as a probable break and note them separately.
3. 3Calculate productive time: add up the minutes in which the agent sent a message, received a message that they read, or was in an active conversation. The definition of 'active conversation' depends on your operation: for chat service, a conversation is active from the moment the agent opens it until they close it or transfer it.
4. 4Obtain idle time by difference: connected time minus productive time minus breaks. That number, divided by connected time, gives you the idle percentage of each agent and of the team.

The formula you can apply with your own numbers

The base formula is simple, but the devil is in what you count as productive. If your tool only records message sending, you will underestimate the productive time of agents who spend time reading histories or writing long responses. If it only records connection, you will overestimate productivity. That is why the formula has three variants depending on the data you have available.

If your tool does not record any of this, the audit becomes sample-based: choose three representative days, sit down with a stopwatch and record every activity change of two or three agents during their full shifts. It is hard work, but it gives you a floor of reality that no theoretical estimate can replace.

Reference thresholds by type of operation

There is no universal threshold of acceptable idle time. An agent handling complex technical support queries will have more writing and research time between messages, and that is not idle time even if they are not sending messages. An agent handling frequent e-commerce questions with quick answers should have low idle time during peak hours. The thresholds below are starting points for interpreting your measurements, not rigid rules.

The checklist to tick off during the audit

This list is meant for you to print or copy and tick off each point as the audit progresses. It is grouped by stage so you can divide the work among several people if needed.

Stage 1: Data preparation

• Define the analysis window (at least one full week, ideally two: one during normal season and one during peak season).
• Identify what data your tool exports: message timestamps, assigned agent, status changes, conversation open and close times.
• If status data is missing, define the probable pause criterion (for example, inactivity greater than 15 minutes without messages) and note it down to apply it consistently.
• Build a spreadsheet with one row per agent and columns for: connected time, productive time, pauses, idle time, inactivity percentage.
• Choose the peak and valley days and times of your operation based on message volume data, not intuition.

Stage 2: Measurement

• Calculate each agent's connected time per day, subtracting registered pauses or probable pauses according to the defined criterion.
• Calculate productive time using the formula variant that corresponds to your available data.
• Calculate the inactivity percentage per agent, per day, and per time slot (peak and valley separately).
• Record how many conversations were left waiting during each agent's inactivity periods. This is the data point that separates legitimate idle time from problematic idle time.
• Note atypical cases: agents with inactivity far above or far below the team average, and days with unexpected volume spikes.

Stage 3: Interpretation

• Compare each agent's inactivity percentage with the expected range for your type of operation in the thresholds table.
• Separate inactivity periods with conversations waiting from periods with no available work. Only the former indicate a management or attitude problem.
• Look at the distribution by time slot: high inactivity during valley hours is expected; during peak hours, it is not.
• Identify whether high inactivity is concentrated in specific agents or is widespread. If it is widespread, the problem is probably sizing or assignment flow, not people.
• Check whether agents with low inactivity show signs of overload: shorter responses, more transfers, more errors. Very low inactivity is also a finding.

Stage 4: Actions

• If you found high inactivity with conversations waiting, review the assignment mechanism: do agents see waiting conversations? Does the system assign them automatically or do they depend on the agent picking them up?
• If you found high inactivity without conversations waiting during peak hours, review sizing: there are probably more agents than necessary in that time slot.
• If you found low inactivity with signs of overload, review staffing upward or redistribute schedules.
• Document the thresholds you decide to adopt as a goal for your operation and schedule a re-measurement in 30 to 60 days to verify the effect of the changes.
• Do not use inactivity as an individual performance metric without considering the context of volume and assignment. It is a system metric, not a personal failing.

What to do when measurement gives strange results

Strange results are information, not errors. If an agent has 90% idle time during peak hours, something may be happening with conversation assignment (for example, new conversations always go to the same agents by connection order). If all agents have idle time close to zero, you are probably underestimating productive time because your tool does not record reading or typing, only sending.

When measurement contradicts what you see day to day, go back to the data source before drawing conclusions. A common mistake is using the record creation date instead of the message's actual timestamp. If your tool imported conversation history, the records may all be dated the day of the import and any analysis of schedules will give absurd results. Verify that the column you are using is the one that records when the event occurred, not when it was inserted into the database.

Limits of this methodology

This audit measures time, not quality. An agent can have perfect idle time within the thresholds and still give poor answers, and another can have high idle time because they take the time to research each case before responding. Idle time is a sizing and workflow metric, not a complete individual performance metric.

It also does not measure work outside the tool. If your agents handle phone calls, answer emails, or do administrative tasks in addition to chat, the time connected to the WhatsApp tool does not represent their full workday, and the thresholds in this guide do not apply directly. In that case, measure idle time only over the time dedicated to chat support, and clearly define what part of the workday corresponds to each channel.

Finally, the reference thresholds in the table are starting points. Your operation may have particularities that justify different values: extended support hours, very marked seasonal peaks, or a team that combines support with active selling. Use the thresholds to ask questions, not to punish.

Audit summary table