VRU Self-Service

About VRUs

A VRU, or voice response unit, also called an Interactive Voice Response Unit (IVR), is a telecommunications device that plays recorded announcements and responds to caller-entered touch-tone digits. A VRU can also be equipped with Automatic Speech Recognition (ASR) or Text-to-Speech (TTS) capabilities.

In Unified CCE terms, the VRU is a device that corresponds to a peripheral and is integrated by means of a PG. A typical configuration consists of a VRU and a PG (or two PG's if duplexed).

A Network VRU supports Unified CCE software's service control interface. A Unified CCE routing script can divert a call to a Network VRU and instruct the VRU to perform specific processing before Unified CCE software determines the final destination for the call. There are multiple Network VRU types, and they are explained in the Scripting and Media Routing Guide for Cisco Unified ICM/Contact Center Enterprise.

There are two VRUs supported by Unified CCE: Cisco Customer Voice Portal (CVP) and Cisco IP-IVR. Because these VRUs support different features and behave differently, reporting data is affected by the type of IVR you have deployed in your system.

Uses for VRUs

Your enterprise might implement one or more types of VRU applications to provide initial call treatment and enterprise queuing.

These VRU applications can be used as follows:

  • In Self-Service applications, the customer can obtain information through a series of VRU prompts, and the entire transaction occurs within the VRU . For example, if the customer calls a bank, the Self-Service application might prompt the user for an account number and password and then provide abilities to check account balance, review recent payments, modify PIN numbers, and so forth.

  • In Information Gathering applications, the VRU prompts the caller for certain information, such as which department the caller wants to reach, and then uses the information in the routing decision and might pass the information to the agent desktop.

  • The VRU is also used to enterprise-queue calls while a customer waits for an available agent. During queuing, the VRU might be configured to play music on hold or perform a VRU application.

VRU Application Reporting

You can use a VRU for a number of different purposes, including queuing, customer self-service, and information gathering.

Impact of VRU Type on Report Data

The types of VRU applications that you use in your enterprise determine what report data you should monitor.

For example:

  • If your VRU performs queuing only, you might want to see how long callers waited in queue and the number of callers who abandoned while queued.

  • If your VRU is used for Self-Service, you might want to see how many successful transactions occurred in the Self-Service application and whether the caller was transferred to an agent from the application.

  • If you are using an Information Gathering application, you might want to see how many callers opted out of the digit collection to be transferred directly to an agent.

Impact of PG Setup Choices on Report Data

When you select a VRU on the Peripheral Gateway Properties page during PG Setup, certain VRU Reporting options affect the data available for reporting:

  • Event Feed

    If you select this option, the VRU PG does not generate real-time trunk and service data update and does not write Termination Call Detail records for each Service Control Interface (SCI) dialogue. The VRU PG still generates real-time peripheral data update.

  • Service Control

    This option is selected by default. This option allows the VRU PG to generate real-time peripheral, trunk and service data updates, and write one or more Termination Call Detail records for each SCI dialogue.

    Selecting this option also enables the Queue Reporting check box. If this box is unchecked, the only events generated for SCI dialogues are Delivered and Cleared and the only call statistic calculated is total call time. If this box is checked, the PG will also generate Queue events. Calculated call statistics will then include queue times and abandons in queue, as well as total call time.

    The Service Control option with Queue Reporting checked generates the most data.

Figure 1. VRU Reporting Options

See the chapter on VRUs in the Scripting and Media Routing Guide for Cisco Unified ICM/Contact Center Enterprise.

Self-Service, Information Gathering, and Queuing VRU Applications

Information gathering VRU applications are used to decide what skill group to queue the call to by walking the caller through a series of voice prompts. The Caller Entered Digits (CED) are passed back from the VRU to be used within the routing script, to decide the optimal skill group to answer the call.

You must be able to determine the following from a VRU service used for information gathering:

  • How many calls traversed the application

  • How long each call remained in the information gathering application

  • How many calls disconnected before being routed to an agent

  • How many calls were eventually routed to agents

Several applications can reside on the same VRU PG. Self-Service and queuing can reside on the same VRU PG, and Information Gathering and queuing can reside on the same VRU PG. This means that all of the applications on that PG belong to the same VRU service.

The VRU service cannot be changed once the call is sent to the VRU. However, the call type can be changed with the Requalify or Call Type node. In the following script, the call type is changed via the Call Type node once it has been queued to separate Information Gathering (CollectDigits) and queuing.

Figure 2. Sample Routing Script for Information Gathering Queuing


Although a service level can be defined for both call types, it is more appropriate to define a service level for the call type that has the Queue to Skill Group node in it.

Calls that disconnect while in the Self-Service or Information Gathering application are considered abandoned calls since both Service Control and Queue reporting must be turned on for VRU Queuing applications. However, you can extract queuing metrics from information-gathering metrics by defining a separate call type for each, and then changing the call type in the routing script.


Note
If the VRU performing Self-Service does not also provide queuing, you can enable Service Control reporting and disable the Queue reporting checkbox. If the caller opts to speak to an agent, then the Self-Service VRU transfers the call to the IP-IVR or CVP that performs queuing, and the call does not appear abandoned from the Self-Service application. This means that the call is considered answered when received by the VRU, not offered. When the call ends, it is counted as handled. If you implement this configuration, reports show the number of calls that were answered and terminated, and time spent on terminated calls.

The following illustration shows how a call moves from the Information Gathering application to the queuing applications.

In this example, 20 seconds will be used to calculate ASA and decide the service level instead of 50 seconds (30 + 20 seconds).

Figure 3. Call Type Data for Calls That Abandon After Call Type Is Changed



Note
If the call abandons before being requalified to the call type that handles queuing, the Call Abandon Wait time is not reset. Therefore, the Abandon Wait time for the information gathering call type starts when the call enters the first call type, and ends when the call abandons, as illustrated below:
Figure 4. Call Type for Calls That Abandon Before Call Type Is Changed


The following table illustrates how some basic metrics are defined at the call type and the IVR service.

Table 1. Self-Service and Information Gathering Application Metrics

Report metric

Call type

VRU service

Skill group

Abandon Wait Time

Starts when a call first enters a call type and ends when it abandons.

Starts when the call enters the service.

Not Applicable

Average Speed of Answer (ASA)

Starts at the first Queue to Skill Group node in the routing script.

Starts at the first Queue to Skill Group node in the routing script.

Starts at the first Queue to Skill Group node in the routing script.

Service Level

Starts as soon as the call enters the call type that has the service level defined.

Starts when the call enters the service.

Not Applicable

Monitoring Self-Service and Information Gathering Application Progress

You might determine the effectiveness of a Self-Service application in several ways:

  • Monitoring the effectiveness of the application as a whole. For example, you might only want to monitor whether a customer's need was satisfied through the VRU application and that the caller did not need to be transferred to an agent.

  • Monitoring the effectiveness of individual transactions within the application. For example, in a banking application a customer might have the ability to perform multiple transactions, such as account lookup, obtaining balance information, and learning about recent payments. You might want to see which of these transactions was used and whether the caller successfully completed the transaction.

  • Monitoring failure cases in which a system error, such as a failed database lookup, caused the caller to be transferred by an agent instead of continuing through the VRU application.

Similarly, you might determine the effectiveness of an Information Gathering application in several ways:

  • Monitoring whether the caller used the system prompts to be routed to an appropriate resource or used a failout path, such as pressing "0", to be routed directly to an agent.

  • Monitoring failure cases in which system errors, such as a failed database lookup, caused the caller to be transferred to an agent instead of continuing through the digit collection prompts for more appropriate routing.

Capturing Script Application Data for CVP

If you deployed Unified CVP as the VRU in your enterprise system, you can use two advanced features to gather more details about a calls' progress through Self-Service and Information Gathering applications. These two advanced features are the capture microapplication and the metadata Exchange Carrier Code (ECC) variable. You can use the details provided by these microapplications only in custom reports; standard reports do not provide this information.

The Capture microapplication enables you to cause a Termination_Call_Detail (TCD) record to be written at any point in the script. This record includes information such as the current call variables, CallRouter call keys, date and time, caller entered digits, and metadata ECC variables.

The metadata ECC variable microapplication captures high-level details about a call's progress through a script. These details include whether the caller is using voice or digit dialing, percent confidence for Automatic Speech Recognition, number of attempts a user made before entering a prompt successfully, number of timeouts, number of invalid entries, microapplication duration, and the routing script used. This information is written to TCD records. If you plan to use the metadata ECC variable, configure the ECC variables in Configuration Manager.

Using the VRUProgress variable, the Capture microapplication, and the metadata ECC variable microapplication together in a script provides you with the ability to monitor details about the transactions performed by the caller and the VRU application's interface to the caller. For example, you could use the Capture microapplication to create a TCD each time the VRUProgress variable changes in the script. The TCD is written for that particular point in the application, which includes the information gathered by the metadata ECC variable. A custom report could show how many callers experienced timeouts at different points in the application, how many attempts callers made before successfully completing a transaction, and how long it took a caller to complete each transaction. This data could indicate problems with the VRU application. You could also run a custom report on an individual call to see how a particular caller used the application and whether they encountered difficulties.

Reports That Show VRU Metrics

This report shows metrics for VRU applications:

  • Unified Intelligence Center IVR Ports Performance Historical Report

Guidelines for Reporting on VRUs

Follow these guidelines when configuring Self-Service applications, Information Gathering applications, and queue applications:

  • If you have Self-Service or Information Gathering IVR applications and want to separate self-service and digit collection metrics from queuing metrics, plan to change the call type in the routing script before the call is queued. This action ensures that you can report on both the self-service/digit collection section of the call and the queuing section of the call using Call Type reports.

  • Plan to enable Service Control and Queue Reporting at the VRU peripheral if you want to report on VRU applications, services, queuing, and trunk groups.

  • Determine the Service Level for the VRU peripheral.

    If the peripheral type is not Aspect, the Service Level defaults to Calculated by Call Center.

    If the peripheral type is Aspect, choose the type of calculation to be performed by default. You can override the default for each individual service.

  • Use the VRUProgress variable in the Set node of the routing script to indicate the status of the call at different points in the routing script. You can set the status to VRU unhandled, VRU handled, VRU assisted, VRU opt out unhandled, VRU script handled, or VRU forced transfer.

    For each transaction in the VRU Self-Service or Information Gathering application for which you plan to change the VRUProgress variable, create a separate call type. In the script, change the call type when a call reaches the end of a transaction and then change the VRUProgress variable. This action enables you to report on each transaction separately using the Call Type VRU Activity reports.

  • Optionally, if you use Unified CVP as your VRU and want to perform advanced custom reporting on VRU application details, configure the following:

    • The Capture microapplication, which you can include in a script to trigger the creation of a TCD record at any point in a routing script. Configure the Capture microapplication as a VRU script; execute the application using the RunExternalScript node. Name the script "CAP" or "CAP, xxx", where xxx is any string that makes the script name unique. For example, CAP, bankingApplication.

    • The Metadata ECC variable microapplication, which collects high-level details about the script application. Configure an ECC variable in the Expanded Call Center Variables configuration tool. The variable length is normally 62 bytes but can be as low as 21 bytes to save space.

    • Use these microapplications in your scripts to trigger TCD creation at points in the script for which you want to capture data. For example, you can capture data when a transaction completes. Use the metadata ECC variable microapplication with the Capture microapplication to capture more details. These details include information about the performance of the script and the customer's experience for each point in the script for which a TCD record is created.

  • There might be cases when a call is not queued, but instead sent to the agent directly (via the LAA Select node) from the VRU. Ensure that the VRU PG is configured correctly. Correct configuration ensures that such a call is considered answered at the VRU service rather than abandoned.

    To do this, set the configuration parameter to /ASSUME_ANSWERED.

  • If you are using IP-IVR as the VRU, set the Configuration parameter in the VRU PG record to /ASSUME_ANSWERED to ensure that calls sent from the VRU to an agent without being queued are reported as Answered.

    With this parameter, calls are counted as successfully connected when the Connect message is sent to the VRU. This prevents calls from being counted as abandoned when a VRU fails to send an Event Report / Answered message in response to a Connect message.

  • Configure services with peripheral IDs that match the information sent from the VRU.

    The peripheral ID that you enter depends on whether you are using IP-IVR or Unified CVP as the VRU.

    • If you are using IP-IVR, you configure a service with a peripheral ID that matches the ID you entered in Application Administration as the post-routing ID. Remember the post routing ID that you configure for use when creating services.

    • If you are using Unified CVP, the peripheral ID that you enter depends on the VRU type.

      If Unified CVP is a routing client that handles new calls (VRU type 5), the peripheral service ID should be 1.

      If Unified CVP receives pre-routed calls (for example, VRU types 2, 3, 7, or 8), the peripheral service ID should be 2.