← All posts
OperationsContact centersReporting

Shrinkage you cannot see: where the contact center day really goes

Workforce management counts the shrinkage it schedules. The drift between tools inside a shift never shows up in the plan, and application-level time data is the first place it becomes visible.

JR
Jon Rumens
Founder, ReclaimTime · October 15, 2026 · 5 min read

Every workforce management team has a shrinkage number. It is the share of paid time that is not available for handling contacts, and it is built up from things the planner can see: breaks, lunch, training, coaching, team meetings, holiday, sickness, system downtime. The forecast is set, the schedule is built, and the adherence report says whether people were in the right state at the right time.

What the adherence report cannot tell you is what happened inside the "available" blocks. An agent in the Ready state for six hours, with handle time and after-call work that add up to four and a half, has ninety minutes that the system calls available and nobody can account for. Multiply that by a team and a quarter and it is the biggest line in the shrinkage budget, and it is not on the budget.

Why the planning tools cannot see it

Workforce management software works from state changes: logged in, ready, on a call, wrap, break. Those states come from the telephony or contact platform, and they describe the agent's relationship to the queue. They say nothing about the screen.

Between contacts, an agent who is nominally ready might be finishing notes in the CRM, looking something up in the knowledge base, checking a personal site, or sitting in a chat window. All four look identical to the ACD. The first two are the job. The third is drift. The fourth might be either, depending on the chat.

Because the planning tools cannot distinguish these, the drift gets absorbed into averages. After-call work creeps up. Occupancy targets get quietly lowered to match reality. The forecast is "accurate" because it has learned to predict the drift without naming it.

What application-level time data adds

The missing layer is time by application and site, per team, inside working hours. Not screenshots, not keystrokes: just which window was in front and for how long.

With that layer, the ninety minutes decomposes. In the teams I have seen go through this exercise, the pattern is rarely "people are slacking." It is usually a mix of:

  • Tool friction. Time in a spreadsheet that exists because the CRM cannot do a lookup that every agent needs. This is a systems problem wearing a productivity costume.
  • Knowledge gaps. Long stretches in the knowledge base or an internal wiki by newer agents, which is training shrinkage that was never scheduled.
  • Unofficial channels. Team chat used for live help, which is a coaching cost that is invisible in the coaching budget.
  • Actual drift. Non-corporate sites during available time. Usually smaller than people fear, and usually concentrated in particular hours of the day.

Each of these has a different fix. Tool friction is a ticket to IT. Knowledge gaps are a nesting change. Unofficial channels might be fine, or might be a sign that the official escalation path is too slow. Drift is a conversation, and often a scheduling one, because a 3 pm slump in a team that started at 7 is a shift design question before it is a conduct question.

None of these fixes are available while the ninety minutes is a single undifferentiated number.

Doing this without turning it into surveillance

The reason most contact centers have not added this layer is not that the data is hard to collect. It is that collecting it looks like surveillance, and in a lot of operations it would be.

Three choices make the difference.

Measure the team, name the tools. The useful unit is the team's distribution of time across applications, not an individual's. ReclaimTime records time in listed corporate applications under the person's name, because that is the job and nobody disputes it, and records everything else anonymously at group level. So the team's non-corporate time is visible as a total and a trend, but no supervisor can pull up a list of which person was on which site. That is the setting I would recommend for any contact center, and it is the one that works councils and HR accept.

Stay inside working hours. Nothing is recorded outside the configured shift. The question is where the paid day went, so the data stops when the pay does.

Do not build a league table. The moment per-agent productive time becomes a ranked list, the data stops describing the operation and starts describing who is best at looking busy. Use it for the four categories above. Use the ACD for individual performance, as you already do.

A worked example, with the numbers removed

Here is the shape of the exercise, with the figures left out because yours will be different.

A supervisor pulls the statistics page for one team over the last two full weeks, filtered to working hours. The time distribution shows the CRM, the telephony client and Teams at the top, as expected. Fourth is a spreadsheet application. Fifth is the knowledge base. Non-corporate time appears as one anonymous block.

The spreadsheet is the surprise. The supervisor asks the team and learns that every agent keeps a personal lookup sheet because the CRM's product search is slow. That is a ticket for the CRM team, and when it is fixed the spreadsheet time should fall. Now there is a before-and-after measurement for a tooling change that previously would have been argued about on feel.

The knowledge base time, split by group, is higher in the group that went live last month. That is expected and it is also a number that nesting plans should contain. Next quarter's nesting plan will.

The non-corporate block is smaller than the operations director assumed and is concentrated in one hour of the day. That hour coincides with a queue trough. The conversation that follows is about whether the schedule should offer a break there, not about anybody's conduct.

Where to start

If you want to try this, start with one team and two full weeks of data, filtered to working hours, before anyone draws conclusions. The dashboard hides activity younger than a few minutes and the first few days of any rollout are noisy while the corporate list settles. Two weeks is the first point at which the distribution means something.

Then look for the fourth and fifth applications on the list. The top three will be what you expect. The next two are where the shrinkage you cannot see has been hiding.

The statistics page in the documentation shows the filters and the export. If you would rather talk it through first, start a pilot deployment with a single team.

See this on your own teams

Start with a pilot group and see the first team reports within a week. A reply comes within one business day.