Zendesk agent occupancy report for chat and messaging

Agent utilization is helpful for ticket-based work, but live channels need a more specific lens. Chat and messaging teams can look efficient on paper while still feeling overloaded because the real constraint is how much live work agents are carrying at once. That is what occupancy helps you see.

This guide explains how to think about agent occupancy in Zendesk, how to report it with the data you have, and how to use it without confusing “busy” with “healthy.” For the larger support review structure, see the support metrics dashboard.

What occupancy means

Occupancy is the share of an agent’s available time that is consumed by active customer work and the wrap-up that follows it.

In practice, teams usually define it like this:

Occupancy = (Active handling time + after-work time) / staffed live-support time

The exact fields vary by Zendesk product, plan, and whether you use messaging, chat, or voice. The core idea stays the same: how much of the shift was spent actively handling live interactions?

Occupancy is related to agent utilization but not identical. Utilization can include broader support work across tickets and queues. Occupancy is mainly about live-channel load.

Why occupancy matters for chat and messaging

Live channels fail differently from email queues.

Over-occupancy means agents have no recovery time, concurrency gets sloppy, and customer experience drops fast.
Under-occupancy may mean overstaffing, low demand, or poor routing into the live channel.
Stable occupancy with rising wait times often means concurrency settings or routing rules are wrong, not just staffing.

If your team handles synchronous work, occupancy belongs next to first response time and channel-level backlog signals. See Zendesk channel performance report.

What a useful occupancy report looks like

Your first report does not need to be perfect. It should answer:

What was occupancy by hour, day, and week?
Which teams or agents were consistently overloaded?
Did occupancy spikes line up with slower replies, longer handle time, or lower CSAT?

Useful views include:

Hourly occupancy by channel - shows peak periods clearly
Occupancy by team or skill group - shows where coverage is thin
Occupancy trend over time - shows whether staffing kept pace with demand
Occupancy against response time - shows when busyness started hurting service

How to build it in Zendesk

The exact setup depends on whether your live work sits in Zendesk messaging, chat, or talk. Use the dataset that contains interaction handling time and agent activity.

Step 1: Identify the time basis

Choose the staffed time you want to compare against:

scheduled live-support hours
logged-in available hours
staffed hours minus meetings, training, and offline work

Be explicit. Occupancy changes a lot depending on whether the denominator is the whole shift or only the portion reserved for live queue coverage.

Step 2: Measure active work time

Look for the time spent:

handling active chats or conversations
in wrap-up or after-conversation work
optionally in concurrent message handling if your product exposes it

If Zendesk gives you multiple status buckets, combine only the ones that represent real customer work. Do not include idle or away status.

Step 3: Calculate occupancy

Once numerator and denominator are aligned:

Occupancy % = active work time / staffed live-support time

Trend it by hour and by team first. Per-agent views are useful later, but team-level patterns usually reveal the staffing problem faster.

Step 4: Pair it with outcome metrics

Occupancy is most useful when read beside:

first response time
resolution time for follow-up work that starts in live channels
average handle time
CSAT or conversation satisfaction where available

An occupancy number alone is not the story. The story is what happened to speed and quality when occupancy changed.

How to interpret occupancy bands

There is no universal threshold, but these rules help:

Too low for long periods - You may be overstaffed or sending the wrong work into other channels.
Healthy middle band - Agents are busy but still have room to finish notes, ask for help, and absorb spikes.
Too high for sustained periods - Quality usually falls before leaders notice it in the weekly report.

For many teams, sustained occupancy above the high 80s is a warning sign, especially in chat. Messaging can sometimes tolerate higher occupancy than live chat because conversations are less synchronous, but the right threshold depends on concurrency, complexity, and tooling.

Common mistakes

Treating occupancy as a performance score - This metric is better for staffing and queue design than for individual judgment.
Ignoring concurrency settings - Two teams with the same occupancy can have very different workloads if one team handles twice as many simultaneous chats.
Using logged-in time as the only denominator - If agents stay logged in during meetings or side work, occupancy will look artificially low.
Reading occupancy without response time - A high number matters because of the service effect, not because busy is automatically bad.

What to do when occupancy is too high

Start with the system, not the person.

Check forecast and staffing

Did volume rise in the hours where occupancy spiked? Compare with ticket volume and channel arrival patterns. If volume changed, the answer may be staffing or schedule alignment, not coaching.

Check handle time

If occupancy is high because interactions last longer, investigate why. A tooling issue, product incident, or poor macro coverage can raise handle time and trap the whole queue.

Check routing

Poor routing sends low-priority or misclassified work into your scarce live queue. Review Zendesk auto-assignment accuracy and whether chat should escalate everything to live agents.

Check after-work burden

Sometimes the interaction is short but the follow-up is not. Heavy documentation or case creation after chat can make occupancy look like a demand problem when it is actually a workflow problem.

When to use occupancy instead of utilization

Use occupancy when:

the team handles chat, messaging, or other live channels
concurrency and queue coverage matter
you need to know whether agents were overloaded in real time

Use agent utilization when:

most work is ticket-based and asynchronous
you want a broader picture of support workload
live-channel timing is not the main operational risk

Many teams need both. Utilization tells the broader labor story. Occupancy tells the live-channel risk story.

FAQ

Is occupancy the same as concurrency?
No. Concurrency is how many live conversations an agent handles at once. Occupancy is how much of the agent’s available time is consumed by customer work. They influence each other, but they are not the same metric.

Should I report occupancy by individual agent?
Start at the team level. Individual occupancy can be helpful for coaching or staffing reviews, but the first use case is usually queue health.

What if Zendesk does not expose every time state I want?
Use the cleanest available approximation and document the definition. A consistent definition is more useful than a perfect one that nobody can maintain.

Can low occupancy still be a problem?
Yes. It may mean live coverage is oversized, work is routed elsewhere, or agents are available but not receiving the right conversations.

See live-channel load before it becomes a staffing fire drill - start free