Completely respect your point and apologies if I was being overly flippant.

I was merely giving lester a starting point from which he can draw a broad assumption for changes in volumes, before immersing himself in erlang. Hoepfully my explaination to Steve has fleshed this out.

Eamon

No patches or pipes here!

I tend to go for the dark clothes, sunglasses and goatee..

Cool!

However, the derived equation in the first post IS my own work.
It seems to work fine with call volumes >150 on a 12hr spread.

I've said it before and I'll say it again.

I'm a geek NOT a nerd! {BIG EVIL GRIN}*

HTH

DaveA




* And proud of it!

Mock and I'll send the penguins round to bite your ankles!

guys thanks for the quick reply

im with worforce for 6months now but i don't feel like it. all of us analyst in my organization are just like followers who just follow our superiors w/o even knowing what is it.. were like more with painting or doing some clerical works than with analyzing which is our title.. i'll get back to what you guys discussed after i'm done with my tasks.. :(

"5,000 calls multiplied by 5 mins per call"

Eamon the average volume is closer to 5600 calls per week and the AHT is 10 minutes not 5 minutes.

Which was what Dave, Lester and I were referring to.

"working out the weekly volume as 25,000 x 12 / 52 and taking abandonment into account"

Eamon,

I have never understood this principle, why would you plan NOT to answer calls?

In a sales environment it would be a difficult conversation to explaint to aq key client that you were planning not to answer calls.
Abandoned is an allowance after the event, not a given before it.

Hi Steve

I can see how you would struggle to explain this to a client, perhaps I can help you out.

When talking about call forecasts people usually quote the number of calls they expect to receive and the answering standard (90% in 20 etc) that they want the operation to perform at. In order to size the operation correctly using erlang, you need to exclude the number of calls that you expect will abandon given that answering standard. So in this example I took 2% of the calls out as that is broadly in line with what happens when a centre performs consistently at 90% in 20.

In the operational environment (especially sales) they will try and answer all calls, but trying to answer every single one would require either a massive increase in staff or a huge level of flexibility (which isn't always possible).

The sale isn't the exclusive driving factor in a business, especially if the revenue generated by handling the calls is less than cost to service it, most sales people understand that.

Eamon

Your logic is flawed. If you are planning to abandon 2% of your volume the likelihood is that you will actually abandon 6%. For every call you plan not to answer there will be call backs which will exacerbate the problem.

I stick by my view that abandoned calls are an allowance after the event and not a given before it.

What you say is quite serious and I strongly recommend that anyone adhering to the practice you describe really considers the consequnces.Just because you think that a particular SL may deliver abandoned calls doesn't mean you shouldn't try and answer them, by all means throw out a warning that abandoned may be x% but do not take the calls out before you start.


Also I think you will find there really isn't a mathematical correlation between an answered within service level and an abandoned rate, only a tacit relationship. Your practice to reduce your forecast is as good a self fulfilling prophecy as you will get in the realms of customer service "I told you there would be abandoned calls because I planned to have them".
Would you also recommend telling your customers that they may not get answered as you are not planning to answer all calls?

Can you imagine a taxi driver saying you are going to have to walk the last mile of the journey because he doesn't have enough gas in the tank? What you describe and advocate is no different.

Remarkable!

Which forecast do you use to compare your actual volumes against? The one you planned for or the original including the abandoned that you deducted?

Your quote "The sale isn't the exclusive driving factor in a business, especially if the revenue generated by handling the calls is less than cost to service it, most sales people understand that. "

What I understand from this statement, if it's true, is that you would not have a business.

We use both, we forecast the overall calls and the calls that will be answered.

As for your last comment - we do ok, ;-)

www.becogent.com

Hello

First time post here and am interested in this thread;

I am using an Workforce planning tool long term planning module. When I run figures through the wfm tool my numbers are alot lower than an erlang calculator. The parameters are the same, opening hours, SLA etc.

monthly volume - 186,000
aht - 333
80/20 sla
85%occ
agents work 8.5 with 1/2 hour lunch
30% shrinkage
open 16 hours per day

Erlang gives approx 180, WFM tool shows as 165

Any ideas, could it be occupancy re the erlang calc?

Thanks for your help!

Hi Mark

The 165 figure looks right given the other inputs. What you might be doing (guessing here) is uplifting the Erlang required figure to take occupancy into account.

When you work out the agents required figure through erlang are you then inflating that figure using the occupancy percentage and then adding shrinkage? If so that would explain the difference between the 165 and the 180.

Eamon

Hi Eamon, thanks for the reply

