UCCX redirect call when the connect to the agent fail

[epasqualotto]

Hi all, I want to redirect a call to another number when the first agent (and the only one in my case) don't answer after N seconds.

I put the redirect on a failed case under "connect to resource" but seems the script skip this failed step because the call is queue again.

Anyone have a works example that use a failed operation when an agent don't answer?

Thanks

[Andrew Skelly]

It sounds like you have it setup the right way.  Can you attach a screenshot of the Select Resource step and its properties?

[epasqualotto]

The step: set connect_fail and switch are never used. After fail the call goes to: Select resource again

[Andrew Skelly]

If you are looking to queue the call to one specific agent, under "Select Resource" instead of using a Routing Type of "Contact Service Queue", instead use "Resource".  You can the specify the resource you want the call to go to.  Set the timer to X number of seconds and if the call fails, then use the redirect step.

The way you have it now, you have the Call Redirect step under the "Selected" portion of the "Select Resource" step.  It should go under the "Queued" leg.  By leaving it the way you have it now, the call will only redirect if the call fails during the "Connect" step.  It doesn't mean it will redirect if the agent is not available (that would be the "Queued" leg).

[Maic Naatz]

Six years later the same behavior on 8.5.1 SU3. The steps after the  failed portion of the connect step are never used. This seems to be a  bug.

[Aaron Harrison]

Hi

I would suggest if you believe this is a bug that you raise a TAC case. This is quite an unusual way to use the system so hoping someone else raises the case might not bear fruit.

TAC can be a little obstructive with these cases and try to tell you that 'scripting problems are not supported by TAC' or some such.

What you need to do is:

1) Produce the most simple script possible that demonstrates the issue. E.g. in this case a simple start/accept/select with a simple step such as goto under each branch of select that directs the script to a different point.

2) Point TAC at the step documentation, point out what happens that is different to that documentation, and ask them to explain why that particular step does not do what the docs say.

3) Don't take 'we don't support scripting' for an answer :-)

Aaron

[Anthony Holloway]

Hey Aaron,

I am very familiar with this functionality of the scripting, and it's not a defect, but a design decision.

The Select Resource Step has the ability to pull the caller back to itself, in other words, interrupt the call flow, to connect them to an available resource.  This is why you can set some steps to be, or not to be, interruptible.  This design aids in the resource selection process, such that, if a resource becomes available, and then does not answer, another available resource can be immediately selected without losing position in queue.  Unlike UCCE, you do not have to manually script this feature by increasing the priority of the caller, and sending them back into queue; UCCX does it automatically.

There is one negative to this design approach as it pertains to trying to manually handle RONA in UCCX:

1. You can only set the interruptible parameter for a single step.  Meaning that, if you had two back to back steps, which were both configured to not be interruptible, as soon as the first step is done executing, and before the second step is executed, the script will be interrupted and pulled back to the Select Resource step.

Knowing the above design and limitation, we should now see that between the Connect step and the first step within the Failed branch of the Connect step, whatever it may be, the call flow will be interrupted if there are other available resources, and the next step to be executed will be the Select Resource step.

The only way that one or more steps within the Failed branch will executed is if there are no more available resources in the resource pool.  Some businesses may only wish to script for that specific scenario.  I.e., All resources have been exhausted, and the last resource let the call RNA, send an e-mail, or try another CSQ, etc.

At a minimum, you do need to put a Goto step in the Failed branch, so that when the last resource RNA's, the logic continues with the Queued logic.

Here's a post I made on the subject a while back, complete with a sample script to validate this:  https://supportforums.cisco.com/message/3665460#3665460

We could ask for a feature enhancement to change this behavior, but then it would work just like UCCE, and we would have administrators struggling with RONA, priorities and losing PIQ.  I don't work with UCCE at all, so I'm not sure what it out there in the wild, but my gut tells me RONA is most often scripted to work like UCCX does out of the box.  But my gut could be wrong.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[jeffjengle]

The person I work with had an interesting idea related to getting around the Fail branch of the Connect not being executed when there are more than 1 agents in the CSQ from the Select Resource. He suggested adding a Dequeue step after the Select Resources and before the Connect step. This seems to work exactly the way I want. The fact that the caller looses their place in the CSQ I think is OK, I increment the priority before going back and doing another Select Resource (if needed) to help that situation. Please let me knowif you know if you see any flaws in this approach. Thanks, -Jeff Engle

[Anthony Holloway]

I'm nearly 100% positive you cannot use the Connect step for a Contact which has been dequeued from the very queue you pulled the Selected Resource from.  I'm shocked this even works.  I'll have to do some testing, and reach out to my Cisco contacts for clarificaiton around this usage.

Not too mention, selecting from and then immediately dequeuing in the first CSQ inflates the metrics for that CSQ.  This ruins reporting.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[jeffjengle]

As a follow-up to my post suggesting DeQueuing the call after the Select Resource Step and before the Connect Step. At first glance, it does work, but with additional testing we found that it causes problems with CAD where the Answer Call button stops working, most of the time. My theory is that CAD looses track of the call when it is DeQueued. We tested the exact same script with and without the DeQueuing the call after the Select Resource Step and before the Connect Step, and only had the call answer issue with the DeQueue in the script. As Anthony stated, this is not a good approach.

Jeff Engle

[Anthony Holloway]

Hey, thanks for the follow up.  Truthfully, I never did test this out myself.  But my gut was really just saying "no. no. no way. just no." to the solution, to even have me bother with testing it.  I'm glad you did some testing and confirmed the behavior before widely adopting this method.  And again, thank you for the follow up to the community.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Anthony Holloway]

My reply to Aaron, was also to you, and for that matter to everyone reading this thread.  I am replying to you directly so that you get an alert/notification of my reply.

My reply should show up down below, but here's a direct link just in case:

https://supportforums.cisco.com/message/3836452#3836452

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.