I have previously talked about volume forecasting, and I think before I move on to other areas of workforce management such as Scheduling, Capacity planning and Real-Time Management I think it is worthwhile discussing how to derive agent workload requirements. In this article we are going to focus mainly on calculating agent requirements for Inbound Voice Interactions, there is growing trend for customer interactions through Email, Chat and Social Media interaction as well as Outbound Voice Interactions and in future articles I aim to address these particular elements as well.
Since over 70% of a contact centres costs can often be associated with staff, and customer interactions live and die on the simple premise that an agent needs to be available in order to be able to speak to a customer, ensuring you have the right number of bodies available for customer interaction is essential.
In its most simplest form, the number of forecasted calls for an interval multiplied by the average handle time (AHT) of a contact will give you a basic agent requirement for "bodies in seats". As with volume forecasting AHT will vary by time of day as well as by day of week and even by week of month in some cases. This might be agent led due to tiredness or customer led because customers call at certain times for certain types of calls.
In reality this simple calculation will not accurately derive agent requirements, which is hardly surprising as nothing is ever easy right? The reason this simple calculation is flawed is that not all voice interactions will land at an agents feet (or ear piece to be more accurate) at the same time. For example if you have a pot of 40 Agents and at 11:07 43 calls arrive, all 40 of your agents will be busy and there will 3 calls in the queue waiting to be answered. At 11:18 after clearing the calls you have 36 calls in action resulting in 4 agents sitting idly waiting for their next customer interaction. This means in reality agents will not necessarily complete a full days work, which is through no fault of their own but because some of their time will be spent dealing with a customer interactions and some of the time they will be spent waiting for their next call. It would be great if calls would arrive sequentially and there are certainly technologies out there that will help to smooth this issue, such as Queue Buster and WeQ4U, but in reality voice interactions arrive whenever the customer decides to place the call. As a result, you need more staff in place than actual hours of work required to be completed. As a WFM planner this is an important element to understand as you will likely need to explain and educate others who have yet to grasp this concept.
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.
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.
