Fudges, Adjustments, and Jake’s Factor
By Ric Kosiba, Interactive Intelligence
“Any number added to, multiplied with, subtracted from, or divided by the number you got in order to get you closer to the number you should have calculated is Jake’s Factor.”
If you look up mathematicians’ discussions of fudge factors, you’ll see that there is a real legitimate use for these sorts of numbers—they serve to quantify holes in our real world knowledge or to put a figure on our scientific uncertainty (i.e., Planck’s Constant). But often they serve less legitimate, but sometimes necessary purposes: they serve as a plug for errors in our analytics (i.e., Jake’s Factor).
There are good and bad fudge factors. Fudge factors that behave correctly can serve a real purpose, even if they are not fully understood. They can plug the error associated with a theoretical calculation when compared to an empirically derived or known real-world answer. Bad fudge factors attempt to do the same thing: plug the difference between a calculation and observed performance. But bad fudges plug an equation with a constant when the calculations’ error is not consistent, or plug a reasonable number into an equation without comparing to the real-world performance. I’ll explain.
Schedule Inflexibility Fudge
The most common of contact center fudge factors is the schedule inflexibility factor. This fudge serves to reconcile the difference between the theoretical agents required versus the actual agents required when putting together a capacity plan or budget. There are many reasons why this factor is used in contact centers, primarily because it just seems to make a lot of sense.
When calculating the number of agents needed for a day, week, or a month, the number of work hours is determined (usually using an Erlang equation) per interval. These work hours are rolled up to an overall FTE number for staffing and hiring purposes. The problem with this theoretical staffing requirement number is that it doesn’t include the complexities and inefficiencies of producing actual employee schedules to meet the requirement. You need to schedule more agents to cover center demand than the raw number the theory states.
This is where schedule inflexibility comes in. Almost every workforce management system calculates this value automatically—it is the difference between raw number of agents required and the number of agents scheduled considering work rules, agent preferences, and shift definitions (shift lengths and break patterns). Because this number is 1) easy to get, 2) seems to add realism to the capacity plans, and 3) tends to overstaff, it is used in many capacity planning spreadsheets.
What mistakes do most analysts make when using this fudge factor? The common mistake most analysts make is that they do not go back and validate these methods to actual contact center performance. When it comes to the real-world performance of a contact center, scheduling (and its inflexibility) is just one part of the equation. Non-adherence and other realities mess up the schedules. The better fudge factor would be an “as produced” schedule rather than the planned schedule.
Wait! It tends to overstaff? Yes, for most companies, the schedule inflexibility factor when coupled with an Erlang equation almost always overstaffs. Many in the industry like this overstaffing cushion, and use it partially for that purpose—to give the operation a cushion. Speaking of Erlang…
The Erlang C Plug Factor
It is has become well-known that the old Erlang C calculation is less than accurate. Yet many workforce management vendors still use the calculation in their software and many, if not most, spreadsheet-based capacity plans still rely on it as well. Why? My guess is that this is because of ease of use or momentum; that legacy math resides in spreadsheets or old systems.
Recently, we have been seeing more and more analysts try to overcome the inherent inaccuracies of Erlang—through the use of either a fudge factor, or through the use of “forecasting out” expected abandoned calls.
The fudge: Analysts are searching for a single fudge factor for the Erlang overstaffing bias and they have their work cut out for them. In the graph below (you’ve seen a similar graph in this column before), we have plotted service level expected when we know exactly how many calls, how many agents, and what the actual handle time was at a call center (the data was taken from a basic ACD report).
What makes these validation graphs so interesting is that they clearly demonstrate the accuracy of this and any other method we choose to analyze. In this case, the Erlang C calculation is seriously in error—it does not come close to predicting what will take place in the call center. But what is useful to our discussion is that it isn’t even consistently inaccurate. Sometimes it is off by 30%, other times it is off by 10%. The variability of the error in prediction shows that we cannot come up with a single fudge factor that will make an Erlang approach accurate (although we can come up with a fudge that certainly makes it closer). The variability of the Erlang calculation is what makes it irredeemable.
We see another fudge in capacity planning spreadsheets to help overcome the assumption within Erlang that no callers ever abandon. The “no abandons” assumption is a pretty well understood simplification. What is not understood is how to fudge old Dr. Erlang’s equation back into shape. One common simple answer is to forecast calls handled rather than calls offered when developing plans. While this seems to be a step in the right direction, it ignores the purpose of the exercise in the first place. That is, it is to evaluate staffing and service at varying volumes. Clearly, you cannot evaluate service at varying volumes if you are assuming the abandons as part of your calculation. The only way I can see this working is for a very small range of service levels being analyzed, and then adding (yet another) fudge factor to account for changes in economies of scale. More fudging feels wrong.
In the market, we are starting to see other variants of Erlang equations—Erlang A and a similar equation, Erlang X. Erlang A serves to add a patience curve to the Erlang C equation, and Erlang X serves to approximate a multi-skill scenario. In year’s past we evaluated an Erlang A equation, and my recollection was that it was still only accurate for a small range of service levels. Feel free to look at it, and I would love to know your results.
Other Fudges and Assumptions
There are other common fudges that I find interesting. One fudge that I accidentally discovered in my younger days was the assumed-occupancy fudge. I was working on a call center modeling project with a good engineering friend of mine, and we were messing around with the Erlang equation to see if we could make it more accurate.
Lo and behold, we found a method. If we could know exactly the future occupancy of the center, we could get the staffing requirements very close to actual. The holy grail of call center math was all ours. The problem was that we could never forecast occupancy with the accuracy required to make staffing decisions accurate. It turns out that knowing occupancy is knowing staffing (they are part of the same equation for determining service). So this method is a cheat, and I expect that those who use assumed occupancy methods cannot prove the accuracy without plugging in actual occupancy, rather than forecasted.
Attributes of a Good Fudge
All fudges aren’t created equal. Fudges that are consistent over time are useful, they represent a consistent factor that we are missing from our calculations. These sorts of fudges are useful and legitimate so long as you carefully validate the model and your fudge factor often.
Fudge factors that are not consistent, like our Erlang C plug, are less useful and could even be dangerous. If you cannot make the fudge accurate most of the time, then it is time to look for other methods to model your contact center. The last thing you need is to have a fudge factor named after you for being wrong, like Jake’s Factor!
Ric Kosiba, Ph.D., is a charter member of SWPP and vice president of Interactive Intelligence’s Decisions Group. He can be reached at Ric.Kosiba@InIn.com or (410) 224-9883.