Precision Routing is
an enhanced routing strategy that you can use as an alternative to, or in
conjunction with, skill group routing. Skill group routing uses predefined
groups. All of the members in the group can handle a particular type of call. A
supervisor manually assigns an agent to the groups for which the agent can
handle incoming calls.
creates attribute definitions, assigns attribute values to each agent, and uses
routing scripts to dynamically find the agents with the necessary attributes to
handle a call. Some example attributes are a proficiency level with a language,
qualification in selling a product, or the location of the agent. By accurately
exposing each agent's skills through this system, you can route the calls to
each agent in ways that bring more value to your business.
identify a call routing requirement, such as language, location, or agent
expertise. Each precision queue can have up to 5 unique attributes, and these
attributes can be used in multiple terms. You can create two types of
attributes: Boolean or proficiency. Use Boolean attributes to identify an agent
attribute value as true or false. For example, you can create a Boston
attribute specifying that the agent is located in Boston. Use proficiency
attributes to establish a level of expertise in a range from 1 to 10, with 10
being the highest level of expertise. For example, a native speaker likely has
a higher value for their language proficiency than a non-native speaker.
When you create a
precision queue, you identify which attributes are parts of that queue and then
implement the queue in scripts. When you assign new attributes to an agent, the
attribute values automatically associate the agent with any precision queue
with matching criteria.
Precision Routing Limitations
Precision Routing is currently available for voice agents only. Precision Routing does not support non-voice media. Precision Routing is available only for Agent PGs on Unified CCE.
Cisco Outbound Option does not support Precision Routing. However, agents who participate in an outbound campaign or non-voice activities (through the use of Skill Groups) can also handle inbound calls from a precision queue.
Precision Routing does not support Unified CVP's Courtesy Callback feature. The complexity of Precision Queues makes calculating accurate Estimated Wait Times difficult. Courtesy Callback depends on Estimated Wait Times. Instead of Courtesy Callback, use nonpreemptive callbacks through the Agent Request interface.
The Agent Greeting feature lets an agent record a message that plays automatically to callers when they connect to the agent. The greeting message can welcome the caller, identify the agent, and include other useful contextual information. With Agent Greeting, each caller can receive a clear, well-paced, language-appropriate, and enthusiastic introduction. This feature saves the agent from having to repeat the same introductory phrase for each call. The feature also gives the agent a moment to review the desktop screen pop-ups while the greeting plays.
Recording a greeting is much the same as recording a message for voice mail. Depending on how you set up the call center, agents can record different greetings that play for different types of callers (for example, an English greeting for English speakers or an Italian greeting for Italian speakers).
By default, greeting play is enabled when agents log in to their agent desktop. Agents can turn greeting play off and on as necessary.
Agent Greeting Phone
Requirements (for Local Agents Only)
Greeting is available to agents and supervisors who use IP Phones with Built-In
Bridge (BIB). These agents are typically located within a contact center.
Phones used with Agent Greeting must meet these requirements:
The phones must
have the BIB feature.
If you disable
BIB, the system attempts to use a conference bridge for agent greeting call
flow and raises a warning event.
The phones must
be running firmware version CM 8.5(1) or greater. (Usually, phone
firmware upgrades automatically when you upgrade your Unified Communications
Agent Greeting does not support outbound calls made by an agent. The announcement plays for inbound calls only.
Only one Agent Greeting file plays per call.
Supervisors cannot listen to agent recorded greetings.
Agent Greetings do not play when the router selects the agent through a label node.
The default CTI OS Toolkit Agent desktop includes the Agent Greeting buttons. If you do not set up Agent Greeting, the Agent Greeting buttons do not execute any functionality. If you use the default desktop but do not plan to use Agent Greeting, you should remove the buttons.
Agent Greeting supports Silent Monitoring (CTI OS and Unified CM-based) with this exception: For Unified-CM based Silent Monitoring, supervisors cannot hear the greetings themselves. If a supervisor clicks the Silent Monitor button in their CTI OS desktop while a greeting is playing, a message displays stating that a greeting is playing and to try again shortly.
Whisper Announcement with Agent Greeting
You can use Agent Greeting with the Whisper Announcement feature. Here are some things to consider when using them together:
On the call, the Whisper Announcement always plays first.
To shorten your call-handling time, use shorter Whisper Announcements and Agent Greetings than you might if you were using either feature by itself. A long Whisper Announcement followed by a long Agent Greeting equals a long wait before an agent actively handles a call.
If you use a Whisper Announcement, your agents probably handle different types of calls: for example, "English-Gold Member-Activate Card,""English-Gold Member-Report Lost Card,""English-Platinum Member-Account Inquiry." Therefore, you may want to ensure that greetings your agents record are generic enough to cover the range of call types.
Whisper Announcement plays a brief, prerecorded message to an agent just before the agent connects with each caller. The announcement plays only to the agent; the caller hears ringing (based on existing ring tone patterns) while the announcement plays.
The content of the announcement can contain information about the caller that helps prepare the agent to handle the call. The information can include caller language preference, choices the caller made from a menu (Sales, Service), customer status (Platinum, Gold, Regular), and so on.
After you enable Whisper Announcement, you specify which announcements to play in the call routing scripts. The script determines which announcement to play based on various inputs, such as the dialed number, a customer ID look up in your customer database, or selections the caller made from a VRU menu.
You store and serve your Whisper Announcement
audio files from the Cisco Unified Contact Center Enterprise (Unified CCE)
media server. This feature supports only the wave (.wav) file type.
The maximum play time for a Whisper Announcement is subject to a timeout.
Playback terminates at the timeout regardless of the actual length of the audio
file. The default timeout is 15 seconds. In practice, you may want your
messages to be much shorter than that, 5 seconds or less, to shorten your
Whisper Announcement with Transfers and Conference Calls
When an agent transfers or initiates a conference call to another agent, the second agent hears an announcement if the second agent's number supports Whisper Announcement. In the case of consultative transfers or conferences, while the whisper plays, the caller hears whatever normally plays during hold. The first agent hears ringing. In the case of blind transfers, the caller hears ringing while the whisper announcement plays.
Whisper Announcement Functional Limitations
Whisper Announcement is subject to these limitations:
Announcements do not play for outbound calls made by an agent. The announcement plays for inbound calls only.
For Whisper Announcement to work with agent-to-agent calls, use the SendToVRU or TranslationRouteToVRU node before you transfer the call to the agent. Transfer the call to Unified CVP before you transfer the call to another agent. Then, Unified CVP can control the call and play the announcement, regardless of which node transfers the call to Unified CVP.
Announcements do not play when the router selects the agent through a label node.
CVP Refer Transfers do not support Whisper Announcement.
Whisper Announcement supports Silent Monitoring (CTI OS and Unified CM-based) with this exception: For Unified Communications Manager-based Silent Monitoring, supervisors cannot hear the announcements themselves. The supervisor desktop dims the Silent Monitor button while an announcement plays.
Only one announcement can play for each call. While an announcement plays, you cannot put the call on hold, transfer, or conference; release the call; or request supervisor assistance. These features become available again after the announcement completes.
The codec settings for Whisper Announcement recording and the agent's phone must match. For example, if Whisper Announcement is recorded in G.711 ALAW, the phone must also be at G.711 ALAW. If Whisper Announcement is recorded in G.729, the phone must support or connect using G.729.
The Congestion Control feature provides protection to the Central Control Router from overload conditions, due to high call rates. The main objective of congestion control is to keep the system running close to its rated capacity, when faced with extreme
overload. The goal is to give satisfactory service to a smaller percentage of calls (your capacity) rather than a highly degraded service to all the calls, during an overloaded condition. This is achieved by restricting capacity on the system by rejection calls by the Routing Clients at the
call entry point. Throttling the capacities ensures the service of those calls routed is successful, meaning no lates or timeouts.
The measured CPS at router is the trigger for identifying congestion in the system. For a given deployment, the supported capacity is set when the deployment type is selected. The router measures the new incoming call requests from all the routing clients and computes moving weighted average
over sample duration. If the average CPS exceeds beyond the thresholds for each level, the congestion levels are changed along with the reduction percentage. The congestion control algorithm utilizes 3 congestion levels and rejects/treats the incoming calls as per the reduction percentage for
that level. The change in congestion level is notified to the routing clients. The routing clients start rejecting/treating calls based on reduction percentage.
For every instance of ICM/CCE deployment, the user needs to select the type of deployment. As part of the deployment type selection, the CPS capacity is automatically set. In a multiple instance deployments like Network Application Manager/Customer ICM (NAM/CICM) as shown in the following
diagram, the congestion control is done based on the call rate measured at each instance. The calls rejected are treated based on the congestion level in that instance. For example, if a call arrives at NAM instance through routing clients, if NAM router is congested, then the routing clients
will apply the congestion logic and reject/treat the calls. Similarly if the CICM is congested, and NAM does CICM lookup for routing any calls, such calls are subjected to congestion control at INCRP routing client at CICM instance.
After upgrading or
installing the system, configure the system to a valid deployment type. The
following table lists the supported deployment types with guidelines for
selecting a valid deployment type. You can find the requirements referred to in
the table on the
Unified CCE DocWiki
Table 1 Deployment Types
This is a
system default deployment type. User cannot select this option; is the default
setting after fresh install/upgrade.
deployment type for NAM instance in a Hosted ICM/CCEH deployment. The system
should be distributed deployment with Router and Logger installed on different
VMs, which meets the specified requirements. No agents are allowed in this
deployment type. If agents are configured and logged in, the capacity is
adjusted to maximum capacity of an Enterprise Contact Center (Unified CCE 12000
Agents Router/ Logger).
deployment type for ICM instance which is dedicated to self service call flows
using Unified CVP or third party IVR systems. The system should be
distributed deployment with Router and Logger installed on different VMs which
meets the specified requirements. No agents are allowed in this deployment
type. If agents are configured and logged in, the capacity is adjusted to
maximum capacity of an Enterprise Contact Center (Unified CCE 12000 Agents
deployment type for NAM instance in a Hosted ICM/CCEH deployment. The Router
and Logger co-located on a single VM meet the specified requirements. No agents
are allowed in this deployment type. If agents are configured and logged in,
the capacity is adjusted to maximum capacity of an Enterprise Contact Center
(Unified CCE 12000 Agents Router/ Logger).
deployment for type ICM Enterprise system where both Legacy TDM ACD PGs and CCE
PGs are deployed. The system should be distributed deployment with Router and
Logger installed on different VMs which meet the specified requirements.
8000 Agents Router/ Logger
deployment for type CCE Enterprise system where only CCE PGs are deployed. The
system should be distributed deployment with Router and Logger installed on
different VMs which meet the specified requirements for 8000 CCE agents.
12000 Agents Router/ Logger
deployment type for CCE Enterprise system where only CCE PGs are deployed. The
system should be distributed deployment with Router and Logger installed on
different VMs which meet the specified requirements for 12000 CCE agents.
deployment type when Packaged CCE: CCE-PAC-M1 is being deployed.
deployment type for ICM Enterprise system where both Legacy TDM ACD PGs and CCE
PGs are deployed. The Router and Logger are co-located on a single VM which
meets the specified requirements.
4000 Agents Rogger
deployment type for CCE Enterprise system where only CCE PGs are deployed. The
Router and Logger are co-located on a single VM which meets the specified
: CCE-PAC-M1 Lab Only
deployment type when Packaged CCE: CCE-PAC-M1 Lab is being deployed.
deployment type when HCS-CC 1000 Agents is being deployed.
this deployment type when HCS-CC 500 Agents is being deployed.
CCE 450 Agents Progger
lab deployments, select this type although the Router, Logger, and PG are not
on the same VM.
deployment type is not supported for production systems.
this deployment for Unified CCE system where only Unified CCE PGs are deployed.
This deployment is for distributed systems with the Router and Logger on other
servers that meet the requirements for 4000 Unified CCE agents.
HCS-CC 12000 Agents
Select this deployment type when HCS-CC 12000 Agents is being
It is very
important to assess the deployment type of the system and set it in the
configuration. In case of wrong deployment type selection, the system will
either be unprotected from overload or will reject/treat the calls based on
incorrect capacity settings.
Congestion Treatment Mode
There are five options available to handle the calls that are to be rejected or treated due to congestion in the system. Contact center administrators can choose any of the following options to handle the calls:
Treat Call with Dialed Number Default Label - The calls to be rejected due to congestion are treated with the default label of the dialed number on which the new call has arrived.
Treat call with Routing Client Default Label - The calls to be rejected due to congestion are treated with the default label of the routing client on which the new call has arrived.
Treat call with System Default Label - The calls to be rejected due to congestion are treated with the system default label set in Congestion Control settings.
Terminate call with a Dialog Fail or RouteEnd - Terminates the new call dialog with a dialog failure.
Treat call with a Release Message to the routing client - Terminates the new call dialog with a release message.
The treatment options are set either at routing client or at global level system congestion settings. If the treatment mode is not selected at the routing client, the system congestion settings are applied for treating the calls.
If you select the treatment option to return a label back to treat the call with an announcement, then the announcement system should be external to CCE instance. In any case the call that is treated should not be re-entered into system for further processing.
Congestion Control Levels and Thresholds
Congestion Control algorithm works in three levels and each level has onset and abatement values. Moving to a higher congestion level will happen when the average CPS exceeds the level’s onset value. For example, if the system is at level 0 and the CPS measured exceeded Level 2 onset capacity
then the congestion is directly moved to Level 2. Moving back to lower congestion level will occur when the average CPS measured falls below the level’s abatement value. Congestion levels can rise from any level to any level. However the congestion level is reduced one level at a time.
Table 2 Congestion Levels
Congestion Level Threshold (Percent of Capacity)
Level 1 Onset value: if the average CPS exceeds this value, the congestion level moves to Level 1.
Level 1 Abatement value: if the average CPS goes below this value, the congestion level moves back to Level 0 (Normal operating Level).
The percentage of incoming calls that are rejected at Level 1 congestion.
Level 2 Onset value: if the average CPS reaches higher than this value, the congestion level moves to Level 2.
Level 2 Abatement values, if the average CPS goes below this value, then the congestion level moves back to Level 1.
The percentage of incoming calls that are rejected in Level 2 congestion.
Level 3 Onset value: if the average CPS reaches higher than this value, the congestion level moves to Level 3.
Level 3 Abatement value: if the average CPS goes below this value, the congestion level moves back to Level 2.
Variable reduction from 100% to 10%
The percentage of incoming calls that are rejected in Level 3 congestion. Depending on the incoming call rate, the reduction percentage varies from 30% to 100% when the congestion level enters Level 3.
The onset, abate and reduction settings are system defined and are not configurable by the user. These values are defined as a percentage of the CPS capacity that is defined for the system.
Congestion control settings can be configured using the Congestion Settings Gadget and Routing Client Explorer tool. The system level congestion control can be set using the congestion control settings. And the routing client level treatment options can be selected using the Routing Client
Upon selecting the deployment type, the system starts computing the various metrics related to the congestion control and system capacity, and generate the real-time report. However, the system does not reject/treat the calls until you enable the Congestion Enabled option on the Settings tab of the Unified CCE Administration tool.
Congestion Level Notification
To notify the CCE administrators, the congestion level changes are logged to Windows application events. Additionally they are sent as SNMP TRAPs and are targeted to Network Management system as configured in Unified CCE SNMP Management settings.
Call Treatment for Outbound Option
Outbound Option is a special case for call treatment with Congestion Control. When Media Routing Peripheral Gateway (MRPG) is integrated for Outbound Option, the PG’s routing client should be configured to always send the dialog failure. The rejected reservation calls are retried by the dialer after a specified interval of time.
Special Operating Condition
This feature is supported by ICM/CCE 9.0(1) and later releases, and requires both Central Controller and PGs to effectively control the overload. The pre 9.0(1) PG routing clients are not capable of rejecting the calls. When a large deployment is undergoing an upgrade to 9.0(1) release, there
is a period of time when the PGs are still operated with pre 9.0 releases. In such cases, the PGs which are in 9.0(1) starts rejecting the calls but pre 9.0 PGs will not reject the call. Hence there may be a possibility where 9.0 PGs rejecting more call until all the PGs are upgraded.
The following options should be considered while upgrading the system:
Upgrade all PG before enabling the congestion control - Enable congestion to reject/treat calls only after all the PGs in the system is upgraded to 9.0. This will ensure uniform rejection of calls across all the routing clients in system.
Upgrade selected PGs: If there are options in the enterprise where few PGs can reject more calls, upgrade those PGs first and then the remaining PG.