Approximating numbers from a bell curve?

Question

I've been banging my head against a wall on this one.

I'm working on a project where the client owns a call centre and wants to estimate the number of people needed to work in half hour slots on a campaign by inputting a peak hour, an estimate of the people needed in that hour and presumably a standard deviation. This should then "fan out" the values to the other slots (diminishing on both sides of the peak).

If this was a graph you would have half hour slots on the x-axis (1 to 48) and number of people needed along the y-axis, which would look like a bell curve with the peak being at the specified peak hour.

How can I get approximate values of the seats needed for each half hour slot? Any point in the right direction would be much appreciated!

P.S. Working in .NET if anyone knows of any libraries that can do this.

Answer 1

I guess this isn't really an answer, but the telephone industry uses the Erlang as a unit of measure for these kinds of problems, which is derived from the average call length and the average number of concurrent calls in a period.

Answer 2

You can get the forumula for the probability density function (along with a .NET libary) here

However, I work on a call center software myself at my job, and I can tell you the FTEs are never normally distributed. There are usually ~2-3 overlapping normal distributions, one skewed left and one skewed right depending on the time of day (early morning, late afternoon) and type of campaign (B2B to B2C).

For a more accurate estimation I would recommend keeping a history of previous activity/load in your call center (what is the average load at each half-hour intervals) then use that as the distribution baseline, scaling it to fit for the expected peak load and estimated call length. This is what we do in ProtCall, and we are usually right within 90 % - 95 % of the actual load. Sometimes. Sometimes we miss by a factor of 10.

EDIT:

Ok, I took a little time to look at how we estimate loads, and standard distribution is not going to get you nowhere. Take a look at a couple of screenshots from our charts and you'll see how diferent the distribution actually looks.

What you need to do( basically ):

1. Sample the number of calls made each minute (how many calls we had since 60 seconds ago)
2. Save those samples in a table : TimeOfDay, CallsMade
3. Load those samples and scale them. (ie. if our total table has 10.000 calls and we estimate our new activity to have 4.000 calls per day, multiply everything by 0.4. You can scale by estimated nr of calls or (more acuratelly) by estimated number of talk-time-minutes per day)

Alternatively, if you simply have a table with a row entry for each call made you can simply :

SELECT count(*),datepart(hour,[CalledOn]) as CalledOn from tableCalls group by datepart(hour,[CalledOn])

to count the calls made each hour. It will sample per hour, not per minute, but it might be enough to give you the baseline

Answer 3

Hmmm

I'd be surprised if the distribution of calls during the day (24 hours from midnight to midnight) was normal (ie followed the bell curve). However, if that is what the client has ordered, so be it. But before you go much further, do some further investigation.

Is your presumption that the client can specify a std dev correct ?

The calls won't be normally distributed about the peak hour within a day, unless the peak hour happens to be 12:00 -- if the client really believes that the distribution of calls is unimodal between 00:00 and 23:59, then I bet the mode ain't at 12:00.

As one of your respondents has already said, you can find the formulae and implementations of the normal distribution readily enough.

But if you want to impress your client and build a better model, I'd start with some simple queuing.

Regards

Mark