" /> StatExpectedWaitingTime in URS, doubt - Genesys CTI User Forum

Author Topic: StatExpectedWaitingTime in URS, doubt  (Read 3543 times)

This topic contains a post which is marked as Best Answer. Press here if you would like to see it.

Offline efrainclg95

  • Jr. Member
  • **
  • Posts: 63
  • Karma: 1
StatExpectedWaitingTime in URS, doubt
« on: June 23, 2018, 08:58:56 PM »
Advertisement
Hello good afternoon, I have a question regarding the EWT statistics (StatExpectedWaitingTime), here my case:

Scenario: I have 4 groups of agents, each agent group has an associated queue (VQ); I have a strategy in composer where I invoke EWT statistics because I want to return the estimated time that the call will be queued, my expression is as follows:

[b]_genesys.statistic.sData (vqueue + '@' + statserver + '. Q', 'StatExpectedWaitingTime')[/b]

Where vqueue is a variable and filled with the alias of the vq: "ATENTO Postpay 100_LimaSwitch"

statserver is my routing service and I fill it with: "StatServer_Routing"

Up there I have my expression ready to fill in the variable EWT estimated waiting time.

Now I have two agents logged into a group of agents, both are not ready, I make the call and in the variable EWT I get the value of 0; in this case because 0 comes to me?

Then, I activate the two agents in Ready, I make two calls and each agent answers the call, at this moment I no longer have an agent available.

Then I make a third call and I see that EWT keeps bringing me 0.

When I make a fourth call here I notice that the EWT brings me values ​​for example the value of 7, I make a fifth call and it brings me the value of 35.

My question is because in the third call the EWT showed me 0?

Could you help me clarify this concept please, maybe I'm doing something wrong or I do not understand this operation well.

I remain attentive, thank you very much.

[i][b]Note: the need I have is that when there are no agents available in any group, calculate with the EWT the estimated time in queue in each group and, depending on the result, derive the call to the best group of agents[/b][/i]

Offline vmc

  • Full Member
  • ***
  • Posts: 112
  • Karma: 0
Re: StatExpectedWaitingTime in URS, doubt
« Reply #1 on: June 23, 2018, 10:26:36 PM »
Seems to me at the third call point there aren't enough running and gathered stats around handle time, prior/current wait time etc to calculate EWT yet.

When the fourth and subsequent calls are made, I assume all previous test calls and released?

Sent from my Redmi Note 3 using Tapatalk

Sent from my Redmi Note 3 using Tapatalk


Offline terry

  • Sr. Member
  • ****
  • Posts: 328
  • Karma: 35
Re: StatExpectedWaitingTime in URS, doubt
« Reply #2 on: June 24, 2018, 03:02:54 AM »
Do you ask StatExpectedWitingTime before or after placing call in queue (invoking <queue.submit>)?

Offline efrainclg95

  • Jr. Member
  • **
  • Posts: 63
  • Karma: 1
Re: StatExpectedWaitingTime in URS, doubt
« Reply #3 on: June 25, 2018, 08:37:47 PM »
Hello Terry,

The expression EWT, I have it in the following way:

_genesys.statistic.sData (vqueue + '@' + statserver + '. Q', 'StatExpectedWaitingTime')

Where:

- [b]vqueue[/b] is the virtual queue and
- [b]statserver[/b] is my routing service

Both are in variables.

I have this in a block before the Target where I set the agent group and the virtual queue.

Is it okay this way?

I am attentive and thank you for your time in helping me understand this case.

Thank you

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: StatExpectedWaitingTime in URS, doubt
« Reply #4 on: June 25, 2018, 08:45:58 PM »
This VQ is configured as Origination DN of the AG, right?
Lima = TdP? :P

Offline efrainclg95

  • Jr. Member
  • **
  • Posts: 63
  • Karma: 1
Re: StatExpectedWaitingTime in URS, doubt
« Reply #5 on: June 25, 2018, 08:54:03 PM »
Hello Cavagnaro

If the VQ is associated with the group of agents, with respect to Lima is the name we have in our laboratory.

Thank you.

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: StatExpectedWaitingTime in URS, doubt
« Reply #6 on: June 25, 2018, 08:55:59 PM »
If? Yes or no?  ???

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: StatExpectedWaitingTime in URS, doubt
« Reply #7 on: June 25, 2018, 09:05:10 PM »
If you do the function without using variables but values from CfgServer itself, do you get any value?

Marked as best answer by victor on June 27, 2018, 12:44:05 PM

Offline terry

  • Sr. Member
  • ****
  • Posts: 328
  • Karma: 35
Re: StatExpectedWaitingTime in URS, doubt
« Reply #8 on: June 26, 2018, 01:01:37 AM »
Basically if you ask for date before placing call in queue the current call (for whom strategy running) is not yet counted.
According statserver formula AHT *CIQU/(AA × EP) the CIQU when strategy run for third call is 0 and accordingly result is 0 too.


Offline victor

  • Administrator
  • Hero Member
  • *****
  • Posts: 1419
  • Karma: 18
Re: StatExpectedWaitingTime in URS, doubt
« Reply #9 on: June 26, 2018, 11:47:38 PM »
[quote author=terry link=topic=11022.msg50114#msg50114 date=1529974897]
Basically if you ask for date before placing call in queue the current call (for whom strategy running) is not yet counted.
According statserver formula AHT *CIQU/(AA × EP) the CIQU when strategy run for third call is 0 and accordingly result is 0 too.
[/quote]


EWT works pretty bad when you have very few calls. The issue is obviously the fact that you actually do not have the call in queue yet.  Plus, it also takes into the account the timeframe - look at your stat - what is the timeframe?

Our practice is to queue the call first and then go to calculate EWT when we had less than 10 calls during the monitored period.

Offline efrainclg95

  • Jr. Member
  • **
  • Posts: 63
  • Karma: 1
Re: StatExpectedWaitingTime in URS, doubt
« Reply #10 on: July 05, 2018, 10:49:24 PM »
Actually when I made some calls the statistics apparently does not work well, but when I have more than 50 calls it is already the exact one, thanks for the support to all, very grateful ...