UCCX - Reporting Statistic PositionInQueue - Position Increase Communicated to Callers w/No Priority Queuing

[NSutfin]

Hello,

I have an issue where intermittently callers are notified of an increase in their queue position. We are FIFO and are not utilizing priority queuing techniques in any scripts and all CCX reporting shows all calls as PRI1.

Normally callers here "Your position 5...4..3..etc" and progress to the final call in the queue. Occasionally our callers are reporting that they are reported as position x and then during the queue phase are reported as a higher position . i.e. "you are position 3....queue loop, you are Postion 8....You are position 7 .. position 6 etc..."  . How is this possible and how can I track this down?

Thank you and I appreciate any insight you can provide.

-Nathan

[Anthony Holloway]

Is it producible on demand? How often is it happening? Does it only happen to a certain script or queue?

Maybe you simplify the scripting by using the icd.aef default script to prove that it happens in a controlled environment? Or can you share your production script here for us to review, just to make sure you're not doing anything weird in the script?

Have you pulled logs for a time frame

[NSutfin]

Anthony ,

Thanks for the quick reply. It is not repeatable and is reported 5 times a week or so with a call volume of around 2000 calls a week.It is an odd problem that I thought might be impacted by pritort calls coming into the queue. We do not adjust priority in our script which made me ask there any way UCCX can garner priority from another source , say Call Manager or is it only attached when UCCX handles the call? How can I attach the script in this forum, the filters are not allowing me to attach?

-Nathan

[Anthony Holloway]

You can zip the file first, then attach it.

Priorities can only be set with the Set Priority step in the script, so if you're not doing that, then it's not a priority related issue.

Do you have UCCX premium, enhanced or standard?

[NSutfin]

Anthony,

We have UCCX premium and I have attached the script.

-Nathan

[Anthony Holloway · Accepted solution]

I don't know if these items are causing your issue, but they do need to be addressed nonetheless.

Wherever you have a Call Redirect step, the Successful branch should have the Set Contact Info step, marking the call as Handled, and an End step to stop further execution of the script.

You don't need the Set Contact Info under the Connected branch of the Select Resource step, as the system will mark the Contact as handled automatically.

Likewise, the Goto TERMINATE_END step is inappropriate in the Connected branch, because the Contact is already terminated (not in a bad way, just that they are now connected to the Agent and not the CTI port).  Instead use an End step here to stop execution of the script.

You are decrementing and incrementing the PIQ value before playing it.  You might want to remove both of those steps, as they are unnecessary.

You should add in a check for the value -1.  The system will sometimes fail to return a value, for whatever reason, and you'll need to not play a -1 value to the caller.  Something as simple as wrapping your play prompts in an If step which checks for:

If (positionInQueue > 0)

Lastly, since you have Premium, you could track the PIQ value, and if it's ever higher than the previous polling, then send yourself an email with the Create/Send eMail steps.  At this point, I would download all of the MIVR Engine logs to analyze them.  Make sure you have the RMCM and ENG debugging turned on ahead of time.

You would have to store the PIQ in two separate variables to do this, e.g.:

int currentPositionInQueue = 0
int previousPositionInQueue = 0
boolean isFirstLoop = true

currentPositionInQueue = Get Reporting Statistic (--Triggering Contact--, Position in Queue [CSQ] from CSQ IPCC Express)
If (isFirstLoop || currentPositionInQueue <= previousPositionInQueue)
  True
    Set isFirstLoop = false
  False
    /* Send an email with a few details about this call, so we can find it in the logs */
Set previousPositionInQueue = currentPositionInQueue

EDIT: Fixed a typo in the sample script steps

[NSutfin]

Anthony,

Thank you very much for your time and analysis. Adjustments you mentioned and the PIQ metric along with the notifications will give me what I need. I will take that route and ensure the MIVR logging is enable. If the issue crops up again, I have a reference point and can engage TAC. There is not much info on this topic so I do appreciate your help.

-Nathan

[Anthony Holloway]

You are welcome. Sounds like a tricky one to track down. I fixed a typo on the sample script I provided, do double check your programming with the latest edit.

If you were curious, now that you have ENG debugging enabled, I wrote an article on how to follow a call through its scripting steps here: https://community.cisco.com/t5/collaboration-voice-and-video/uccx-viewing-executed-script-steps-via-cli/ta-p/3162231

[NSutfin]

Anthony,

I have another question.

Regarding the example, what is the point of the variable

boolean isFirstLoop = true

 It starts off true, and then becomes a condition in the OR statement

isFirstLoop || currentPositionInQueue <= previousPositionInQueue

At that point, if it is true(which it is), it will be set to false.

Now on the next go around, the isFirstLoop variable is now false which hit the false branch of the if statement and trigger and email.

I am not clear on the point of this variable. Would not using currentPositionInQueue <= previousPositionInQueue as  condition for the alert be enough?

-Nathan

[Anthony Holloway]

Good question! First, when isFirstLoop gets set to False, it will not then automatically cause the If step to fall into the False branch. Because, the idea is that on that first loop, the previous value had not been set yet, but at the end of the first loop it gets set.

E.g., Say PIQ was 5 on the first loop. Then current is 5 and previous remains it's initial value of 0. If I simply compare current <= previous, well then we can see that 5 is not <= 0, in fact, this is the exact problem we are trying to catch. When the current value is higher than the previous value.

Therefore, the boolean allows us to ignore initial PIQ reads, and then only compares the current and prev values on loops 2 and beyond.

One thing to know about Java is its lazy evaluation of conditions. If the condition was (true || false || false || true || false), Java would only look at the very first true, and not concern itself with the rest of the booleans. This is helpful in a number of situations, namely, when you're trying to act on a variable which might actually be null. E.g., (name != null && name.trim().toLowerCase() == "anthony") If I don't do the null check first, Java with throw a NullPointerException when I try to .trim() it.

Anyway, I hope that helped clear it up.

[NSutfin]

Anthony,

Thanks for the info. I figured that loop variable was used to wait a cycle until the other variables initialized such that an accurate measure could taken before the alert. I got it in place and everything is working well. I also added a sessionid and a callerid step to garner info for the email alert. I will let you know how it ages and if I see any callers jump position.Thanks again

-Nathan 

[Anthony Holloway]

Awesome! Good luck with it. Do post back if you figure out what was happening.