All my talk about Occupancy makes me realize two things: First, many people may not know what exactly it is. Second, they may not know how to calculate its effects.
Because of this, people make generalizations about what a good occupancy should be. For most of my career, I have heard that you never want to run much higher than 85% Occupancy, because that makes employees get back-to-back calls and work too hard. Of course, being a math guy, I had to see if this was true. And, in turn, this led me to understand how the definition of Occupancy can play a big factor in what would be acceptable.
Defining Occupancy
Occupancy is loosely defined as how busy an agent is handling calls. Convert that to a formula and you get the time handling calls divided by the time you should be handling calls.
That denominator is a little vague, isn’t it? “Time you should be handling calls” is defined differently in many phone switches. In some cases, it is time-logged into the phone; in others, it is time-logged into a skill; and, in still others, it is time on calls or waiting for calls. For many years, these definitions were very close and mimicked Mr. Erlang’s idea that agents were only occupied handling or waiting for calls. But, in the past 20 years, all the major switch providers have added functionality to the systems. Not Ready, Unavailable and Aux Time each allow agents to stay logged in but unavailable for calls. This is a great help in tracking agent time, but it messes with how the switches calculate occupancy. Whereas, before, agents logged out for everything else, now they stay logged in and select a Not Ready code for many activities.
Considering that the things typically associated with Not Ready codes like breaks, meetings and training make up around 8%–10% of shrinkage in a typical contact center, and your acceptable occupancy can have quite a range.
I solve this dilemma by always calculating Occupancy the same way, and as Mr. Erlang intended. My formula is this:
Time handling calls
Time handling calls + Time waiting for calls
Where:
- Time handling calls equals total handle time (talk, hold and wrap)
- Time waiting for calls equals available or ready time (time waiting logged into the ACD but not on a call or in an auxiliary or not ready state)
I use this formula because it allows me to reconcile back to my Erlang calculations and service level. Also, it allows me to be consistent when comparing across systems and clients by removing that 8%–10% (or more) of shrinkage that is captured in an agent’s login time by Not Ready codes. Now that we have a cleaner definition of occupancy, let’s look at how to calculate its effects on agents.
Calculating Occupancy’s Effects on Agents
When agents are too busy, they do not have enough time between calls. So that is what we will calculate to determine what occupancy is “too busy.” Let’s start with three assumptions:
- There are 3,600 seconds in an hour (60 minutes times 60 seconds per minute).
- Our average Handle time is 300 seconds (I just picked this—feel free to use your own).
- We are not worried about the Occupancy, Service Level relationship for this exercise.
The process is simple math. We will first calculate occupied seconds, then convert those seconds to calls handled, calculate the remaining seconds and then divide those seconds by the calls to determine the average number of seconds between calls. That looks like this:
Yup, an 85% Occupancy nets you about 53 seconds between each call… man, that’s a long time! Don’t believe me? Stop reading and sit still and silent for 53 seconds… I’ll wait…
So how could 85% be considered the max if there is that much time between calls? I believe it comes back to that 8%–10% of Not Ready time. If my switch calculation includes it, an 85% occupancy in the switch is really more like a 93%–95% using my definition. Following my math above, that would be somewhere between 16–23 seconds between calls (see the table below). That is still a respectable gap.
There you have it!
85% is too low… sorta… Occupancy is tricky, but once you have it calculating correctly you can have a better discussion around how it affects agents.
