Want help applying this guide?Ask the DripTell team
Customer support occupancy is the share of queue-ready time spent doing customer work. Measure active customer work against active work plus ready waiting time, within the same interval and work type. Do not divide by the whole paid shift, and do not use the result as a personal productivity score.
That distinction matters in messaging. A conversation can remain open for four hours while the customer is away, yet require only twelve minutes of real work. Another agent may handle two live chats at once. If the clock is vague, a precise-looking percentage will still be wrong.
Define queue ready time before the formula
Start with the denominator. Queue-ready time is the period when a person is logged in, available to receive the relevant work, and not assigned to an off-queue duty. Active customer work and ready waiting time belong inside it. Breaks, leave, training, team meetings, coaching, planned project work, and confirmed system downtime do not.
- 1Fix the ready denominatorInclude active work and ready waiting while excluding documented off-queue duties.
- 2Mark customer workCount only activity that directly advances, completes, or safely hands off a customer need.
- 3Allocate concurrency onceNever count the same minute separately for every simultaneous message thread.
- 4Read useful intervalsExpose peaks and quiet periods before relying on a weekly average.
- 5Check customer outcomesRead occupancy beside waits, resolution, repeats, quality, and backlog age.
Microsoft's historical agent dashboard separates active and inactive session time and reports available, busy, away, and offline durations. Your event names may differ, but the boundary between queue-ready and off-queue time should be equally explicit.
Count work that directly advances a customer need. That can include conversation time, necessary research, collaboration, and case notes required to complete or hand off the work. A general knowledge-base rewrite may improve service later, but it is planned off-queue work for this measure. Write these state definitions into the team’s conversation status policy before producing a dashboard.
The working formula is simple. Occupancy equals active customer work divided by active customer work plus ready waiting time. Keep the numerator and denominator visible beside the percentage so a changed status rule cannot hide behind the result.
Messaging work needs an active time rule
Calendar-open time is rarely a fair messaging numerator. A customer may take an hour to send a document. An agent may answer another conversation during that gap. Measure active effort through reliable work events, a defensible activity timer, or a short work-sampling study. Never count the same minute once for every concurrent chat.
Choose one concurrency rule and test it against real histories. You might allocate an active slice to the conversation receiving the work, or measure the agent’s combined messaging effort at queue level without forcing every minute into a case. What matters is that total allocated work cannot exceed the actual queue-ready time in that interval.
Keep occupancy separate from average handle time. Handle time asks how much working time a contact consumed. Occupancy asks how much of the team’s ready capacity was occupied. One can rise while the other falls when arrival volume, concurrency, or staffing changes.
Read short intervals before a weekly average
A weekly average can hide a punishing lunch peak and a quiet afternoon. Calculate occupancy in intervals the operation can act on, often thirty or sixty minutes for a messaging team. Then show the distribution across intervals, not only one blended mean.
Segment where the work behaves differently. Voice, live chat, and asynchronous messages should not share one denominator unless the same people truly move between them under a documented capacity rule. Split specialist queues when complexity or permissions materially change the work. Keep volume beside every result in the inbox reporting view.
| Observed pattern | Customer evidence | Likely operating question | Safer response |
|---|---|---|---|
| High occupancy and rising wait | Older unowned work or missed response promises | Is demand above available coverage in this interval | Add coverage or move planned work, then recheck |
| High occupancy and more repeats | Reopens, repeat contact, or weak quality findings | Are people rushing or losing wrap-up time | Protect completion work and review affected cases |
| Low occupancy and long wait | Ready time exists while work remains queued | Is routing, presence, or assignment data wrong | Repair the queue rule before changing staffing |
| Large peaks hidden by a normal week | A few overloaded intervals | Does the schedule match the arrival pattern | Use the volume forecast to change overlap |
| One person stays much higher | Harder case mix or manual overrides | Is assignment fair and comparable | Review the workload policy rather than ranking people |
The table is a diagnostic map, not proof of cause. Read several signals together and inspect a representative sample before acting.
Use occupancy to fix the system
Occupancy is most useful at queue and interval level. It can reveal a schedule mismatch, too little recovery space, excessive wrap-up, broken routing, or a channel that consumes more attention than its case count suggests. It becomes dangerous when leaders turn it into a target for every person and every hour.
Microsoft’s capacity profile guidance recognizes that work differs by complexity and channel, that capacity may be concurrent or daily, and that some channels should block extra assignments. It also explicitly warns against using the feature for employment decisions. That is the right posture for occupancy data too.
Do not copy a universal benchmark. First build a trustworthy baseline for each work class. Pair it with response wait, verified resolution, repeat contact, transfers, quality findings, backlog age, and schedule adherence. If occupancy rises while outcomes stay stable after a genuine demand increase, the staffing question differs from a rise caused by bad status data.
Run a two week measurement test
Pick one queue. Agree on ready, active, and off-queue states. Audit twenty recent conversations, including customer-away periods, concurrent chats, escalations, and required wrap-up. Then calculate interval occupancy for two weeks without setting a target.
During the review, ask where the number disagrees with observed work. Fix missing events and unclear states first. Only then compare occupancy with waits, repeats, quality, and the forecast. The first useful decision may be a schedule change, a routing repair, protected documentation time, or no change at all.
In the DripTell team inbox, ownership, status, channel, history, and internal notes stay beside the conversation. Those records can support a cleaner measurement model, but the policy still comes first. A dashboard cannot decide which minutes truly represented customer work.
Frequently Asked Questions
What is the customer support occupancy formula?
Divide active customer work by active customer work plus ready waiting time for the same queue, work class, and interval. Exclude time when the person was not available for that queue.
Is high occupancy always bad?
No. A short, expected peak can be manageable. Sustained high occupancy becomes concerning when waits, repeat contact, quality problems, missed work, or team strain also rise.
Should occupancy be measured for each agent?
Individual data can help audit state accuracy or understand case mix, but it should not become a ranking or employment score. Make queue and interval patterns the main operating view.
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