UCCX - max number of executed steps in Queue loop

[Kim Nielsen]

Hi,

I have a script running at a Hospital, that is hitting some long wait times. I think that we have contacts calling in that is waiting about an hour.

When the contacts is in the queue loop, then I have 2 delays, each 15 sec, so the loop is taking about ½ min each time. One of the thing it is doing, is telling the contact which number in queue they are, and also it is checking if there's still agents ind the queue.  

I think that ½ min is a good amount of time to do these checks. And it is also what the customer have requested.

The problem is that this queue loop consists of about 26 steps, and this gives me about 18 min, that the contact can stay in the loop, before hitting the system parameter "max number of executed steps" default number of 1000 steps.  Therefore we have changed the parameter to 4000 steps.

What do you do to keep it below 1000 steps, if it's an queue that has some long Waits? I find it hard to see any solutions to this problem, unless I set some prety long delays in the queue loop.   

The script is looking like this:

: Queue Loop:

: If (boolPriorityCall) Then

: Call Hold (--Triggering Contact--)

: Delay intQueueWaitTimer01 sec

: Call Unhold (--Triggering Contact--)

: If (boolPriorityCall) Then

: intQueuePositionNow = Get Reporting Statistic (--Triggering Contact--, Position in Queue[strCSQ] from CSQ IPCC Express)

: intAgentsReady = Call Subflow(SCRIPT[COM/NumberOfAgentReadyCheck.aef], intAgentsReady)

: Start

: intAgentTaler = Get Reporting Statistic (Talking Resources[strCSQ] from CSQ IPCC Express)

: intAgentReady = Get Reporting Statistic (Ready Resources[strCSQ] from CSQ IPCC Express)

: intAgentReserveret = Get Reporting Statistic (Reserved Resources[strCSQ] from CSQ IPCC Express)

: intAgentWork = Get Reporting Statistic (Work Resources[strCSQ] from CSQ IPCC Express)

: Set intAgentsReady = intAgentReady + intAgentReserveret + intAgentTaler + intAgentWork

: End

: If (intAgentsReady == 0) Then

: Set intQueuePositionNow = intQueuePositionNow / intAgentsReady

: If (intQueuePositionNow == 0) Then

: If (intQueuePositionNow <= intQueuePosition ) Then

: Set intQueuePosition = intQueuePositionNow

: Switch int ( intQueuePosition )

: Play Prompt (--Triggering Contact--, P[strOrg +"\" +strHovedNummer +"\" + strNumber6InQueue +".wav"] )

: Call Hold (--Triggering Contact--)

: Delay intQueueWaitTimer02 sec

: Call Unhold (--Triggering Contact--)

: Goto Queue Loop

Br

Kim Nielsen

[djlundberg]

Hi Kim-

Increasing the max number of executed steps isn't too big of a deal.  I've seen that done in many contact centers without any issues.

I only see one step that could be reduced which doesn't offer much.  You could make the 'Queue Loop' label part of the boolPriorityCall If statement. 

You might also take a look at the expected wait time or position in queue and if that is greater than some defined value extend the delays to one or two minutes and then check more frequently when the caller has a better chance of being answered.

It sounds like they need to add another staff member to reduce the queue times and provide a better customer experience, but you obviously don't control that.

DJ

[Aaron Harrison]

I always increase the step count. Always. It's really easy to run out of steps even with a basic few checks in the queue loop.

It's there to prevent long running loops due to scripting errors AFAIK. If you do create one of those it will stop at 9999 steps rather than 1000, which probably won't take much longer.

[Anthony Holloway]

Old reply, I know, but I couldn't help myself.

One must consider what is being looped over and over.

I recently saw the following:

Caller disconnected while script was running.  The On Contact Inactive Exception handler at the top of the script said to Go To a label called END.  Label called END was right above the Terminate(--Triggering Contact--) step.  The Terminate step caused a Contact Inactive Exception, and the script jumped up to the END step.  Rinse and repeat, and in about 0.050 seconds the script reached the 1,000 step limit and aborted.  That's really not that bad actually.  A little annoying if ENG debugging is turned on, because all script steps are logged.  But overall, pretty minor.

Imagine instead that a different kind of loop existed, and it was looping HTTP calls, or database reads, etc.  That could not only harm UCCX, but the network and the remote server being connected to.

So, I agree with increasing the step maximum, but do be aware that not all loops are created equal.

[Aaron Harrison]

Nice to hear from you Anthony!

I'd definitely agree that loops can be bad, and that it's totally up to whoever authors the script to test for all these conditions as the results can be at best tricky to troubleshoot and at worst very difficult to recover from depending what's in the loop... but I still think that most of the time you want a longer step window, and that a 1000 unwanted modifications to a DB probably isn't much better than 5000 or 9999 - I'm not going to be manually undoing either :-)

[Anthony Holloway]

A-a-ron, my man!

I wrote a document to help with finding loops.  Well, not exactly loops, but script steps which are executed for a caller.

https://supportforums.cisco.com/document/13050181/uccx-viewing-executed-script-steps-cli

It would be trivial to find calls that are looping, because the call would have been aborted due to max step exceeded, and then you just work backwards in the traces from there.

I do agree with you that in the grand scheme of things, looping is bad, whether 1,000 or 2,000 times, however, what I meant was, looping a DB read 1,000 times is worse than just bouncing 1,000 times between two steps: a Goto and a Label.  Ergo, not all loops are equal.