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.
You can use routing scripts to divert a call to a Network VRU for additional call processing.
A VRU, or Voice Response Unit, is a telecommunications device, also called an Interactive Voice Response Unit (IVR), that plays recorded announcements and responds to caller-entered touch-tone digits. Cisco Unified Customer Voice Portal (CVP) is the supported VRU for Packaged CCE. A VRU can also be equipped with Automatic Speech Recognition (ASR) or Text-to-Speech (TTS) capabilities.
After you set up VRUs through the Configuration Manager, you can write routing scripts that send calls to the VRU, queue the call, and invoke specific VRU scripts.
You can write routing scripts that send calls to the VRU, queue the call, and invoke specific VRU scripts. VRU scripts are configured using the Network VRU Scripts tool in the Unified CCE Administration tool.
You can send a call to a VRU Unified CVP for further processing by using the Send to VRU node (in the Queue tab of the Palette).
The Send to VRU node is also valid for use with Type 3, Type 5, Type 6, Type 7, and Type 10 VRUs.
When Unified ICM Packaged CCE runs a Send to VRU Node, it looks up the call's Dialed Number, the Dialed Number's Customer, and the Customer’s Network VRU. If that fails to retrieve a Network VRU, the router uses the system default Network VRU.
If the Network VRU is of Type 3 or Type 7, the router sends an instruction to the routing client to connect the call to the Network VRU. The instruction contains the label configured for this Network VRU as well as a correlation ID to allow the router to uniquely identify the dialog with the routing client and the dialog with the VRU PG. The router waits until it receives a RequestInstruction message from one of the connected VRU PGs with the same correlationID as a sign that the call is now connected to the VRU.
If the Network VRU is of Type 5 the router sends an instruction to the routing client to connect the call to a VRU resource. The instruction contains the label configured for this Network VRU. The router waits for a response back from the routing client that the call is properly connected to the VRU resource.
If the Network VRU is of Type 10 (which is typically used only with Unified CVP), the Router uses a two-step transfer. The first transfer is to move the call to the Unified CVP, followed by a second automatic transfer to setup a VRU leg for the call that employs the VXML Gateway or Cisco Virtualized Voice Browser (VVB) for IVR treatment. The purpose of Type 10 VRU is to simplify the configuration needed in the Comprehensive Call flow model.
Important points to note while you are using the Type 10 network VRU are:
For calls originating from Unified CM, the Correlation ID is automatically added to the end of the transfer label defined in the Type 10 Network VRU configuration.
For calls that are front-ended or originating from Unified CVP, only a single automatic transfer from the switch leg to the VRU leg occurs, using the transfer label defined for the Type 10 Network VRU.
For calls originating from all other routing clients like TDM ACD's, other VRU's or NIC's, a "Translation Route to VRU" node should be employed for the first phase of transfer, instead of the "SendToVRU" node without which the calls would fail.
There are two failure cases:
If the label does not exist, script execution continues with control flowing through the nodes failure output terminal.
If Unified ICM Packaged CCE does not receive confirmation, execution continues with control flowing through the nodes failure output terminal.
In all other cases script execution continues with control flowing through the nodes success output terminal.
Notes:
If the Run External Script, Play, Menu, Collect Data, or Queue node is used in a script before a Send To VRU node, an implicit Send To VRU node is assumed. For Network VRUs of Types 3, 5, 6, or 7 yYou do not have to use the Send To VRU node. However, include the node in routing scripts as a visual aid if you ever need to troubleshoot the script.
If the call is delivered to the VRU Unified CVP but then abandoned, script execution ends. In monitor mode, a special label on the Send To VRU node accounts for these cases.
You do not need to set properties for the Send to VRU node. However, you can optionally add comments or connection labels.
You can use multiple Run External Script nodes to run a series of scripts on the VRUUnified CVP.
The Run External Script node is valid for use with all the VRU types.
 Note |
