Difference between Estimated Wait time and Average wait time

What is the difference between the estimated wait time for customer in a queue which is obtained as a result of the query /api/v2/routing/queues/{queueid}/estimatedwaittime and the average wait (ASA or Avg Wait) time shown in the report "https://apps.mypurecloud.com.au/directory/#/engage/queues" ?

Both of those values for a particular queue are different by a long way.

Also, Can I get the formula used to calculate both of these values ?

Thanks,
Anil

In the Queues Activity view, the ASA column uses the tAnswered metric. This metric can be retrieved via a conversation aggregate query that is grouped by queue and media type. ASA/tAnswered is a metric that represents factual data about events that have occurred in the past.

EWT is something else altogether and I would expect it to almost always be different than the ASA. The EWT value is calculated based on numerous data points within PureCloud and there are different formulas that may be used depending on the context. EWT is an educated guess about what might happen in the future.

So, if I need to get the time it takes for a customer in a particular queue to be answered by an agent in real time, which metric should I consider EWT or Avg Wait time ?

I can't tell from your question if you're looking for historical data or a prediction of what the wait time might be. But from my previous comment:

ASA/tAnswered is a metric that represents factual data about events that have occurred in the past.

EWT is an educated guess about what might happen in the future.

Hi Tim,

We've noticed there is a big difference between the EWT and the ASA (the EWT is significantly underestimating the waiting time).

Is there a way to configure the EWT for it to give a better prediction?

Thanks,

Ori

I am not aware of any way to configure the EWT calculation.

Hi Tim,

Thanks a lot for you help.

To provide more details on Ori's request and what we are looking for :
We have an In-Queue-Call-Flow in which we want to tell the customer how much time he/she will wait in the queue. We want the "factual" time and not the "predictive" one.

Here is a screenshot of what we are trying to configure :

We are wondering if, instead of the "Call.EstimatedWaitTime" variable (which is predictive), we can tell the client the "ASA" variable that we can see in the queue report screen :

Thanks for your time.

Baptiste.

Sorry, the last image has not been uploaded on my previous post :

EWT is the only such statistic built in to Architect. If you need to play other statistics, like ASA, you would have to build a bridge server integration to call the appropriate Platform API and return the ASA. You would then consume this integration as a bridge server action in Architect.

Thanks Tim for your answer.
Do you know if it is planned in Purecloud backlog to develop availability of other statistics for Architect such as the ASA ?

Thanks for your help.
Baptiste.

1 Like

Ori,

Can you provide some additional details on your experience with using EWT and what you believe you want to be able to tweak on it? As Tim mentioned EWT takes a lot more factors into account like the current volume and amount of interactions in front of a specific interaction to predict how long they would need to wait. Using ASA for these announcements will not make things better in my opinion. The fact that the ASA early in the morning has been 20 seconds doesn't say anything about the ASA when the peak of the day hits. As ASA is updated after a conversation gets connected you can see how this value will be always behind setting expectations. I much rather like us to focus on what you believe is wrong with our current EWT calculation so that we can see what can be done about this.

Thanks,

Jeroen Buis

1 Like

Hi Jeroen,

Thanks for your reply. After a lot of testing we found out why the EWT was giving a much lower estimate than the reality. We've found out that also agents that are off line but are on the active queue are impacting the EWT. We think that also Agents on breaks are impacting it. Only when we put everyone except the people taking calls at that moment on the Inactive queue, the EWT started giving correct estimations.

It will be very helpful, I think, for us and other PureCloud users to know what are the factors taken into account in the EWT so that we can adjust work processes accordingly.

Anyways, this seems to be working fine for us now, we just have to make sure we keep the Active part of the queues clear.

Thanks for your responses and for your help!

Ori

1 Like