This document describes the Ring-No-Answer (RONA) feature in Unified Contact Center Enterprise (UCCE) environment in conjunction with two different types of Cisco Interactive Response Unit (IVR) i.e. IP-IVR and Cisco Voice Portal (CVP) ensures that when an agent does not answer a call. For example,
Suppose, you walk away from the desk without making it Not Ready, the call is taken away after ringing for a configurable number of seconds, is then presented to another agent or is put back in a queue and the unanswered agent is put in not ready state.
When a solution of UCCE application is integrated with CVP as a queuing point and routing client, RONA needs to be configured differently than when it is integrated with IP-IVR. The difference is the result of the fact that IP-IVR's call control is with the CallManager, whereas with CVP, the call control is with the CVP.
RONA Operation for UCCE with IP-IVR
This function is implemented by setting a RONA timeout i.e. Ring no answer time in the agent desk settings.
When a call rings for the configured number of seconds, the CallManager PG makes the agent unavailable.
And send a post-route request to the Intelligent Contact Manager (ICM) through a dialed number i.e. Ring No Answer Dialed Number, is also configured in the Agent Desk Settings.
A routing script is executed that determines a new destination for the call. This can be another agent or the script, which can put the call back in a queue.
When using RONA with IP-IVR, the ICM responds back to the CallManager with the new destination for the call. The CallManager is responsible for call delivery to the right destination (IP-IVR for queuing or new agent).
RONA Operation for UCCE with CVP
When you use UCCE with CVP, the CallManager does not control the queuing platform (CVP) and can therefore not send the call back to the CVP for re-queuing. Instead, the CVP controls the call and takes over the re-queue action
The solution is done in two separate steps, i.e. to use the RONA function on the Agent Peripheral only to make the agent unavailable when it does not answer the call and to use the ICM Router re-query function to take the call away from the non-answering agent.
RONA Agent Desk Settings Configuration for CVP Route Re-query
The Agent Desk Settings configuration needs to have a ring no answer time set, but should NOT have a ring no answer dialed number set. The time-out should be set to the maximum time you want to allow the agent to answer a call, for example, 2 rings = 8 seconds. This timer should be set shorter than the no answer time-out for router re-query on CVP.
This causes the agent to be unavailable after the RONA timer expires but does not invoke the RONA mechanism to re-route the call.
Further Lab Testing indicated the re-route still doesn't take place even if the Ring no Answer Dialed Number is configured in the agent desksetting. This is because the queueing point is at CVP with Voice Response Unit Peripheral Gateway (VRU PG) as the routing client, a Dialed Number with callmanager agent PG cannot be used as a routing client.
Router Requery Configuration
Router Requery is triggered by the routing client (the CVP) when a No-Answer-Timer setting (RNATimeout) expires on CVP. After the CVP VB RNATimeout expires the CVP --> VRU PG sends an EventReport = No Answer to the router. The router picks another target according to the routing script and sends the Connect message to the CVP. The target might be another agent or it might be a VRU label to re-queue the call.
The No Answer timer for Router Re-query is not controlled by the ICM, but by the switching fabric, which is the CVP in this case. CVP has a configurable No Answer timer, called RNATimeout. Set the RNATimeout to the desired number of seconds that the agent phone should ring before being taken away. In any case, this timeout should be longer than the RONA time-out set in the Agent Desk Settings.
Enable Requery on the node in the script that selects the first agent. Depending on the type of node used, the Requery mechanism will select a new target from the available agents or requires additional scripting. The ICM Script Editor Guide describes how Requery works for the different nodes.
Router Re-query with Queue Node Example
In most cases, UCCE uses the queue node. The queue node requires additional scripting to handle the re-queuing of the call in front of the queue. This script example provides a standard way of handling this.
The queue node selects the longest available agent from the skill groups configured for an available agent.
If there is no available agent, it queues the call with a priority set in the node (see screen shot below) and continues down the success exit of the node.
When an agent becomes available the ICM always selects the longest queued call from the ones with the highest priority.
When the queue node connects the call to an agent and the agent does not answer the call, the CVP Ring-No-Answer time-out will expire, causing the Re-query mechanism to kick in.
The script immediately continues through the failure exit of the Queue node with the Re-query Status variable set to No Answer (= 3).
The typical treatment is to put the call back into the same queue but with a higher priority than all other calls, since the call needs to go in the front of the queue, not the back.
A Typical Treatment of Re-query Call in the ICM Script with Queue Node
The Scripting Logic
When the queue node selects an agent which does not answer the call, the script exits through the failure exit of the queue node.
The If node tests the RequeryStatus variable.
If it has a value greater than zero, this is a re-query call, and the script re-queues the call.
In the example above it also sets a flag using a call variable for reporting purposes (see below).
Assuming that there are no agents available, the Queue node immediately exits through the success exit.
The If node checks to see if this is a re-queried call.
If so, it increases the Queue Priority of the call so that it is handled before any other calls in the queue.
It then enters the normal wait loop with RunScripts.
The expected RONA Behaviour with Router Re-query
The script connects the call to an agent by sending connect message to CVP (with re-query enabled).
Agent phone rings.
After the RONA timeout expires (agent desksetting RONA) the ICM makes the agent unavailable.
The agent state does not change until the call gets taken away from the agent. The agent phone continues to ring and the agent can still pick up the phone (if the agent does pick up the phone now, the agent is left in Ready state after the call, even if it was after the RONA timer expired).
After the CVP RNATimeout expires, ICM Router re-queue the call.
When the call disappears from the first agent, the agent is put in a Not Ready state.
Further Applications of Router Re-query Script
The same type of script can be used for other situations where the agent does not answer the call.
For example when the network never delivers the call to an agent (because of a network failure for example) or when the agent is busy on another call (this can only happen if the agent received a non-ACD call after the agent had been reserved or if the agent is busy on a non-ACD line appearance on his phone).
In these cases, the router re-query mechanism kicks in as well. The Re-query Status variable will have an indication why this happened (busy or network failure). The call can be re-queued and redelivered in the same way. In fact, the script above does that as the If node connected to the failure exit of the Queue node does not discriminate the various failures.
Reporting Limitation with Router Re-query RONA
The disposition of the re-queried call is not correctly reported.
The Redirect No Answer field in the agent and skill group reports do not show calls that are redirected by this mechanism.
Each call that is redirected by this mechanism is counted twice, once as abandoned and once as handled (if the call is finally handled).
There are two CCE TerminationCallDetail records for this call, one for the rerouted call (with CallDisposition Abandoned while Ringing, code 3) and one for the handled call with a CallDisposition depending on how the call was finally handled.
The scripting example above shows how a Peripheral Call Variable can be used to mark and count calls Re-queried because of no answer. A custom reporting template can be written to report on this data.