When you integrate the ECE with the Unified ICM, you can also use the Run External Script node to push a URL to the caller's web browser. To do this, an entry in the Network VRU list must point to the URL map file on the ECE. For more information, see the Configuration Guide for Cisco Unified ICM/Contact Center Enterprise. |
If the external script runs successfully, control then passes through the success branch of the Run External Script node.
If the external script does not run successfully for any reason, then control passes through the failure branch of the Run External Script node.
Note |
|
Note |
When an uninterruptible script is used in a Run External Script node, the CallRouter waits for the script result from the VRU. It then runs the next node. Calls can only be routed when they reach an interruptible node. The Wait node and interruptible Run External Script node ( micro apps) are interruptible. Every other node is uninterruptible. |
Following is the Properties dialog box for the Run External Script node:
|
Step 1 |
Select the Unified ICM Packaged CCE Script/External Script Name you want to run. |
|
Step 2 |
Optionally, add comments and connection labels. |
The following table lists the possible values for the VruStatus variable:
|
Value |
Meaning |
Description |
|---|---|---|
|
0 |
VRU_SUCCESS |
The last VRU node was successful. |
|
1 |
VRU_ERROR |
The last VRU node failed because of a routing or configuration error. |
|
2 |
VRU_TIMEOUT |
The last Send To VRU or Translation Route to VRU node failed because the routing client did not respond within 20 seconds or the last Run External Script node failed because the timeout limit defined for the script expired. |
|
3 |
VRU_ABORTED |
The last VRU node did not complete because the caller ended the call or stopped responding. (Because this causes the routing script to terminate immediately, this value is never seen.) |
|
4 |
VRU_DIALOG_ FAILED |
The last VRU node failed because communication with the VRU ended unexpectedly. |
|
5 |
VRU_SCRIPT_ NOT_FOUND |
The VRU failed because the referenced VRU script was not found in the Unified ICM Packaged CCE configuration. |
|
6 |
STATUS_MAX_QUEUE_LIMIT_EXCEEDED |
The last node failed because the maximum call queuing limit was exceeded. |
|
7 |
STATUS_NO_VALID_EXPRESSION |
The last node failed because no valid expression was found. |
|
8 |
STATUS_NO_VALID_TARGET |
The last node failed because no valid target was found. |
|
10 |
STATUS_NO_MRD_MATCH |
The last node failed because no targets matched with the Media Routing Domain on the call. |
|
11 |
STATUS_CONSIDER_IF_FAILED |
The last node failed because the Consider If expression failed on all targets. |
|
12 |
STATUS_NO_VALID_PERIPHERAL |
The last node failed because none of the targets were configured on the supported peripheral. |
|
13 |
STATUS_NO_ONLINE_PERIPHERAL |
The last node failed because all targets are on peripherals that are offline. |
You can queue a call at a Network VRU until a specific resource becomes available. A call can be queued for one or more skill groups, an enterprise skill group, or a precision queue, or one or more scheduled targets. As soon as an agent becomes available at one of the specified targets, the call is removed from the queue and sent to the target.
Specifically, you can:
Place a call in a precision queue.
Place the call in one or more skill groups, an enterprise skill group, or one or more scheduled targets.
Adjust the priority of call in a queue for one or more skill groups or scheduled targets.
Remove the current call from any queues to which it is assigned.
Call Flow:
The call is first sent to the Network VRU. This step is required before you queue the call.
The call is queued for three skill groups.
If the call is successfully queued, the script cycles between a Wait node and a Run External Script node so that the caller hears an announcement every 30 seconds.
If an agent in one of the skill groups becomes available, the call is removed from queue and taken back from the a VRU Unified CVP. Routing script execution ends and the call is delivered to the target.
You could use other nodes like Queue to Skill Group or Queue to Precision Queue to queue the calls to different targets.
 Caution |
