Debug IPCC 'Get Reporting Statistic' nested under ACD 'Select Resource'

[Brendan Ord]

Hi all,

I am working on an IPCC queue script, and am having trouble debugging a 'Get Reporting Statistic' which is nested in "Queued" under the 'Select Resource'.

I've attached a screenshot of the script.  Calls successfully queue up, and agent phones ring, so everything other than the reporting statistic is working.  My problem trying to troubleshoot this is that when I do a reactive debug on the script, I can't step down into the nest options under Select Resource.  The call just stays queued with MOH, and agents ring etc.  Is is possible to step through the nested Queued options?

The goal with this script is that every 30 seconds, the caller is played a Menu allowing them to dequeue and go to a Reception handset, or Voicemail.

Not sure where I've gone wrong - as I can't figure out how to properly debug this, or at least see what value gets put into the CallTime integer variable.

Other reporting statistics work.  In the production script, we also have an "Agent's Logged In" stat that we pull, and that works fine.

We are using UCCX11.  We've hit a LOT of bugs along the way so I'm not sure if I've hit yet another one....

Thanks all,

[Deepak Rawat]

First of all, if you want the Queued branch of the script to come into effect then your agents will need to either remain in Not Ready or Logged Out state. As long as there is a single agent available and in a Ready state call will be delivered to that agent. Hence, please check the CSQ that you are setting inside the CSQ variable and ask the agents of that CSQ to either be in a Not Ready or logged out state. Alternatively, you can create a dummy CSQ on UCCX and assign a single agent to that and then change the CSQ in the script to that particular CSQ and can test it that way as well.

The goal with this script is that every 30 seconds, the caller is played a Menu allowing them to dequeue and go to a Reception handset, or Voicemail.

However, the way you have created the script does not really achieve this. What your current If condition states is that if Current Wait Duration is more than 30 seconds route it to XYZ since you have not expanded the If statement I am guessing this. However, did this particular customer had really waited in the queue for 30 seconds. Answer is No, what the Get Reporting step is really providing is the wait duration based on the previous calls handled by this CSQ and does not take the fact into consideration if this caller is waiting for 30 seconds in the queue or not

That being said, you should do something like below in the script instead of using Get Reporting Statistics and do it that way. In the below example, DelayWhileQueued is set for 30 seconds but you can change that to 5, 10 etc as per your requirements:

https://supportforums.cisco.com/discussion/13041491/ccx-siple-script-assistance-place-caller-queue

Regards

Deepak

[Brendan Ord]

Thank you for your prompt reply, Deepak.

I see, firstly, what I was doing wrong in the reactive debug.  This CSQ is indeed, not in production and is just a test queue with a single agent.  That agent, I had in a Ready state and the handset was ringing - so, I assume that while the CSQ is attempting to bridge the call to an agent the script logic doesn't progress to Queued.

I am still trying to understand what statistic the Current Wait Duration reporting statistic is actually getting.  So, it's the Current Wait Duration of the entire CSQ?  If Caller A had been queued for 1 minute, and Caller B came in after and was Queued Caller B will be played the Menu, as the CSQ's Current Wait Time is greater than 30 seconds due to Caller A having been queued for 1 minute?

I understand that I am using it wrong, and I looked at your sample script and it's a much simpler and efficient way to do periodic announcements.

Now, I am going back to my Manager to determine exactly what they were trying to achieve with the original script (we're migrating from CCX6 to CCX11).  Perhaps they were trying to achieve a way to overflow callers immediately should the Queue be quite full (i.e. with wait times longer than 3 minutes).

Thank you for your assistance, I have a better understanding now and now need to revise my understanding of call handling within our CSQ's.

[Deepak Rawat]

Sure Brendan, please get the confirmation from your manager that what exactly they want:

1) That all the callers should wait in the queue for a minimum of 30 seconds before overflow happens

2) As soon as the wait duration comes more than 30 seconds, calls should overflow

Regards

Deepak