Estimated Wait Time Calculation vs Built-in function EstimatedWaitTime()

[stork]

I'm trying to figure out what the difference is between the EWT calculation for Courtesy Callback versus the built-in function EstimatedWaitTime().  The only documentation I can find for the built-in function isn't very descriptive it terms of the math behind it.  Below is the description I find in a document;

Returns the minimum estimated wait time for each of the queues against which the call is queued (skill group(s) or precision queue(s)). Queue to Agent(s) is not supported. If no data is available, returns -1. The estimated wait time is calculated once, when the call enters the queue.

The default estimated wait time algorithm is based on a running five minute window of the rate of calls leaving the queue. Any calls which are routed or abandoned during the previous 5 minutes are taken into account as part of the rate leaving queue. For precision queues, the rate leaving queue represents the rate at which calls are delivered or abandoned from the entire precision queue, not any individual precision queue steps.

I have tried both calculations and they both seem to give different results.  The eventual plan is to get courtesy callback working, but our current request is to speak back the current position in queue and the estimated wait time to the caller if they are queued.

Anyone know which is best to use, built in function or the calculation?

[geoff · Accepted solution]

I do not know the answer to your question but I do know that for one Government project we worked on we investigated about 10 different formulae for EWT, and the one we ended up choosing (because it gave the most reliable results) is the following:

(SkillGroup.MySkill.RouterCallsQNow+1)*300/(SkillGroup.MySkill.CallsAnsweredTo5+SkillGroup.MySkill.RouterCallsAbandQTo5)

Regards,
Geoff

[stork]

Thanks Geoff.

One question on the calculation, why are you multiplying by 300?  Is this just to represent 5 minutes of available agent time for the previous 5 minute window?  

I believe in the CCB EWT calculation they have 20 as the default value for their multiplication.  Just curious.

[geoff]

Are you referring to the "20" we see in the CCB formula like this?

((SkillGroup.%1%.RouterCallsQNow+1) - (ValidValue(SkillGroup.%1%.AvgHandledCallsTimeTo5, 20))

/

Max ( SkillGroup.%1%.Ready, (SkillGroup.%1%.TalkingIn + SkillGroup.%1%.TalkingOut + SkillGroup.%1%.TalkingOther))))

The "20" there is part of the ValidValue() function.

For what it's worth, many formulae were tried, including the CCB one.

Regards,
Geoff 

[stork]

Yes I was referring to the 20 in that formula.  From what I gather from that calculation, if the value of "SkillGroup.%1%.AvgHandledCallsTimeTo5" is not valid, they replace it with 20.  I'm just wondering what that is supposed to represent so I can adjust if needed for our call center.

[geoff]

That value is to protect the formula when the average handled time in the rolling 5 minute window is invalid. This will occur when the call center starts up each day, or if there was a lull of 5 minutes and no calls were answered (unusual).

My guess is you can replace this with what you typically see in your call center - say 180s. But as I mentioned, we found a better way.

Regards,
Geoff 

[stork]

I'll have to give that calculation a try.  Since we currently on Packaged CCE 10.5, there isn't the ability to set "Enterprise Skill Groups".  Currently our tiers for agents for a skill would be something like "mySkill_SG1, SG2, SG3, SG4".

So for the calculation I would need to adjust for this... I believe anyway.  Below is what I think would mimic yours with all of the tiers.

(SkillGroup.CNE_Genesis_SG1.RouterCallsQNow+SkillGroup.CNE_Genesis_SG2.RouterCallsQNow+SkillGroup.CNE_Genesis_SG3.RouterCallsQNow+SkillGroup.CNE_Genesis_SG4.RouterCallsQNow+1)*300
/ ((SkillGroup.CNE_Genesis_SG1.CallsAnsweredTo5+SkillGroup.CNE_Genesis_SG2.CallsAnsweredTo5+SkillGroup.CNE_Genesis_SG3.CallsAnsweredTo5+SkillGroup.CNE_Genesis_SG4.CallsAnsweredTo5)+(SkillGroup.CNE_Genesis_SG1.RouterCallsAbandQTo5+SkillGroup.CNE_Genesis_SG2.RouterCallsAbandQTo5+SkillGroup.CNE_Genesis_SG3.RouterCallsAbandQTo5+SkillGroup.CNE_Genesis_SG4.RouterCallsAbandQTo5))

Or do you see a different way of handling the tiers? 

Thanks again for the advice.

[geoff]

This three-skill one may look a bit strange, but it was vetted and thoroughly tested

(SkillGroup.SG1.RouterCallsQNow+1)*300/(SkillGroup.SG1.CallsAnsweredTo5+SkillGroup.SG2.CallsAnsweredTo5+SkillGroup.SG3.CallsAnsweredTo5+SkillGroup.SG1.RouterCallsAbandQTo5)

Regards,
Geoff

[Chintan Gajjar]

Sharing what we came up with:

we had to deal with more than 9 skill-group to fetch the EWT. we were queuing a call to 9  skil group with successive queue nodes. so what we did was, we had put the call type node right in front of queue node.

and extracted the AvarageHandleTimeHalf, since the call volume on those queues was not so large we decided to use AvarageHandleTimeHalf over the AvarageHandleTimeTo5 from Call Type data.

Once we had Average Handle Time from above in sec, we just extracted the logged on agents from EntSkill and followed the formula of

AverageHandleTime/(LoggedOnAgents*60) for EWT in minutes.

[stork]

Thanks Chintan, I'll try that one as well.  Currently I have 2 calculations in my scripts that are just saving to PVs so I can get an idea of how close the data is.

So far I have these entered in several queue's

Using Geoffs method; (PQ.MySkill.CallsInQ+1)*300/(PQ.MySkill.CallsAnsweredTo5+PQ.MySkill.CallsAbandQTo5)

Using built in function; EstimatedWaitTime()

Both return relatively close results, Geoffs method is a bit higher.  I will test yours as well.  You stated your call volume is relatively low, I don't believe ours is that high for the queue that I am testing this with.  Just ran a report and they received approx. 

I'll try yours as well and see what I get. 

MyCallType.AverageHandleTime/(PQ.MySkill.LoggedOnAgents*60)

I'll let all these run for another week and see what I see in the database.

[geoff]

Great to see that sort of testing. I'll be interested in your results.

Regards,
Geoff

[stork]

Thanks for all the responses but after seeing the results for a week I have decided to use the built-in function for EWT.  It seemed to yeild the closest result to the current wait time.  Either way I guess it just depends on the volume of your call center, below is what I tried. 

• EstimatedWaitTime()
• CallType.MyCallType.AvgHandleTimeHalf/(PQ.MySkill.LoggedOn*60)
• (PQ.MySkill.CallsInQ+1)*300/(PQ.MySkill.CallsAnsweredTo5+PQ.MySkill.CallsAbandQTo5)

I looked in the TCD table for the PQ in question so I could see the results stored in my PVs and then searched the same time fram in the CTHH table so I could see the AvgRouterDelayQToHalf and compare.

Thanks again for the input.

[piyush aghera]

Hello,

Its been an old thread but i could not find any other recent thread regarding EWT, so continuing this one.  Per my testing, if there are no calls in last 5 minutes then built-in EWT function returns -1. And after receiving first call in queue, it starts calibrating its value as traffic grows.  Is this understanding correct ? If so, what could be the best method to calculate EWT on lower traffic PQs.

[david.macias]

I think last year I did another run at EWT and the built in still proved to the best method. So I would continue to use that, but if it yields a -1 then default to the longest call in queue. If neither metrics yield any data then there shouldn’t be any wait time, right? Maybe start by looking to see if there’s anyone available in those queues and then decide if you need to evaluate EWT.

david

[piyush aghera]

Thanks David.. Completely agree that built-in function still wins.. and my problem is that if there are no calls in last 5 minutes, then only it returns -1 on first call after that.  So I can either use longest wait time or default some time like 1 minute whenever -1 returns.  So its not a show-stopper. I just wanted to confirm that does it return -1 if there are no callers in last 5 minutes for a PQ or am I missing something ?

Thanks.