UCCX Looping between two Contact Centre queues

[cameronjohn1]

Hi All,

I have two Regions with each having there own contact centers

UCCX Region A

Queue A - Agents Not logged In overflow to Queue B

UCCX Region B

Queue B - Agents Not logged In overflow to Queue A

At the moment call bounce between Region A to Region B when no agents logged in. 

Is there anyway to prevent this from UCCX Admin or the script.

Apologies if this have been covered before.

[Roger Kallberg]

You could use a variable that is set when the call is initially send from queue A or B and then evaluate the value of this before you send the call back again to the other queue. Assuming that all is done within one CCX system.

[Ratheesh Kumar]

Hi there

Seems like the config is done from the script side so, definitely possible from the script side. I assume, there will be Get report Stat in the script that determines the status of agents and doing a redirect/overflow to the second queue. Since you mentioned two different call centers, most likely there will be a redirect in script 1 after checking the Report stat of agents, redirect to script 2 triggers. 

A snap shot of existing script should be great for further troubleshooting

Hope this Helps

Cheers
Rath!

***Please rate helpful posts and if applicable mark "Accept as a Solution"***

[Elliot Dierksen]

How are you redirecting the call? If you are doing it via a call redirect, you can check to see if a redirecting party is set. If so, you can code for a "no agents available" or redirect to voicemail. Whatever is appropriate for your business case.

[Thomas G. Johannesen]

When you say 2 region with they own contact centers - are you then meaning 2 ccx clusters ?

If so then I would use http triggers to check for logged in agents on the other cluster before the redirect step.

So customer calls in on "Region A - Queue A".

1. Get reporting stat says no agent logged in "Queue A".

2. Call HTTP trigger on "Region B - Queue B" to check if any agents are logged in there.

3A - No agent on "Region B - Queue B" - No Redirect

3B - Some agents on  "Region B - Queue B" - Do redirect

If "Region A - Queue A" and "Region B - Queue B" is on the same cluster, I would just queue the call in queue B if no agents a logged into Queue A, so the call is queued in both Queue A and Queue B

Hope it make sense

[cameronjohn1]

Thanks for your replies. 

I have two separate clusters with two separate helpdesk queues. 

Below i am forwarding on not available and if the other side is logged out it will go to voicemail. Vice Versa

However this will still loop if both sides are not available. Hard because different time zones but can happen. 

The https triggers sounds interesting but how will that work with two separate systems? 

Script below

[Roger Kallberg]

HTTP triggers should work regardless of separate CCX systems. I’ve never used them, so I’m not in a position to help you with this. Hopefully someone else in the community can lend their assistance with this.

[Thomas G. Johannesen]

The HTTP triggers could work like this:

From Cluster A you make a HTTP request to a HTTP trigger on Cluster B.

That HTTP trigger send back number of agents logged into Queue B. If number > 0 then do the redirect. Else do somehing else.

The HTTP trigger on cluster B will provide you with live data on the Queue B

So before your "Call Consult Transfer" you make to request to the other cluster.

See the HTTP trigger as an extension to the "Reporting Static" step - It make it easy to reach the stats from outside your cluster.

Here is an description about how to set it up

example trigger http CCX 8.5 - Cisco Community

[cameronjohn1]

Hello Thomas, just wondering, how you call the http trigger to query the 2nd UCCX cluster.

1. Create script with agent available logjn and if not available go to voicemiail, else send to otherside CSQ 

2: Create the http trigger and associate it with the script

3. Call the http trigger to pull real-time agent statistic from other side. How is this programmed?

[Elliot Dierksen]

Here is another idea that should be relatively simple. Create two different triggers for your applications (1 new one for each application/queue). The new one should only be used for when one application fails over to the other. Check the dialed number in your script. If it came in via the failover trigger, apply some sort of closed/nobody available treatment. That will keep it from looping.

[cameronjohn1]

Thank you all. I will look into these options. 

Just on the failover trigger. Why would the redirected call come via the failover trigger and not the main trigger. That would also mean when i redirect to the other regions i would point to the failover trigger?

Also would logic be

If transferring_num = 52222 (failover trigger)

True: go to Voicemail

False: go to toCallCenter

[Roger Kallberg]

You define what number that is used for the failover in each of the scripts, so you have control over this yourself for the failover between the two systems.

The logic that you should create is if the call comes in on the failover number and there are no available agents you send the call to voicemail or whatever you see fit. In fact you could also do the reverse, check if the call came in on the normal (main) trigger and if there are no available agents then you send the call to the failover trigger of the other system, otherwise you send the call to the queue handling for available agents.

You should not use the normal (main) trigger numbers for the failover, they should only be used for direct calls to each of the contact centre systems.

[cameronjohn1]

ok thanks. 

So would the logic be like this. 

Site A 

no Agents Available

if redirectNumber = <site B failover number>

True --> Go to Vocemail

False --> Call redirect to Site B

set redirectNumber = <failover number Site A>

call redirect to Site B

Site B

no Agents Available

if redirectNumber = <site A failover number>

True --> Go to Vocemail

False --> Call redirect to Site A

set redirectNumber = <failover number Site B>

call redirect to Site A

[Roger Kallberg]

Yes. To me the definition of failover numbers you use feels somewhat backwards, but as long as it’s logical for you it’s all good.