Expand all | Collapse all

Estimated Wait Time Calculation

  • 1.  Estimated Wait Time Calculation

    Posted 01-07-2019 15:18
    In PureCloud documentation, it states that Estimated Wait Time (EWT) uses metrics from the "previous week down to the half hour interval from the current queue."  Is it really in the best interest of a caller to hear their EWT based on the previous 7 days worth of activity?  Is there any way this could be shortened to the "previous XX intervals" or perhaps the "previous XX calls"?

    Or, can someone help me understand?  I'm not sure I quite get the logic of an EWT Variable based on 7 days worth of calls in a contact center.


  • 2.  RE: Estimated Wait Time Calculation

    Posted 01-09-2019 05:35
    As i understand it, the EWt is calculated like this:
    avarage handle time (for calls in the last seven days) * position in queue / available agents * ( 1 - abandon rate)

    aht: 50s
    position in queue: 10
    agents on queue: 5
    abandon rate: 2%

    (50 * 10 / 5) * ( 1 - 0.02)
    = 100 * 0.98
    = 196 seconds

    Thomas Karlshoj
    HI3G Denmark ApS

  • 3.  RE: Estimated Wait Time Calculation

    Posted 01-09-2019 09:18
    Correct.  The previous 7 days.

    If I call into a call center Wednesday morning at 10:00 AM, why should anything that happened the previous Thursday, Monday's off hours, or over the previous weekend be impacting the EWT I hear as the caller?  Call center traffic is constantly changing.  Media types are prone to remain in queue waiting on an agent, or even remain in queue connected to agents for prolonged periods of time (think Callbacks and Emails).

    Again - what is the logic of taking into account those metrics for the previous 7 days worth of activity?

    Would it not be more accurate to allow a customer, through the EWT tool in Architect, to determine how many previous intervals to base this information on?  Or how many previously connected interactions?  Or better yet, just have the EWT tool in Architect look at the previous 30 or 60 minutes OOB?

    PureConnect and PureEngage function this way.  Most competitors function this way.  And the incumbent systems we are replacing with PureCloud for our customers function this way.

    Trent Vance

  • 4.  RE: Estimated Wait Time Calculation

    Posted 01-09-2019 10:31


    I am part of the team that build the EWT api. You are absolutely right that there are some cases where more recent data point give a better estimate on the handle time. We mainly chose a week to capture the average to smooth it out over different time period of the day, i.e. beginning and end are usually very hard to predict using recent data.  

    Let us know if the result of the current EWT is not accurate based on your observation, and we can take a look and see what's affecting it. As far as being able to change the interval of aggregation of those metrics, at the moment this is not being supported at the individual customer level.

    That being said, we are putting in some effort in enhancing all of the data we use for calculating EWT with machine learning and AI tech. That's in the roadmap as part of the overall enhancement to EWT. This will take in all the pattern and behavioral changes (time of the day, day of the week, recent fluctuation, system load) into account when calculating EWT and make it that more accurate.

    Wei Xun Ter
    Genesys - Employees

  • 5.  RE: Estimated Wait Time Calculation

    Top 25 Contributor
    Posted 01-09-2019 11:24
    @Wei Xun Ter I know that recently we had issues with a large client over the holiday season, they had peek calls these days where wait times were over an hour, and the EWT was telling customers that it was 12-14 minutes.

    Angelia Harper

  • 6.  RE: Estimated Wait Time Calculation

    Posted 01-10-2019 16:33


    Would love to dig deeper into this. Have you created a care ticket for us to look at. Keeping in mind that there's a lot of moving pieces to consider too when it come to a longer than expected Estimated Wait Time. Currently the system doesn't predict if an agent or more is going to be taken out from the queue, in this case for example a initially predicted EWT would be shorter than what the actual wait time will be with less staff.

    If you have the reports, you can check if the AHT for the hour or day is significantly different from others. If not, most likely there's other factor that's in effect. 

    Going back to my original comment, we are working on a better solution that would also incorporate agent going in and out of queue, and availability probability of agents that serve multiple queue on a specify queue, etc.


    Wei Xun Ter
    Genesys - Employees

  • 7.  RE: Estimated Wait Time Calculation

    Posted 13 days ago
      |   view attached
    Hi Wei,

    I have recently had discussions with our service partner around Estimated Wait time and I have done some significant work in comparing the EWT from the previous 7 days and graphed this against the TACD time. Now I know that TACD is not the be all and end all, however, if a customer hears an estimated wait time of 5 minutes and their actual TACD time is 20 mins, there is something not right. I am very keen to hear of the work you are doing in this space and I am happy to assist you wherever I can.

    The answer I received from logging this was: 

    'This appears to of been working as expected and I will list the reasoning. EWT is generated based on the previous weeks analytics data down to the half hour interval (this is not configurable). EWT uses the following analytics metrics in its calculations: (tHandle, tAcd, tAbandon, tTalk, nOffered). All of these factor into the calculation for EWT and again it uses the data that went through this queue exactly one week previously, not the current day. So while the agents in each queue may be very similar or the same, that is not the determining factor.'

    The attachment outlines two different comparison periods:

    1. I have done a comparison between 07/01/19 & 31/12/18 given the advice received (I believe) was that EWT is based on the previous week/interval data and takes into account the wait time, abandon and handle/talk time of that previous week interval to estimate the likely EWT in this interval. I know this is a very simple explanation for a complex algorithm but I would like to draw your attention to the attached and below. I have isolated this down to one hour for comparison purposes.


    1. I have graphed the EWT verse TACD for 07/01/19 and you will see that the TACD is significantly higher than the EWT (Tab comp 0701vs3112)
    2. I have compared in a side by side graph the EWT for 07/01/19 versus the TACD and AHT for 31/12/18 for the same time frames – 10:30am to 11:30am and the correlation does not make sense to me. For example, the EWT calc remains relatively flatlined from 10:30 – 11:08 where as our AHT and TAcd for this day is peaky. The EWT from 11:08am  increasing from this flat line I can sort of see why, but would expect greater EWT given the pressure seen on Tacd and THandle (Tab comp 0701vs3112)
    3. If the previous week is actually used; technically the EWT should not work on 08/01/19 as the previous week was a public holiday with no data. (Tab Comp 080119)
    2. I have run another comparison between 140119 and 210119 and the results are similar to my earlier comparisons. Please see the attached graphs focussing on the day and two timespans 10-11am and 1:15pm – 2:15pm. (Tab 1401 Verse 2101). I know that TACD is not the only measure, but customers on average are waiting 5-10 minutes more that the EWT calculation.

    I can see some correlation in terms of patterns when looking at the EWT on 21 versus 14 (TACD/AHT) in terms of a general pattern, specifically when considering only the EWT on 21/01 versus ACD on 14/01 , but the EWT is out for the majority of the day (start and end seems OK) specifically when considering the TACD and AHT.

     To put this into perspective from a customer (just one example): Example Call: f58010cd-f315-4f75-b948-057bbff55f96 TACD 21:50, EWT 13M44s, customer heard EWT of 'about 15 mins' because of our round up 5 mins intervals but waited almost 22 mins

    An example from today is eab81e97-b3ee-4c9c-bc41-3d878efc8574, TACD 20:31, EWT PT2M11S, customer heard EWT of about 5 minutes.

    Please feel free to reach out to discuss.


    James Ross
    Fair Work Ombudsman



    EWT in queue cleansed.xlsx   1.33MB 1 version