A place to ask questions, connect with others, and stay in the know
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.
Angelia,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.Thanks,
'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.'
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 minsAn example from today is eab81e97-b3ee-4c9c-bc41-3d878efc8574, TACD 20:31, EWT PT2M11S, customer heard EWT of about 5 minutes.
Genesys® powers 25 billion of the world’s best customer experiences each year. Our success comes from connecting employee and customer conversations on any channel, every day. Over 10,000 companies in 100+ countries trust our #1 customer experience platform to drive great business outcomes and create lasting relationships. Combining the best of technology and human ingenuity, we build solutions that mirror natural communication and work the way you think. Our industry-leading solutions foster true omnichannel engagement, performing equally well across all channels, on-premise and in the cloud. Experience communication as it should be: fluid, instinctive and profoundly empowering.