cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
279
Views
5
Helpful
5
Replies
Beginner

Queue to Skill Group Node Failure

Is there a reason why a call would take the failure path on a Queue to Skill Group node? We have random calls hanging on hold for way longer than they should and I'm thinking it's the ones that take this path, which seems to happen for 10% or fewer of our calls into this script. Curious what would ever cause a call to take that path and how I might be able to fix that so it doesn't happen again.

 

Info: PCCE version 11.6.1

There are no "consider if..." arguments. 

 

Fail Path.jpg

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Rising star

Re: Queue to Skill Group Node Failure

So a call is going down the failure path of your Queue to Skill Group node because the call is triggering one of seven requery status variables. 

Requery Status VariableDescription
REQUERY_ANSWER (0Script ends. The call was successfully sent to the chosen target.
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node.
REQUERY_ROUTE_SELECT_FAILURE (1)Routing client generated an error code from ReRouteReq msg indicating a Route Select failure.
REQUERY_CALLED_PARTY_BUSY (2)Routing client generated error code from ReRouteReq msg indicating the called party is busy.
REQUERY_NO_ANSWER (3)Routing client generated an error code from ReRouteReq msg indicating no answer.
REQUERY_ERROR (4)CallRouter generated an error code. The attempt to send the call to target failed because the target was not reachable (i.e., busy, ring no answer).
REQUERY_TIMED_OUT (5)The attempt to send the call to a target failed because the Routing Client did not respond within the DivertOnBusyCallTimeout period. The script ends
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node.
REQUERY_ABORTED (6)The attempt to send the call to a target failed because the caller hung up or the call was lost. In the case of ABANDON and DISCONNECT, the CallRouter assumes the call has ended and ends the script. The RequeryStatus value is set to 6, indicating REQUERY_ABORTED.
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node.

 

When it comes to requery status, it's almost always a RONA (3). But to know for sure, you can edit your script with seven IF nodes checking to see if Call.RequeryStatus==0, Call.RequeryStatus==1, Call.RequeryStatus==2... all the way to 6. One of those IF nodes will get the call and go out the success branch... let us know which one it is.

View solution in original post

5 REPLIES 5
Rising star

Re: Queue to Skill Group Node Failure

I'm curious to know what that next node is that's going from the Queue to Skill Group node. Is it an IF node that's checking for requery status?
Beginner

Re: Queue to Skill Group Node Failure

Correct.

Highlighted
Rising star

Re: Queue to Skill Group Node Failure

So a call is going down the failure path of your Queue to Skill Group node because the call is triggering one of seven requery status variables. 

Requery Status VariableDescription
REQUERY_ANSWER (0Script ends. The call was successfully sent to the chosen target.
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node.
REQUERY_ROUTE_SELECT_FAILURE (1)Routing client generated an error code from ReRouteReq msg indicating a Route Select failure.
REQUERY_CALLED_PARTY_BUSY (2)Routing client generated error code from ReRouteReq msg indicating the called party is busy.
REQUERY_NO_ANSWER (3)Routing client generated an error code from ReRouteReq msg indicating no answer.
REQUERY_ERROR (4)CallRouter generated an error code. The attempt to send the call to target failed because the target was not reachable (i.e., busy, ring no answer).
REQUERY_TIMED_OUT (5)The attempt to send the call to a target failed because the Routing Client did not respond within the DivertOnBusyCallTimeout period. The script ends
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node.
REQUERY_ABORTED (6)The attempt to send the call to a target failed because the caller hung up or the call was lost. In the case of ABANDON and DISCONNECT, the CallRouter assumes the call has ended and ends the script. The RequeryStatus value is set to 6, indicating REQUERY_ABORTED.
NOTE: This variable is used internally by the CallRouter. You cannot test for this variable in an IF node.

 

When it comes to requery status, it's almost always a RONA (3). But to know for sure, you can edit your script with seven IF nodes checking to see if Call.RequeryStatus==0, Call.RequeryStatus==1, Call.RequeryStatus==2... all the way to 6. One of those IF nodes will get the call and go out the success branch... let us know which one it is.

View solution in original post

Beginner

Re: Queue to Skill Group Node Failure

I think RONA answers my question actually, now that you mention it. This was a rapid, emergency deployment so we never tested RONA and the agents are pretty new so I can see them letting this happen. After you mentioned that I checked and the requery node was set up so RONA calls would move on into the hold queue rather than requeue to another agent. Thanks! I'll mark this as the solution as soon as I've confirmed.

Rising star

Re: Queue to Skill Group Node Failure

If I can make a suggestion... if the call does RONA, you should send it back to the Queue to Skill Group node to attempt another agent. I've attached a screen shot to show

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards