12-06-2019 06:36 AM
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
Solved! Go to Solution.
12-09-2019 02:07 PM - edited 12-10-2019 11:10 AM
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
12-06-2019 06:50 AM
12-06-2019 07:25 AM
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
12-06-2019 07:45 AM
12-06-2019 08:42 AM
12-09-2019 02:07 PM - edited 12-10-2019 11:10 AM
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
12-10-2019 10:32 AM
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
12-10-2019 11:11 AM
12-10-2019 12:58 PM
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
12-10-2019 02:35 PM
12-11-2019 09:20 AM
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
12-11-2019 12:00 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide