Agent Workload Forecasts

So what to do? How do we account for the arrival randomness and queuing behavior of inbound voice interactions? Well the most widely used method is called Erlang C, and in contact centres that are single skill and not using skills-based call routing, it is probably the most cost effective method. I say cost effective because it is free and available as an excel add-in, although there other premium extensions available of the Erlang-C formula such as Erlang-X developed by ccmath, I however can not qualify their accuracy having never used – if someone from ccmath, wishes to give me a trial version I would be happy to review here in this blog.

Erlang C works by taking volume forecasts and average handling time (AHT) over the desired time intervals, together with service level goals as an input to calculate the number of agents needed for each time interval. Among other limitations such as described next, the Erlang-C model ignores busy signals, customer impatience and services that span multiple visits.

However, most importantly using Erlang C alone to derive agent requirements will not yield acceptable results in a skill based routing environments. For example using Erlang C to calculate agent workload requirements in a skills-based routing environment usually results in over-staffing due to the lack of consideration of the use of ACD call routing logic and efficiencies through economies of scale gained from multiskilled agents. To understand why this is the case you need to understand how Erlang – C works. For example Erlang C makes the assumption that each individual agent will handle a voice interaction on a first come first served basis, and in many contact centres the telephony routing system is simply not set up this way. For example usually each call type will have a different priority, and to be fair why would you want non value calls to have the same priority as value calls?

One solution adopted is to calculate agent workload requirements for each call type independently, and then lower or raise requirements based on an efficiency factor to estimate greater efficiency provided by multiskilled agents. I think it fair to say that this method has its drawbacks, the obvious being how do you account for dynamic ACD routing and the ever changing dynamics of individual skill sets spread over each and every intra-day interval. Having a one fit all efficiency factor to estimate greater efficiency provided by multiskilled agents, might just work for a capacity plan where the average will even things out, but you try to deploy this for intra-day workload forecasting and it is bound to fall down on multiple occations.

Another solution to overcoming multi-skilled environments is to use another type of mathematical forecasting called “Multi-Server Queuing”. In its simplest form this is a system that when customer arrivals find all servers busy they do not enter the queue but are instead lost to the system. For those Math geeks out there, this system has Poisson arrivals, and service times are exponentially distributed. However like Erlang C it has its limitations and requires all agents within an agent group to possess identical skills-sets and that each agent group has its own dedicated queue or a common queue for all agent groups, thus falling down when agents are assigned to individual skills or have different skill priorities. Again this is rarely true in most contact centres today, where calls are queued to agent groups simultaneously or based on conditional rules.

So where does this leave us? Well according to a white paper written by Paul Leamon for IEX Corporation (now NICE), the solution is “to integrate simulation of ACD routing into the forecasting and scheduling process”.

An integrated simulator works by replicating and running multible scenarios for the real life set-up that includes every call type, multiskilled agent, and agent availability by call type. Much of the above ideas have been extracted from Paul’s excellent white paper, and anybody wishing to read further please drop me a note and I will be happy to send you a copy of the white paper.

What we have discussed thus far is purely to calculate agent requirements for “bodies in seats”, making the assumption that all agents are always available to handle call workload at all times. However we all know that this is not the case, nor even advisable i.e. burnout. So as a final refinement to deriving agent workload requirements we need to incorporate what is often termed as shrinkage. Shrinkage is the time (or percentage of time) agents are not productive due to breaks, meetings, training, sickness, holiday, etc. You can either opt to add shrinkage to forecasted agent requirements or reduce the number of actual scheduled staff numbers, its up to you. I prefer adding to agent workload requirements, hence why its in this article. I personally find it easy to explain to operations and anyway it is often useful to keep your actual scheduled staff numbers pure for comparison purposes. Shrinkage is factored into agent requirements by increasing the requirement by the percentage you expect to lose agents for unproductive tasks or events. For example if 36 staff are required to answer the incoming voice interactions (using whatever method) and we know that shrinkage is likely to be 25%, then we need an additional 12 agents, bringing our total to 48. Many contact centres will add the same shrinkage level across all intervals, however in reality we all know that this will not be the case. Whether you are able to customise your shrinkage levels to differ across intervals or not, the most important thing to remember is to reduce your shrinkage percentage every-time you add an event into the schedule. For example if you originally planned for 25% shrinkage, of which 5% was to account for lunches and breaks, once you have completed a schedule that includes planned breaks and lunches you need to reduce shrinkage by 5%. This would be the same of any other planned activity, but of course there are some shrinkage events you just can’t plan for, such as sickness. However this is a altogether different subject for another day.