ERLANG Help needed

[Alex D]

Hi there. I have a new type of transaction I need to calculate my FTE need for. Think of it as emails....the customer goes online, creates a "case" for an agent to handle, rather than a call. My standard calculation that I use is overstating my FTE need....the only difference between this type of transaction and a phone call is that we have 24 hours to resolve the case, but we aren't open 24 hours, we still schedule standard 8 hour shifts.

The AHT we are using for planning is 360, the shrink is 27%. What formula do you recommend to use to calculate the FTE Need for this type of work?

 

[KRice]

Are you saying that you currently schedule one 8-hour shift per day, and you wish to estimate how many FTEs (the number of people per shift) that would be expected to handle this workload?

 

[Alex D]

Are you saying that you currently schedule one 8-hour shift per day, and you wish to estimate how many FTEs (the number of people per shift) that would be expected to handle this workload?

So, yes, our shifts are 8 hours per day, we don't work 24 hours around the clock, but have 24 hours to resolve our cases

 

[KRice]

24 hours from the time the request arrives, or 24 actual working hours (which would be 3 days)?

 

[Alex D]

24 hours from the time the request arrives, or 24 actual working hours (which would be 3 days)?

24 hours from the time the request arrives....do you need to see my current calculation?

 

[KRice]

Yes, that would be helpful. I’m wondering if you need to make some scaling adjustments to account for the difference between “calls” that I’m assuming can arrive 24 h/day, and “call servicing” that only occurs 8 h/day.

 

[Alex D]

Yes, that would be helpful. I’m wondering if you need to make some scaling adjustments to account for the difference between “calls” that I’m assuming can arrive 24 h/day, and “call servicing” that only occurs 8 h/day.

=forecasted volume*forecasted AHT/3600/# of business days/8/(1-Shrink %)/Occupancy %

forecasted AHT i am using is 360, # of business days, for example of Feb I am using is 21, my shrink is 26.5% and occupancy is 85%

 

[KRice]

What is your typical forecasted volume, and is the volume relatively constant over a 24 hour period? For example, do you see 300 online cases initiated during an 8 h shift, 300 during during an entire 24 h period (only 8 h of which has some actively working to resolve them). I'm trying to understand what a typical 24-hour cycle requires in terms of service demand.

Does the demand for help continue on non-work days? You mentioned business days. Does that mean that cases received at the end of work week are automatically "late" when work begins on them at the beginning of the next work week, or is your target response time in terms of 1 regular working day?

And you mentioned the current approach seems to be overestimating the number of people needed. What result does the current approach produce?

 

[Alex D]

What is your typical forecasted volume, and is the volume relatively constant over a 24 hour period? For example, do you see 300 online cases initiated during an 8 h shift, 300 during during an entire 24 h period (only 8 h of which has some actively working to resolve them). I'm trying to understand what a typical 24-hour cycle requires in terms of service demand.

Does the demand for help continue on non-work days? You mentioned business days. Does that mean that cases received at the end of work week are automatically "late" when work begins on them at the beginning of the next work week, or is your target response time in terms of 1 regular working day?

And you mentioned the current approach seems to be overestimating the number of people needed. What result does the current approach produce?

My forecast is going to vary, seasonal volume, for sure, our priority is to improve our current calcs to get a better #, as I said, we are over-stating our need. Work does come in on Sat/Sun, and the clock will keep ticking on those, so yes, come Monday, we'll be late on those, but that's acceptable for now.

In short, I am needing to find another calculation to use, to help me create my long term forecast for the rest of the year in terms of FTE NEED.

Current approach, for example, in FEB says I need 20 FTE, but I am going with 10-12, and the wait times are under 10 minutes, and with a 24 hour acceptable ASA, I am overstating my need

 

[KRice]

Again, what is a typical volume?...I'm looking for a reasonable estimate to plug in to some calculations. But I'd like to also understand the time component for the volume. For example, if I choose a call volume of 1000 per 1440 minutes (1 day), that would lead to an estimated call rate of (1000 calls) / (1440 min) * (60 min/h), or 41.7 calls/h. This would normally be used to estimate the Traffic Intensity:
calls/h * avg. time per call, or (41.7 calls/h) * (6 minutes/call) * (h/60 minutes) = 4.17 Erlangs (essentially call-hours per hour).

This is what we find in this part of your formula: "forecasted volume * forecasted AHT / 3600"
And then to account for shrinkage and occupancy, this part also makes sense: "/(1-Shrink %)/Occupancy %"

What I do not follow is this part: "/# of business days/8 "

It seems that in the example I've described, 4.17 Erlangs is not an appropriate description of the Traffic Intensity. While we might, for simplicity, assume the call volume (or web-based requests for help) arrive somewhat regularly over a 24-h period, 7 days a week, those requests are not serviced over that same period of time. Instead, servicing is much more sporadic, but at a higher intensity because for a regular workday, only 8 hours is devoted to servicing those requests. And for a week basis, normally on 5 of the 7 days are devoted to servicing the requests. So it would seem to me that the Traffic Intensity should be scaled by a factor of (24/8) * (7/5) = 4.2 (interesting that this number coincidentally is about the same as the Erlangs computation above). In any case, if we apply this scaling factor to the Traffic Intensity, a modified Traffic Intensity of (4.2) * (4.17 Erlangs) = 17.5 Erlangs

Then after burdening this value by the Shrinkage and Occupancy factors, I get an estimate of about 29 agents.

I've posted some Erlang C worksheets on this site, but it sounds as if you may already be using a tool. I do wonder if some fundamental assumptions in the theory might not hold for your application. For example, Erlang adopted the Poisson distribution to estimate the probability that calls are answered within their target times, but your average handling time (6 minutes) and the the target response time (24 hours) are so disparate that we are operating in one tail of the probability distribution...which isn't good. Those probability estimates would have much higher uncertainties associated with them.