Cisco Unified Contact Center Enterprise Design Guide, Release 10.0(1)
Features
Downloads: This chapterpdf (PDF - 1.38MB) The complete bookPDF (PDF - 12.74MB) | The complete bookePub (ePub - 6.48MB) | Feedback

Features

Features

Precision Routing

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.

Precision Routing 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.

For more information about Precision Routing, see the Cisco Unified Contact Center Features Guide.

Precision Routing Attributes

Attributes 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.

Agent Greeting

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)

Agent 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.


    Note


    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. (In most cases, phone firmware upgrades automatically when you upgrade your Unified Communications Manager installation.)

  • See the Cisco Unified Contact Center Enterprise Compatibility Matrix at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrix_​for_​Unified_​CCE for the list of supported Cisco Unified Call Center phone models.

Agent Greeting Functional Limitations

Agent Greeting is subject to these limitations.

  • 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

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.

For more information about Whisper Announcement, see Cisco Unified Contact Center Features.

Whisper Announcement Audio File

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 call-handling time.

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 send the call to the agent. You must send the transferred call to Unified CVP before you send the call to another agent. Then, Unified CVP can control the call and play the announcement, regardless of which node sends 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.

Congestion Control

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.

Figure 1. NAM/CICM deployment

Deployment Types

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 Communications in a Virtualized Environment DocWiki page.

Table 1 Deployment Types

Deployment Type Code

Deployment Name

Guidelines for Selection

0

Not Specified

This is a system default deployment type. User cannot select this option; is the default setting after fresh install/upgrade.

1

NAM

Select this 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).

2

IVR-ICM

Select this 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 Router/ Logger).

3

NAM Rogger

Select this 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).

4

ICM Router/Logger

Select this 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.

5

Unified CCE 8000 Agents Router/ Logger

Select this 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.

6

Unified CCE 12000 Agents Router/ Logger

Select this 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.

7

Packaged CCE : CCE-PAC-M1

Select this deployment type when Packaged CCE: CCE-PAC-M1 is being deployed.

8

ICM Rogger

Select this 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.

9

Unified CCE 4000 Agents Rogger

Select this 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 4000 CCE agents.

10

Packaged CCE : CCE-PAC-M1 Lab Only

Select this deployment type when Packaged CCE: CCE-PAC-M1 Lab is being deployed.

11

HCS-CC 1000 Agents

Select this deployment type when HCS-CC 1000 Agents is being deployed.

12

HCS-CC 500 Agents

Select this deployment type when HCS-CC 500 Agents is being deployed.

13

Unified CCE 450 Agents Progger

For all lab deployments, select this type although the Router, Logger, and PG are not on the same VM.

Note   

This deployment type is not supported for production systems.

14

HCS-CC 4000 Agents

Select 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.


Note


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.


Note


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 Levels

Congestion Level Threshold (Percent of Capacity)

Description

Level1Onset

110%

Level 1 Onset value: if the average CPS exceeds this value, the congestion level moves to Level 1.

Level1Abate

90%

Level 1 Abatement value: if the average CPS goes below this value, the congestion level moves back to Level 0 (Normal operating Level).

L1Reduction

10%

 The percentage of incoming calls that are rejected at Level 1 congestion.

Level2Onset

130%

Level 2 Onset value: if the average CPS reaches higher than this value, the congestion level moves to Level 2.

Level2Abate

100%

Level 2 Abatement values, if the average CPS goes below this value, then the congestion level moves back to Level 1.

Level2Redution

30%

 The percentage of incoming calls that are rejected in Level 2 congestion.

Level3Onset

150%

Level 3 Onset value: if the average CPS reaches higher than this value, the congestion level moves to Level 3.

Level3Abatement

100%

Level 3 Abatement value: if the average CPS goes below this value, the congestion level moves back to Level 2.

Level3Reduction

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.


Note


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.


Real-Time Capacity Monitoring

The "System Capacity Real-time" real-time report provides congestion level information to the user. This report is based on table System_Capacity_Real_Time in the Database Schema Guide for Cisco Unified Contact Center Enterprise. The report provides the following views:
  • Congestion Information View
  • Rejection Percentage View
  • Key Performance Indicators View
  • System Capacity View

For a detailed description of these reports refer to the Report Template Reference Guide for Cisco Unified Intelligence Center.

Congestion Control Configuration

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 Explorer tool.

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.