Do not use the nodes like Route Select to queue the calls when the script cycles between a Wait node and a Run External Script node. |
Note |
In this scenario, you would likely make the VRU script interruptible so that the routing script can retrieve the call immediately when the resource becomes available. |
If an agent becomes available in one of the skill groups, the call is routed to that resource.
Note |
If the current call is not at a Unified CVP when the Queue node runs, Packaged CCE sends the call to the associated Network VRU. (This does not apply to Type 2 VRUs, which are VRUs at customer premises.) |
The Queue node includes a Priority field, which sets the initial queuing priority for the calls processed through this node versus other calls queued for the same target. The priority is expressed as an integer from 1 (top priority) to 20 (least priority). The default value is 5.
If more than one call is queued to a group when an agent becomes available, the queued call with the lowest priority number is routed to the target first. For example, assume an agent in a skill group becomes available and two calls are queued to that skill group. If one call has priority 3 and the other has priority 5, the call with priority 3, the lower value, is routed to the skill group while the other call continues to wait.
Note |
The Queue node does not actually result in instructions being sent to the VRU. When queuing occurs the Queue node exits immediately through the success branch and the call is assumed to be at the VRU; the script should then continue with a Run External Script node to instruct the VRU what to do while holding the call until an agent to becomes available. Typically this would invoke a Network VRU script that plays music-on-hold, possibly interrupted on a regular basis with an announcement. |
Following is the Properties dialog box for the Queue node:
|
Step 1 |
To change the queue type: |
|
Step 2 |
To add targets:
|
|
Step 3 |
Optionally, continue defining Target Type information for the Route (Drop-down list) member. This is the route to send the call to when an agent in the target type becomes available. (The drop-down list includes all routes associated with the target.) |
|
Step 4 |
Optionally, add connection labels. |
Note |
When processing a Queue node, the router first checks for an available target, if there is none available then the router attempts to queue the call. The call does not move to the VRU if there is an available agent. |
You can use the Precision Queue script node to queue a call or task based on caller requirements until agents with desired proficiency become available. This node contains multiple agent selection criterion which are separated into steps.
A single call can be queued on multiple precision queues. If an agent becomes available in one of the precision queues, the call is routed to that resource. You cannot reference multiple precision queues with a single Precision Queue node. However, you can run multiple Precision Queue nodes sequentially to achieve this.
The Precision Queue node includes a Priority field, which sets the initial queuing priority for the calls processed through this node versus other calls queued to the other targets using different nodes. The priority is expressed as an integer from 1 (top priority) to 20 (least priority). The default value is 5.
If more than one call is queued to a precision queue when an agent becomes available, the queued call with the lowest priority number is routed to the target first. For example, assume an agent in a precision queue becomes available and two calls are queued to that precision queue. If one call has priority 3 and the other has priority 5, the call with priority 3, the lower value, is routed to the precision queue while the other call continues to wait. If the priorities of the two calls are same, then the call queued first is routed first.
VRU script instructions are not sent to the VRU. If a call enters the Precision Queue node and no resource is available, the call is queued to the precision queue and the node transfers the call to the default VRU, if the call is not already on a VRU. The script flow then exits immediately through the success branch and continues to a Run External Script node to instruct the VRU what to do while holding the call until an agent becomes available. Typically, this invokes a Network VRU script that plays music-on-hold, possibly interrupted on a regular basis with an announcement. The script flow can also use other queuing nodes to queue the same call to other targets, for example, Queue to Skill Group and Queue to Agent.
The following list describes the Precision Queue Properties dialog box for a static precision queue script node.
The following property is unique to static precision queues:
Drop-down list—To route calls that enter this node to a static precision queue, you must select a precision queue from the list.
The following properties are common to static and dynamic precision queues:
Select Precision Queue radio buttons—You can select one of the following options for each a precision queue:
Statically—Select this option to choose a single precision queue to be selected for all the calls that enter this node.
Dynamically—Select this option to select a precision queue on a call-by-call basis based on a formula.
Note |
The dynamic precision queue option is enabled only for System Administrators. For other users, this option is disabled. |
Priority selection—To select the initial queuing priority for calls processed through this node, you can select from 1 to 20. The default is 5.
Enable target requery check box—To enable the requery feature for calls processed through this node, select this check box. When a requery occurs, for example if a call is presented to an available agent and the agent does not answer, the script continues through the failure terminal. The script can then inspect the call variable RequeryStatus to determine what to do next. The typical action in case of a No Answer is to queue the call again to other precision queues, and increase the priority so that it is taken out of the queue before regular queued calls.
Wait if Agents Not Logged In check box — When this check box is selected and the agents who are associated with a step are not logged in, then the router will wait for the time that is configured for that step. When this check box is not selected, the router will not wait on any step. However, on the last step, the router will wait indefinitely irrespective of the selection.
The following list describes the Precision Queue Properties dialog box for a dynamic precision queue script node.
Use dynamic precision queues when you want a single routing script for multiple precision queues (for example, when the overall call treatment does not vary from one precision queue to another). Dynamic precision queues can simplify and reduce the overall number of routing scripts in the system.
Note |
The dynamic precision queue option is enabled only for System Administrators. For other users, this option is disabled. |
The following properties are unique to dynamic precision queues:
Find By radio buttons—To dynamically route calls that enter this node to a Precision Queue name or ID, use the Find By radio buttons.
Precision Queue Name radio—Select this option to dynamically route calls that enter this node to a Precision Queue name.
Precision Queue ID—Select this option to dynamically route calls that enter this node to a Precision Queue ID.
Formula Editor button—To determine to which Precision Queue name or ID to route calls that enter this node, click the Formula Editor button to create a formula. The formula is then evaluated at run time to select a precision queue by either name or by database ID. For example, you can use the formula "Call.PeripheralVariable4" to look up the Precision Queue if call variable 4 contained the Precision Queue name, as a result of a database lookup or from Unified CVP call processing.
Note |
The section on static precision queues describes the properties that are common to static and dynamic precision queues. |
Precision queues internally are configured with one or more time-based steps, each with a configured wait time. After a call is queued, the first step begins and the timer starts. This occurs although the path of the script exited the success node and a new node may be targeted (for example, Run Ext. Script).
If the timer for the first step expires, control moves to the second step (assuming one exists), and so on. As long as the call remains in queue and there are steps left to perform, the call internally continues to move between steps regardless of the path the call takes after it leaves the precision queue node. If a call is queued to two or more precision queues, the call internally walks through the steps for each precision queue in parallel. After the call reaches the last step on a precision queue, it remains queued on that step until the call is routed, abandoned, or ended.
If there is an update to the precision queue definition, then all queued calls in the precision queue are re-evaluated and are re-run from the first step.
For example, consider the wait time for an ongoing call at step 1 to be 1080 seconds, of which 1000 seconds has already elapsed. Now, suppose the wait time is changed to 900 seconds, then the wait time for this call is also reset to 900 seconds, even though only 80 more seconds are left to move to the next step.
You can override the priority of a call in queue set by the Queue node by using the Queue Priority node (in the Queue tab of the Palette).
For example:
The original priority of the call in queue is set by the Queue to Skill Group node or the Precision Queue node.
The call waits in queue for 20 seconds while the caller listens to an announcement.
Call control passes to a second Wait node.
If 20 more seconds pass without an agent becoming available, the Queue Priority node is run and raises the call's priority in queue.
Notes:
Only use the Queue Priority node after a Queue to Skill Group node or a Precision Queue node. Any subsequent use of the Queue to Skill Group node or the Precision Queue node results in setting the queue priority back to the original setting for that node.
The Queue Priority node sets the priority for a call within all queues that the call is placed in. If a call requires the priority to be raised in one queue only, you should use a subsequent Queue to Skill Group or Precision Queue node for only that skill group/queue (with the new priority).
Queuing priorities should be handled very carefully. Just increasing Queue priority does not get a call handled sooner. The effect depends on the other call in the queue. For example, if all calls are treated using the example above, the priority increase has no net effect. If the script above is only used for the Platinum customers while the Standard customers script leaves them at the default priority level, the effect is that all Platinum customers that have been in queue for more than 20 seconds are handled first regardless of other customers in queue. As the delay for Platinum customers is greater than 20 seconds, no Standard customers are handled ever. The solution is to increase the priority level for Standard customers as well, but only after they have been in queue for a longer period, for example 3 minutes.
Following is the Properties dialog box for the Queue Priority node:
You do not have to define properties for the Cancel Queuing node. You can optionally add comments or connection labels.
You can halt script execution for a specified number of seconds by using the Wait node (in the Queue tab of the Palette).
The Wait node simply stops script executing for the specified number of seconds. In the meantime, the Network VRU is waiting for instructions.
 Warning |
You must set protocol time-out variables in the VRU system to a value greater than the longest wait node used in the script. |
Warning |
You must set protocol time-out variables in Unified CVP to a value greater than the longest wait node used in the script. |
Following is the Properties dialog box for the Wait node:
Define Wait node properties as follows:
|
Step 1 |
In the Timeout in field, specify an interval to wait, in seconds. |
|
Step 2 |
Optionally, add comments or connection labels. |
Feedback