The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
After defining how a script is used to categorize contacts, you typically use the nodes available in Script Editor to specify how the contact is to be routed to a target destination. A routing target is an entity to which the system can route a contact, including agents and skill groups. The routing target receives the contact and processes it accordingly.
The following nodes available for agent routing:
Queue to Agent Node. For more information, see Specify an Agent Directly
Agent to Agent Node. For more information, see Transfer Calls from Agents to Agents
The Agent to Agent node routes the call to the specified agent. You define the agent either by directly selecting the agent from the database or by providing an expression using a formula. The expression must translate to agent peripheral number or SkillTargetID. The router then finds a valid label for the agent. If there are no labels configured for the specified agent, the failure node of the Agent to Agent node is executed.
Following is the Properties dialog box for the Agent to Agent node:
| Step 1 |
Choose an option from the Select agent by drop-down list:
|
| Step 2 |
Based on your selection in Step 1, select the peripheral or agent, or enter an expression, as necessary. |
| Step 3 |
Optionally, check or uncheck Fail node if agent is unavailable:
|
| Step 4 |
Optionally, add comments and connection labels. |
You can use the following nodes to stop script processing:
End Node
Termination Node
Release Call Node
You can terminate the script by using the End node in the General tab of the Palette.
If the script reaches the End node, it has failed to find a target for the contact. Packaged CCE then uses the default route for the Dialed Number.
Several End nodes can appear in the same script. The End node is never required; a script can terminate with any node.
You do not define any properties for the End node. You can optionally add comments.
You can terminate the script and disconnect the caller by using the Release Call node in the Targets tab of the Palette.
You can use a Release Call node in situations where the caller needs no further service after executing several Unified CVP scripts.
You do not define any properties for the Release Call node. You can optionally add comments.
ServiceRequested is a call variable available in Script Editor. It provides more details regarding the routing request. The field is currently only set for multichannel routing (Task Routing), voice callback (Agent Request) and Pick/ Pull routing, otherwise it is set to 0. Based on the value of this field, the script can take different actions.
|
Service Requested Variable |
Description |
|---|---|
|
0 = ROUTE_SERVICE_REQUEST_NONE |
No service requested. |
|
1 = ROUTE_SERVICE_REQUEST_VOICE_CALLBACK |
Caller is requesting a voice callback. |
|
2 = ROUTE_SERVICE_REQUEST_TRANSFER |
Transfer a task that is already assigned to an agent back to a queue. |
|
3 = ROUTE_SERVICE_REQUEST_RONA |
A task is being rerouted on no answer (RONA). |
Target Requery is a script node feature that you can use to handle routing failures, for example due to No Answer or Busy responses, or for unreachable targets caused by transient failures in the network (such as network congestion). If the determined destination for a contact is available but not reachable, Target Requery attempts to find a different valid destination.
You need Target Requery to address the following failures:
Failure to deliver a call to an agent.
Failure of the outbound leg of a blind-mode Network Transfer.
Target Requery works on a per call basis; that is, the routing information for one call does not affect the state for other calls. If the first target selected for the contact was not reachable, the target is not eliminated from the potential routing destinations for other contacts.
 Note |
You can enable the Target Requery feature for CVP, ICM to ICM gateway, and a subset of the supported carrier NICs. You cannot use the requery feature with any of the multimedia requests because the MR PG does not support requery mechanism. |
In the system, when queried, the CallRouter returns a label to the routing client. The routing client then routes the call to the destination specified by the label. If the destination is not reachable (for example, because of a busy signal or no answer), the call is routed to the default destination.
With Target Requery in a Label, Route Select, or Select node, if the router fails to route to a target node, a second attempt is made. If the failure occurs a second time, then the router continues from the failure path in the node.
Note |
In a Queue node, just one target is used. If the router fails to route to the target node, the failure path of the node is taken immediately. To implement requery in a Queue node, you can create a script that increases the priority and requeries the call from the failure path to the same queue. |
In the event of a failure, you can handle requerying in the scripting environment, as you deem appropriate.
Target Requery does not require different definitions for different failure cases. However, you can choose to handle different failures differently.
You can test the error path of these script nodes using Target Requery to determine the specific network cause of failure and conditionally retry the attempt as necessary. You can accomplish this using an If node to check the value of the call variable RequeryStatus. The decision path for the script is then determined by the value of the RequeryStatus variable.
The following are possible values for the RequeryStatus variable:
|
Requery Status Variable |
Description |
||
|---|---|---|---|
|
REQUERY_ANSWER (0) |
Script ends. The call was successfully sent to the chosen target.
|
||
|
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_ABORTED (5) |
The attempt to send the call to a target failed because the caller abandoned before the call could be delivered to its destination. In the case of ABANDON and DISCONNECT, the CallRouter assumes the call has ended and ends the script. The RequeryStatus value is set to 5, indicating REQUERY_ABORTED.
|
||
|
REQUERY_TIMED_OUT (6) |
The call attempt failed because the routing client did not respond to the router within the DivertOnBusyCallTimeout period (180 seconds by default). If the target node has Router Requery enabled, when DivertOnBusyCallTimeout period expires, the Router closes the Router Requery with REQUERY_TIMED_OUT .
|
The following nodes support Target Requery:
Label
Queue
Queue to Agent
Precision Queue
Route Select
Select
You define nodes to enable Target Requery. For the Queue, Queue to Agent, and Route Select nodes:
| Step 1 |
Open the node properties. |
| Step 2 |
Click Change. A dialog box opens. |
| Step 3 |
Check Enable target requery. |
| Step 4 |
Click OK to close the dialog box. |
| Step 5 |
Click OK to close the properties dialog box. |
| Step 6 |
For the Label, Select and Precision Queue nodes: For Select nodes:
|
Feedback