Interesting, I thought the 165 was to low hence my post.I have used workload and also erlang (fracagents).

With the workload I have included the occupancy figure. With the erlang calc this was not inflated as erlang already assumes a level of occupancy?

I have a feeling the WFM tool calc is either incorrect or there is an input error somewhere along the line.

Hi Mark

I worked out the requirement at 165 using a spreadsheet model that I have that works out the FTE requirement either as a direct fracagents calc, or as a workload figure with Occupancy included. Using a top line occupancy of 85% and the other inputs you have given hits 165.7 FTE. Using the erlang alone acutally reduces the FTE requirement slightly as it assumes periods where greater than 85% occupancy is possible. Either way the forumla

Calls per week x AHT(secs) / occupancy% / (1-Shrinkage%) / 36000 / hours per FTE per week

should give you the right figure

Just make sure that yu are applying the lunch figure in the right context. i.e. leave it out all together and ensure that the hours per FTE per week is 40 or include it (which your WFM tool will probably want to do) and divide by 42.5. It may me that you have included an allowance for lunch in one part of the calculation and then divided the total by a lower FTE hours per week assumption. That would bridge the gap between the two figures you have.

Alternatively
Is the profile of the calls very erratic by any chance?

Eamon

This could be because of the way shrinkages are added to the workload. Your excel tool may inverse the addition of shrinkages whilst your WFM tool may be a mark up.

Just a thought.

Thanks Steve/Eamon

I did think about the shrinkage calcualtion and both use the following req/(1-Shrinakge).

Eamon, having looked at the history that the wfm tool was using there are big peaks and troughs and certain periods of missing data, so maybe this caused the differences.

I think either way the amount of time that has been spent trying to investigate this has confirmed my personal opinion that wfm tools should be used for scheduling etc as their main purpose. Longer term planning as I have always done should be outside of this area.

As I say just my personal opinion.

Thanks again

Mark

Hi Mark

Yep, if you are using two wildly different call profiles, one through WFM and one through Erlang then they will produce slightly different results.

Still, if both are using the same parameters then they should come out with close to the same answer.

What do you have in your WFM tool for IOT?

Eamon

Curious as to what you everyone is using in Shrinkage and have a comment about inaccuracy of using the common add-in "fracagents" function.

I'm assuming that you are not accounting for scheduling efficiency (or inefficiency). Even with a perfect forecast and perfect math (Erlang and other), more than likely, you will never be able to build schedules that have a perfect fit (this factor can vary greatly based on flexibility of breaks/lunches, FT to PT ratios, hours of ops, size of operation, etc). If you want to see how bad it can be, try 2000 calls a day, 900 second AHT, 80/20 SL, normal curve over 14 hours of ops, all FT agents, and breaks (15 minutes each) must fall +/1 one hour from 1/4 and 3/4 into shift and lunch (1 hour) must fall +/- 1.5 hours of the halfway point. I believe you will find what the calculations say you need and what can be scheduled to cover the pattern are two different numbers. I don't see where anyone is accounting for this, unless you are including in your shrinkage (which most people do not do).

On the fracagents function, just be aware that it uses linear interpolation to determine the fractional (it goes one over the required and one under the required and takes the linear solution between those based on the SLs at those "whole" staffing numbers to determine the fracagents. As most of us know, Erlang calcs are not linear. If they were, you wouldn't need to use the calcs; it would be very easy to determine staff required and outcomes with straight linear math. If you know VBA and look at the code, you should very easily be able to compare the fracagents code to the agent code to determine how you can modify to give accurate fracagents results.

If you want to see the issue, do a calc to determine agents using the fracagents function, then reverse it by using this as the agents and doing a SLA function to see if it returns the same SL that you started with (try for example SL 80/20, 200 calls per hour, AHT 900, the fracagents will return 57.23 (to two decimals) when reversed it will be 79.45% (did not meet the 80% goal), the true fractional agents should be 57.47 (to two decimals) resulting in 80.00% (meets the 80% goal).

Granted the inaccuracy is pretty low, however if you are using fracagents because the difference between 58 FTE and 57.23 FTE is important, then getting a result of 57.23, when it actually should be 57.47 is probably important to you as well.

Since the one in my last post came close to SL goal, figured I'd give another example of either a small center, or maybe the first hour (or last hour) of the day when volume is lower.

Try a fracagents with 80/20 SL and 20 calls an hour (or 10 for half hour) and 900 AHT. fracagents returns 7.72 (rounded to two decimal), if you back into service level percentage, using the unrounded return result from the fracagents and the SLA function, you get a SL of 73.62% (way short of 80% goal).