Hi All,

I have been asked to provide the predicted available time in my forecast requests. I use Erlang to calculate my requirements and I came up with a formula that gives me an answer. I would like to hear if anyone has a different calculation or opinion.

My calculation is as follows:-

((calls * AHT) / (required hours * 3600)) - 1

Thanks
Scott

Scott,

Don't forget to consider breaks, meals, and other forms of shrinkage.
Those all take away from your "available" time.

I think a more accurate formula would look something like this:

(Total FTE hours/day*3600)-((total calls/FTE*AHT)+(break minutes/day*60)+(meal minutes/day*60)+("other shrinkage"%*(Total FTE hours/day*3600)))

I might have misplaced a parenthesis here or there, but i think you get the idea.
This is designed for a single FTE...if you want it total for the site, multiply the result by FTE, or if you have an equal amount of full-timers vs. part-timers you might want to do a separate calculation for each...

-Tom Tritten
WFM Solution Architect

Hi Thomas,

thanks for your answer, but I'm not sure I need to do that.

My thoughts are using excel erlang, you provide a call volume, SLA and aht per interval, this then tells you the number of people that need to be logged in and able to take calls for you to meet service level. As I understand it and correct me if I'm wrong Erlang works or arrival of traffic and then calculates the required agent to ensure that you will have an available agent with 20 sec 80% of the time. (assuming 80/20 is your SLA).

Break time etc woud be over and above as shrinkage.

My questions is, is the difference between workload (Calls * AHT) and total available hours required by erlang (agents * interval time) a fair assumption of Available time calculated from Erlang.

Cheers

Scott,

I've been looking at this for a few days now...

My first thought was that it's too simple.

However on reflection and in light of Thomas's answer
I have to say I think you're correct...

With one caveat....

The shrinkage you are allowing for is obviously NOT part
of the ReqHrs, however you need some sort of minor allowance
IF you wish to be particularly accurate to allow for the time
the scheduled agents are not available (Loo, water etc...)

Obviously this is extreme shrinkage forecasting, but, in
the case of the most accurate forecast should be accounted for.

For the main part your first calculation (as far as I can see)
is OK.

Hope it helps.

Regards

DaveA

Scott,

Perhaps I misunderstood your original question.
Due to the way the question was worded, and the division by 3600, I was under the assumption that you were looking for the actual total number of available seconds that you would have during a given day.
If you are looking for just a simple erlang calculation, then you are on the right track, but I would like to echo Dave's caveat to consider some form of shrinkage to maximize accuracy.

Good Luck!

-Tom Tritten

Thanks Dave & Thomas, I think from your answers I have what I was looking for, Basically in a situatioin where you don't ask you OSP's to answer calls, you ask thme to deliver productive minutes.

Productive minutes defined as Talk,Type & Available time. The reason I came up with the formula ignoring the shrinkage factors that you have is based on me not actually defining the number of people they need, just the time they need to deliver.

I was after the Available time as I want to explain what to expect to the senior management. especially when the OSP's ar elikely to exceed the required staffing to maximise billing.

based on the previous posts, and the extra info in this, can i ask if you agree with my original calculation now?

I have had to do a lot of work around agent occupancy recently and totaly agree with your calculation in your first post for a forecasted idle time.
You seem to know what you want to achieve and how to get there but I thought you may find the below interesting, I certainly did when I first started on the piece of work I was asked to complete-

http://www.servicelevelgroup.com/files/SLGOccupancyBasics.pdf