Reporting Guide for Cisco Unified Contact Center Enterprise

Reporting Guide for Cisco Unified Contact Center Enterprise
Reporting Guide for Cisco Unified Contact Center
Enterprise & Hosted
7.5(1)
September 2009
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0833
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE.
ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED
WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF
ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET
THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE
SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as
part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED
"AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING,
WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING
FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES,
INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE
THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco
Pulse, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for
Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks;
Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, and Flip Gift Card
are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA,
CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco
Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Fast Step, Follow Me
Browsing, FormShare, GainMaker, GigaDrive, HomeLink, iLYNX, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, Laser Link,
LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow,
PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, ScriptShare, SenderBase, SMARTnet, Spectrum
Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco
Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0908R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and
figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and
coincidental.
Copyright 2009 Cisco Systems, Inc. All rights reserved.
Table of Contents
Preface ...........................................................................................................................................................1
Purpose .....................................................................................................................................................1
Audience ....................................................................................................................................................1
Organization ..............................................................................................................................................2
Related Documentation .............................................................................................................................2
Conventions................................................................................................................................................3
Obtaining Documentation and Submitting a Service Request...................................................................4
Documentation Feedback...........................................................................................................................4
1. Planning the IPCC Enterprise System to Meet Reporting Needs...............................................................5
Reporting Concepts....................................................................................................................................6
Reporting Applications...........................................................................................................................6
About Call Types....................................................................................................................................6
About Peripherals..................................................................................................................................7
About Skill Groups.................................................................................................................................8
About Enterprise Skill Groups...............................................................................................................8
About Agent Teams................................................................................................................................9
About Media Classes and Media Routing Domains..............................................................................9
About Redirection on No Answer...........................................................................................................9
About VRU Applications.........................................................................................................................9
Planning for Naming Conventions............................................................................................................10
Planning for Reporting on Call Types.......................................................................................................11
Planning for Agent Reporting...................................................................................................................12
Planning for Skill Group Reporting...........................................................................................................14
Planning for Enterprise Skill Group Reporting..........................................................................................16
Planning for Agent Teams and Supervisors..............................................................................................16
Planning for Transfer and Conference Reporting......................................................................................16
Planning for Supervisor Assist and Emergency Assist Reporting............................................................17
Planning for Redirection on No Answer Reporting with IP-IVR................................................................17
Planning for Redirection on No Answer Reporting with Customer Voice Portal.......................................18
Planning for VRU Application Reporting...................................................................................................18
Planning for Reporting on Unexpected Scripting Conditions....................................................................20
Planning for Reporting on Short Calls......................................................................................................21
Planning the Historical Data Server for Reporting....................................................................................22
Planning which Report Templates to Use.................................................................................................23
Planning for Custom Reporting................................................................................................................24
2. Understanding Cisco IPCC Reporting Architecture..................................................................................25
System IPCC to ICM Component Mapping..............................................................................................26
Overview of IPCC Enterprise Components..............................................................................................26
IPCC Enterprise Deployments Presented In This Guide..........................................................................27
IPCC Enterprise Versus ICM Enterprise with ACD Architecture..............................................................28
ICM Enterprise with ACD Architecture.................................................................................................28
IPCC Enterprise Architecture..............................................................................................................29
IPCC Enterprise with Multichannel Applications Architecture..................................................................30
Understanding the Historical Data Server................................................................................................32
Relationship Between the Logger and Historical Data Server.............................................................32
Logger and Historical Data Server Failure and Recovery....................................................................32
Reporting Intervals ..................................................................................................................................33
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
i
Real-time Data.....................................................................................................................................33
Historical Data.....................................................................................................................................35
Data Comparisons....................................................................................................................................35
Real-time and Historical Record Comparison......................................................................................35
Call Type and Skill Group Record Comparison....................................................................................36
Half-hour Boundary Issues for Reporting Data....................................................................................37
Reporting in a Multichannel Environment.................................................................................................37
Media Routing Domains......................................................................................................................37
Media Classes.....................................................................................................................................38
Agent Availability and Route Ability.....................................................................................................38
Multichannel Reporting Data...............................................................................................................41
Reporting Tools for Multichannel Applications.....................................................................................42
Entities that Capture Reporting Data........................................................................................................42
3. Managing Agents......................................................................................................................................45
Useful Agent Statistics and Report Templates.........................................................................................45
How Do You Want to Report on Agent Performance?..........................................................................46
What Data Do You Want to See?.........................................................................................................47
Monitoring Agent States...........................................................................................................................50
Agent States........................................................................................................................................50
Agent States and Skill Groups.............................................................................................................52
Agent State Hierarchy for Multi-session Chat Media Routing Domain................................................52
Agent State and Task State Relationship.............................................................................................53
Agent Not Ready Reason Codes.........................................................................................................54
Agent Logout Reason Codes...............................................................................................................56
Configuration and Scripting Considerations for Reporting on Agent States.............................................57
Configuration and Scripting Considerations for Agent Reporting........................................................57
Configuration and Scripting Considerations for Not Ready Reason Code Reporting..........................57
Configuration and Scripting Considerations for Logout Reason Code Reporting................................58
Reporting on Agent Task Handling...........................................................................................................58
Types of Tasks.....................................................................................................................................58
Task Times...........................................................................................................................................61
Outbound Option Dialing Campaign Calls...........................................................................................62
Redirection on No Answer Calls with IP IVR.......................................................................................63
Redirection on No Answer Calls with CVP..........................................................................................64
Configuration and Scripting Considerations for Task Reporting...............................................................64
Configuration and Scripting Considerations for Transfers and Conferences........................................64
Configuration and Scripting Considerations for Redirection on No Answer with IP-IVR......................65
Configuration and Scripting Considerations for Redirection on No Answer with CVP.........................65
Reporting on Agent Call Transfers and Conferences...............................................................................66
Transfers and Conferences Using Dialed Numbers.............................................................................66
How Database Fields Are Affected by Transfers and Conferences......................................................67
How Types of Calls are Affected by Transfer and Conference.............................................................68
How Skill Groups are Affected by Transfer and Conference................................................................68
Configuration and Scripting Considerations for Transfer and Conference Reporting...............................71
Configuration and Scripting Considerations for Transfers and Conferences to Skill Groups...............71
Configuration and Scripting Considerations for Transfers and Conferences to Agents.......................71
Reporting on Supervisor Action...............................................................................................................72
Supervisor and Emergency Assist for Existing Call ............................................................................72
Supervisor and Emergency Assist for No Call.....................................................................................72
Barge-In...............................................................................................................................................73
Intercept...............................................................................................................................................73
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
ii
Configuration and Scripting Considerations for Reporting on Supervisor Action.....................................74
4. Measuring Customer Experience..............................................................................................................77
Useful Customer Experience Statistics and Report Templates................................................................77
How Do You Want to Report on Customer Experience?......................................................................78
What Data Do You Want to See?.........................................................................................................79
Call Type Reporting..................................................................................................................................80
General Call Type Report Data Balancing...........................................................................................81
How Calls that Encounter Error Conditions Affect Call Type Reporting...............................................81
How Calls that Abandon Affect Call Type Reporting............................................................................82
How Abandoned Short Calls Affect Call Type Reporting.....................................................................83
How Calls that Have a Bad Label Affect Call Type Reporting..............................................................83
How Calls that Experience Redirection on No Answer with IP IVR Affect Call Type Reporting...........83
How Calls that Experience Redirection on No Answer with CVP Affect Call Type Reporting..............84
How Calls that Terminate Label Node and Route to Non-Monitored Devices Affect Reporting...........85
Configuration and Scripting Considerations for Call Type Reporting........................................................85
Configuration and Scripting Considerations for Redirection on No Answer with IP IVR Reporting.....85
Configuration and Scripting Considerations for Redirection on No Answer with CVP Reporting........86
Configuration and Scripting Considerations for Reporting on Calls that Route to Non-Monitored
Devices................................................................................................................................................86
Configuration and Scripting Recommendations for Reporting on Abandoned Short Calls for the Call
Type.....................................................................................................................................................86
Reporting on Average Speed of Answer..................................................................................................87
ASA for the Call Type...........................................................................................................................87
ASA for the Skill Group........................................................................................................................87
ASA for the Agent................................................................................................................................88
Service Level Reporting...........................................................................................................................88
How Service Levels are Calculated.....................................................................................................88
Service Levels per Reporting Entity.....................................................................................................91
Service Level at the Call Type..............................................................................................................91
Service Level at the Skill Group...........................................................................................................92
Service Level at the Peripheral VRU Service - Not Applicable for System IPCC Deployments...........94
Using Call Type Interval Reporting to Monitor Service Level...............................................................94
Configuration and Scripting Recommendations for Service Level Reporting...........................................95
5. Monitoring Operations, Configuration, and Scripting................................................................................97
Useful Operational, Configuration, and Scripting Statistics and Report Templates..................................98
How Do You Want to Report on Operations, Configuration, and Scripting?.........................................98
What Data Do You Want to See?.........................................................................................................99
The Role of the Default Skill Group in Reporting...................................................................................105
How New Calls Increment Default Skill Group Statistics...................................................................106
How Agent to Agent Dialing Increments the Default Skill Group Statistics........................................106
How Transferred and Conferenced Calls Increment the Default Skill Group.....................................107
Configuration and Scripting Recommendations for Default Skill Group Reporting................................107
Reporting on Outbound Dialing Campaign Effectiveness......................................................................107
Configuration and Scripting Recommendations for Reporting on Outbound Dialing Campaigns..........108
Reporting on Short Calls........................................................................................................................108
Abandoned Short Calls......................................................................................................................108
Answered Short Calls - Not Applicable for System IPCC Deployments............................................109
Configuration Recommendations for Reporting on Short Calls..............................................................110
Configuring Abandoned Short Calls..................................................................................................110
Configuring Answered Short Calls - Not Applicable for System IPCC Deployments.........................110
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
iii
Determining Full-Time Equivalents and Percent Utilization....................................................................110
Understanding VRU Application Reporting............................................................................................111
Self-Service, Information Gathering, and Queuing VRU Applications...............................................112
Measuring VRU Utilization - Not Applicable for System IPCC or ARI Enterprise Deployments........114
Determining Self-Service Application and Information Gathering Application Effectiveness.................115
Monitoring Self-Service and Information Gathering Application Progress.........................................115
Capturing Script Application Data (CVP only)...................................................................................117
Configuration and Scripting Recommendations for Self-Service Applications, Information Gathering
Applications, and Queue Applications Reporting...................................................................................118
Translation Route Reporting...................................................................................................................119
6. Implications of Fail-over for Reporting.....................................................................................................121
About Peripheral Gateway/CTI Manager Service Fail-over....................................................................121
About Agent Desktop/CTI OS Server Fail-over......................................................................................122
About Cisco CallManager Fail-over........................................................................................................123
About Application Instance/MR PG Fail-over.........................................................................................123
About Application Instance/Agent PG CTI Server/ PIM Fail-over...........................................................124
7. Sample Calls and Report Data...............................................................................................................125
IPCC Enterprise Voice Call Reporting Data...........................................................................................125
Voice Call without Queuing................................................................................................................126
Voice Call with Queuing ....................................................................................................................128
Voice Call with Agent Consultative Transfer.......................................................................................132
Voice Call with Redirection on No Answer with IP-IVR......................................................................136
Voice Calls that Redirect on No Answer with CVP............................................................................141
8. Troubleshooting Report Data...................................................................................................................147
Troubleshooting Agent Reporting...........................................................................................................147
Agent data does not appear in reports..............................................................................................147
Agent Not Ready reason code text does not appear in reports.........................................................148
Agent state does not appear in Agent State Trace reports................................................................148
Agent Desktop Statistics for LoggedOnTimeSession do not appear to report accurately.................149
Agent-initiated Outbound calls appear as Inbound/Internal...............................................................149
Troubleshooting Call Type and Skill Group Reporting............................................................................150
Call Type ErrorCount incremented if Caller disconnects when call is translation routed ..................150
Call Type reports and Overflow Out Column......................................................................................150
Calls Offered for call type does not seem correct over a half-hour interval.......................................151
Total number of calls queued to each skill group is greater than the number of calls offered for the day
...........................................................................................................................................................151
Calls counted as errors in call type reports.......................................................................................152
Calls counted as incomplete in call type reports...............................................................................153
Calls offered to the call type is greater than total calls offered to skill group.....................................154
Number of calls that abandon while ringing for the skill group does not equal the number of calls that
abandon for the call type...................................................................................................................154
Abandon delay time when caller abandons in queue is different than average abandon delay time when
call abandons while ringing for the call type......................................................................................155
Troubleshooting Queue Reporting..........................................................................................................155
Queue information does not appear in reports (Not applicable to System IPCC or ARI)..................155
Missing call in queue information in the WebView Service real-time and historical templates (Not
applicable to System IPCC or ARI)....................................................................................................156
Troubleshooting VRU Application and Trunk Group Reporting (Not applicable to System IPCC or ARI).156
VRU Application information does not appear in Call Type or Service reports..................................156
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
iv
Information for Trunk Groups associated with VRU ports does not appear in trunk group reports (Not
applicable to System IPCC or ARI)....................................................................................................157
Troubleshooting Historical Data Server Data..........................................................................................157
Historical Data Server is losing the oldest data.................................................................................157
Historical report is missing data for a recent interval.........................................................................158
Data is missing from the Historical Data Server after it has recovered from a failure........................158
Troubleshooting Application Gateway Reporting....................................................................................159
The number of Application Gateway requests in reports is larger than the number of Router Call Detail
records...............................................................................................................................................159
Index ...........................................................................................................................................................161
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
v
List of Figures
Figure 1: ICM Enterprise with ACD architecture............................................................................................................28
Figure 2: IPCC Enterprise Architecture...........................................................................................................................29
Figure 3: IPCC Enterprise with Multichannel Options...................................................................................................31
Figure 4: Real-time Data Moved to Local Database.......................................................................................................34
Figure 5: Agent State Hierarchy in Skill Group and MRD.............................................................................................53
Figure 6: Agent State and Task State Relationship..........................................................................................................54
Figure 7: Sample Routing Script for Information Gathering and Queuing...................................................................113
Figure 8: Call Type Data for Calls that Abandon after Call Type is Changed...............................................................113
Figure 9: Call Type Data for Calls that Abandon before Call Type is Changed............................................................114
Figure 10: Routing Script for Voice Call without Queuing...........................................................................................126
Figure 11: Routing Script for Voice Call with Queuing................................................................................................129
Figure 12: Routing Script for Voice Call without Queuing...........................................................................................132
Figure 13: Routing Script for Redirection on No Answer with IP-IVR........................................................................136
Figure 14: Routing Script for Redirection on No Answer with IP-IVR........................................................................137
Figure 15: Routing Script for Redirection on No Answer with ISN.............................................................................142
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
vi
Preface
Purpose
Welcome to the Reporting Guide for Cisco IPCC Enterprise & Hosted. This guide provides
information to help you understand how reporting data is generated and how to interpret reporting
data in a Cisco IPCC Enterprise environment. This guide also helps you understand the
implications of configuration and scripting on reporting data.
Audience
This guide is written for anyone who uses WebView or Cisco Unified Intelligence Suite (Unified
IS) to generate reports in an IPCC environment to monitor contact center agent performance,
operational effectiveness, and customer experience. Contact center supervisors and managers
and individuals responsible for configuring and scripting will find this guide useful.
This guide also applies to reporting in an Unified ICM Enterprise environment with an Agent
Routing Interface (ARI) deployment. In an ARI deployment, an ARS PG interfaces with an
ACD/PBX.
To generate reports for the ARS PG and for the agents, skill groups, and other entities associated
with it, select the IPCC report templates in WebView.
This guide does not include reporting in an IPCC Gateway environment, in which an IPCC
Enterprise system is connected as a child IP ACD to a parent ICM Enterprise. To understand
reporting implications for this type of deployment, refer to the Cisco IPCC Gateway Deployment
Guide.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
1
Preface
Organization
Organization
This document contains the following sections:
• Planning the IPCC Enterprise System to Meet Reporting Needs (page 5)
This section provides a high-level overview of the configuration and scripting necessary for
producing reporting data that you require from your deployment.
• Understanding IPCC Enterprise Reporting Architecture (page 25)
This section explains how the architecture and components of the system generate and affect
reporting data.
• Managing Agents (page 45)
This section provides statistics for measuring agent performance and identifying training
needs and explains how data for the agent is generated.
• Measuring Customer Experience (page 77)
This section provides statistics for measuring customer experience and explains how data
for customer experience is generated.
• Monitoring Operations, Configuration, and Scripting (page 97)
This section provides statistics for monitoring operational, configuration, and scripting
accuracy and efficiency and explains how operational data is generated.
• Implications of fail-over for Reporting (page 121)
This section explains what happens to reporting data when components in the IPCC Enterprise
system Fail-over.
• Sample Calls and Report Data (page 125)
This section describes sample calls in the system and the report data generated for agent,
skill group, and call type reports.
• Troubleshooting Reporting Data (page 147)
This section describes how to correct common reporting data issues.
Related Documentation
Refer to the following documentation for additional information:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
2
Preface
Conventions
• IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
• Cisco IPCC Gateway Deployment Guide
• ARI Deployment Guide for Cisco Unified Intelligent Contact Manager Enterprise
• Reporting Guide for Cisco Unified ICM Enterprise & Hosted
• IPCC Administration Guide for Cisco IPCC Enterprise Edition
• ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
• Cisco Unified Intelligence Suite Intelligence Center User's Guide, Release 7.5(1)
Refer to the following documentation for WebView information:
• WebView Installation and Administration Guide for Cisco ICM/IPCC Enterprise & Hosted
Editions
• WebView Reporting Online Help
• WebView Template Reference Guide for Cisco IPCC Enterprise & Hosted
• Template Design Guide Using InfoMaker for Cisco ICM/IPCC Enterprise & Hosted Editions
Conventions
This manual uses the following conventions:
Convention
Description
boldface font
Boldface font is used to indicate commands, such as user entries,
keys, buttons, and folder and submenu names. For example:
• Choose Edit > Find.
• Click Finish.
italic font
Italic font is used to indicate the following:
• To introduce a new term. Example: A skill group is a
collection of agents who share similar skills.
• For emphasis. Example: Do not use the numerical naming
convention.
• A syntax value that the user must replace. Example: IF
(condition, true-value, false-value)
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
3
Preface
Obtaining Documentation and Submitting a Service Request
Convention
Description
• A book title. Example: See the Cisco CRS Installation Guide.
window font
Window font, such as Courier, is used for the following:
• Text as it appears in code or that the window displays.
Example: <html><title>Cisco Systems,Inc. </
title></html>
< >
Angle brackets are used to indicate the following:
• For arguments where the context does not allow italic, such
as ASCII output.
• A character string that the user enters but that does not appear
on the window such as a password.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering
additional information, see the monthly What's New in Cisco Product Documentation, which
also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication
(RSS) feed and set content to be delivered directly to your desktop using a reader application.
The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
Documentation Feedback
You can provide comments about this document by sending email to the following address:
mailto:[email protected]
We appreciate your comments.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
4
Chapter 1
Planning the IPCC Enterprise System to Meet
Reporting Needs
The manner in which you configure and script the Cisco IPCC Enterprise system greatly affects
the accuracy and usefulness of the reporting metrics. This section discusses guidelines for
configuring and scripting features and components to ensure that the reports display correct and
relevant metrics for the contact center implementation.
Consider the guidelines in this section while planning the configuration and scripts for your
system. If your system is already installed, review the guidelines to correct any configuration
and scripting problems that might affect the reporting data.
If you are using a Cisco IPCC Enterprise deployment other than System IPCC Enterprise, refer
to the IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition for
instructions on configuring the system to meet these guidelines. If you are using a System IPCC
Enterprise deployment, refer to Cisco IPCC Enterprise Edition System IPCC Installation and
Configuration Guide.
For instructions on creating scripts to meet these guidelines, refer to the ICM Scripting and
Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions .
This chapter contains the following topics:
•
•
•
•
•
•
•
•
•
•
•
Reporting Concepts, page 6
Planning for Naming Conventions, page 10
Planning for Reporting on Call Types, page 11
Planning for Agent Reporting, page 12
Planning for Skill Group Reporting, page 14
Planning for Enterprise Skill Group Reporting, page 16
Planning for Agent Teams and Supervisors, page 16
Planning for Transfer and Conference Reporting, page 16
Planning for Supervisor Assist and Emergency Assist Reporting, page 17
Planning for Redirection on No Answer Reporting with IP-IVR, page 17
Planning for Redirection on No Answer Reporting with Customer Voice Portal, page 18
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
5
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Reporting Concepts
•
•
•
•
•
•
Planning for VRU Application Reporting, page 18
Planning for Reporting on Unexpected Scripting Conditions, page 20
Planning for Reporting on Short Calls, page 21
Planning the Historical Data Server for Reporting, page 22
Planning which Report Templates to Use, page 23
Planning for Custom Reporting, page 24
Reporting Concepts
As you plan your deployment, it is necessary to understand several important concepts for Cisco
IPCC Enterprise reporting, including the role of call types, peripherals, skill groups, agent teams,
media routing domains and media classes, and the different purposes that VRUs can serve.
Reporting Applications
This guide uses many references to WebView, Cisco System's legacy reporting application.
The Unified Intelligence Center, introduced in Release 7.5(1), is Cisco's new reporting engine.
Unified IC is one of two components of the Cisco Unified Intelligence Suite.
Like WebView, it is a browser-based application and pulls reporting data from the AW and
HDS databases on the Unified ICM Admin Workstation.
Unlike WebView, it is installed with fewer than two dozen stock templates. These templates
are based on the WebView All Fields templates. Unified IC offers extensive flexibilty in that
it allows you clone these templates and, in your cloned versions, to hide or show fields, rename
fields, move fields, and change grouping and sorting.
This guide contains reporting concepts and guidance for configuring Unified ICM for reporting
that are applicable to both WebView and Unified IC.
About Call Types
Call types are the highest level reporting entity in the Cisco IPCC Enterprise system. Call types
are used to group calls for the purpose of call treatment and reporting. Call types determine the
manner in which a call is treated when it enters the system by selecting the routing script to run
for a call.
The call type can be changed throughout the life of a call to direct the call to a new routing
script and to gather report metrics for different legs or transactions. Reporting on call type
activity provides insight into end-to-end customer interactions with the system and with agents
by providing data such as Service Level adherence, transfers, average speed of answer, calls
handled, and calls abandoned.
A call type is defined as a category of incoming call or non-voice task that can be routed to an
agent by the Central Controller. Each call type has a schedule that determines which routing
script or scripts are active for that call type at any time.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
6
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Reporting Concepts
There are two classes of call types:
• Voice (phone calls): Voice call types are categorized initially by the dialed number (DN)
and, optionally, by the caller-entered digits (CED) and the calling line ID (CLID).
• Non-voice (e-mail and text chat): Non-voice call types are categorized initially by the Script
Type Selector and, optionally, Application String 1 and Application String 2.
You might change the call type within a routing script for several reasons. Consider these
examples:
• In a Self-Service VRU (page 9) application script, you might change the call type at specific
points in the script to indicate that a transaction has been completed. For example, if the
customer is calling a bank and successfully checks his or her account balance using a
Self-Service script, you might want to change the call type to indicate that the account balance
transaction has completed and a new transaction has begun. In this case, you would create a
call type for each transaction on which you want to report.
• You might change the call type when a call enters a queue at the end of an Information
Gathering VRU application in order to separate Information Gathering and queuing metrics.
In this case, you would create call types associated with the Information Gathering applications
and call types associated with queuing.
• You might change the call type in a script to direct the call to a new routing script associated
with that call type.
You can also use call types to report on certain activities that occur within the contact center.
For example, you might create separate call types for these situations:
• Calls that redirect on no answer (RONA (page 9)).
• Calls that are transferred to other agents.
• Requests for supervisor assistance.
About Peripherals
A peripheral is a device, such as the Cisco CallManager, IP IVR, Cisco Customer Voice Portal
(CVP), and multi-channel options, that receives tasks that have been routed by the Cisco software.
The Peripheral Gateway (PG) is the component that talks to the telephony devices (peripherals)
through their own proprietary CTI interface and keeps track of the agent states and calls that
are on the telephony devices.
In Cisco IPCC systems, reporting data is gathered for each peripheral. In order to understand
how reporting data is gathered in your environment, it is important to understand the deployment
used to meet the contact center's needs.
In Cisco IPCC Enterprise deployments that use the Generic PG (that allows multiple peripherals
of different types to reside inside of the same PG), or separate PGs for Cisco CallManager and
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
7
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Reporting Concepts
the VRU, the Cisco CallManager and VRU appear as separate peripherals to the software. In
this case, each time a task switches between the Cisco CallManager and the VRU peripherals,
the task appears as a new task to the system. From a reporting perspective, this has an impact
on how and when data is collected.
In this deployment, for example:
• A task (call) that comes into the Cisco CallManager then gets transferred to the VRU and
then back to an agent looks like three separate tasks (calls). A Termination_Call_Detail is
written for each task (call).
• A task (call) that is queued to a skill group and later answered by an agent is not considered
as offered to a skill group until the task (call) is answered.
In an Cisco IPCC Enterprise deployment with IPCC System PG (including the System IPCC
Enterprise deployment), the IPCC System PG consolidates the Call Manager and VRU peripherals
into a single peripheral. In this case, each time a task switches between the Cisco CallManager
and the VRU peripheral, the task appears as a single task to the IPCC Enterprise system.
Hence in this deployment data is collected differently; for example:
• A task (call) that comes into the Call Manager then gets transferred to the VRU and then
back to an agent looks like a single task (call) to the ICM/IPCC software and a single
Termination_Call_Detail is written.
• A task (call) is considered as offered to a skill group when the task (call) is queued to a skill
group.
About Skill Groups
A skill group is a collection of agents at a single contact center who share a common set of
competencies and can handle the same types of requests. Each skill group belongs to a Media
Routing Domain (page 9). You can report on agents individually or report on all of the agents
in one or more skill groups to monitor agent performance. You can also report on skill groups
as a whole to see how the skill group is performing compared to other skill groups. You might
use this level of reporting, for example, to see if calls are being distributed evenly by your
routing scripts and configuration.
About Enterprise Skill Groups
An enterprise skill group is a collection of skill groups. While each individual skill group is tied
to a specific peripheral, an enterprise skill group can span peripherals. For example, you may
have a skill group called Boston_Sales on one peripheral and a skill group called NewYork_Sales
on another peripheral. You could create a Sales enterprise skill group to organize these two skill
groups for reporting purposes. The software can simply total some statistics to obtain
enterprise-wide values. For example, to obtain the number of agents available in an enterprise
skill group, the software adds the number of agents available in each member peripheral skill
group.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
8
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Reporting Concepts
If you consolidate skill groups from the same peripheral into an enterprise skill group, you will
see double-counting of some metrics in your reports.
About Agent Teams
An agent team is a group of related agents associated with a single peripheral. Agent teams are
associated with a primary supervisor and can be associated with one or more secondary
supervisors. You can report on agent teams to monitor the performance of a particular team.
Supervisors might find these reports useful to monitor the agents that they supervise.
About Media Classes and Media Routing Domains
If you have deployed Cisco Collaboration Server or Cisco E-Mail Manager in your Cisco IPCC
system, agents can be configured to receive requests from multiple media channels, including
voice, Web, and e-mail. A Media Class represents a combination, or a single instance, of media
that are to be treated as a single concept. In Cisco IPCC Enterprise systems, Media Classes
include voice, multi-session chat, single-session chat, blended collaboration, and e-mail.
A Media Routing Domain (MRD) is collection of skill groups and services that are associated
with a common media class. Each skill group is assigned to a Media Routing Domain. The
software uses MRDs to route a task to an agent who is associated with a skill group and a
particular medium.
You can report on activity for all of the MRDs that you have configured in your system.
About Redirection on No Answer
The Redirection on No Answer (RONA) feature ensures that if an agent does not answer a call
within a specified amount of time, the call is assigned to a different skill group or agent and the
original agent is made Not Ready so that he or she is not routed additional calls. This feature is
implemented differently depending on whether you are installing IP-IVR or CVP as the VRU
for your system.
Redirection on No Answer is not supported for the AGS PG.
About VRU Applications
Your enterprise might implement one or more types of VRU applications. VRU applications
include Self-Service and Information Gathering. 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 his or her 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 he
or she wants to reach, and then uses the information in the routing decision and passes the
information to the agent desktop.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
9
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Naming Conventions
The VRU is also used to 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.
The types of VRU applications that you use determine what report data to monitor.
For example:
• If your VRU only performs queuing, you might want to see how long callers waited in queue
and 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.
Planning for Naming Conventions
Before configuring the system, decide on the naming conventions to be used throughout the
contact center enterprise.
When planning your installation, consider how you want to name the components and entities
that you will be configuring. For example, what kind of names do you want to use for call types
and skill groups? The names for agents, skill groups, agent teams, peripherals (such as VRU
peripherals and CallManager peripherals), call types, VRU services, trunk groups, and application
gateways appear in WebView as selection criteria for reports.
Depending on your contact center, a wide range of individuals might be running reports and
using the selection criteria. Using intuitive names for components and entities will help these
users interpret the report selection criteria correctly. For example, instead of using numbers for
call type names, use descriptive text such as "RedirectOnNoAnswer" or "SupervisorAssist".
When you generate a WebView report, you can select up to 1000 items from the list. If you are
running an agent report, you can select from a list of agents; if you are running a skill group
report, you select from a list of skill groups, and so forth.
Also the selections and reports are sorted by names. Using meaningful naming conventions (for
example, prefixing the name of items associated with a particular workgroup with the same
prefix) helps contact center personnel find a particular report more easily.
If you are deploying an IPCC Gateway system, in which Cisco IPCC Enterprise appears as an
IP ACD to a parent ICM Enterprise system, limit the number of characters in the names of
agents, skill groups and call types on the child IPCC Enterprise system. When these names are
passed to the parent ICM during auto-configuration, the software configures the name such as
(Parent)Peripheral.EnterpriseName +"."+ (Child)Skill_Group.PeripheralName. configured
name exceeding 32 characters are automatically truncated and replaced with a number. This
means you will not be able to find the name in reports run on the ICM Enterprise system. Refer
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
10
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Reporting on Call Types
to the Cisco IPCC Gateway Deployment Guide for more information about IPCC Gateway
deployment and considerations.
Planning for Reporting on Call Types
Follow these guidelines to obtain accurate and useful reporting data:
• Determine how many call types you need to configure to meet your reporting needs.
Consider the following when determining the number of call types required:
– Configure a separate call type for each type of call treatment that you want to offer.
– Configure a separate call type associated with Redirection on No Answer (RONA)
situations. This enables you to direct calls that Ring No Answer to a routing script designed
for this situation and to report on this Redirection on No Answer call type to see how calls
that redirect on no answer are eventually handled.
– Configure a separate call type associated with the Supervisor and Emergency assist script
for each agent team. This enables you to direct the assistance request to the Supervisor
and Emergency Assist routing script which can assign the request to the primary or
secondary supervisor for that agent's team. You can use call type reports to view data for
supervisor assistance calls.
– Configure a separate call type associated with call transfers and conferences. This enables
you to direct the transfer to a different routing script.
– If you are planning to report on individual transactions within VRU Self-Service or
Information Gathering applications, configure a separate call type for each transaction.
– If you want to separate Information Gathering VRU metrics from queue metrics, configure
a separate call type for queuing.
• Determine the Service Level for call types.
Service Level indicates how well you are meeting your goal for answering calls. For example,
your goal might be to answer 80% of calls within two minutes. In this case, you would set
the Service Level Threshold to 120 seconds. Reports show you the percentage of calls that
are answered within that time threshold, enabling you to see whether you are meeting your
goal.
Also, determine how the abandoned calls will impact the Service Level. Decide whether the
abandoned calls are ignored in the Service Level calculation, negatively affect Service Level,
or positively affect Service Level. For example, for VRU Self-Service applications all calls
that terminate are considered abandoned, even if the caller received the information he or
she required. You might want to ignore these calls or have them affect Service Level positively.
You might want calls that abandon while queuing or while ringing to impact Service Level
negatively.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
11
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Agent Reporting
You can configure the Service Level setting individually for each call type, or set a global
Service Level for all call types.
• Decide whether you want to configure abandoned short calls to filter out calls that abandon
very quickly.
If you want to use abandoned short calls, you configure the call type Abandon Wait Time in
the configuration tool. Calls that abandon within the Abandon Wait Time are reported as
short calls.
If you do not want to use abandoned short calls, leave the Abandon Wait Time field blank.
• Decide whether you want to define time intervals for reporting on answered and abandoned
calls for the call type.
These intervals appear in call type reports which display the number of calls answered and
abandoned for each interval. These reports are useful for monitoring when calls are abandoning
or being answered. You might want to configure the intervals in relation to the Service Level
for the call type to see how close to the Service Level calls are being answered and abandoned.
Service Level tells you what percentage of calls are being answered within a certain time,
but does not tell you how closely to the Service Level calls are being answered or abandoned.
Call type intervals provide additional insight into how long callers are waiting before their
calls are answered or before they abandon.
For example, if your Service Level is two minutes, you might want to set up intervals for 30
seconds, one minute, 80 seconds, 120 seconds, 180 seconds, 210 seconds, and 240 seconds.
Using these intervals, you can see whether calls are being answered in the thirty seconds
after the Service Level Threshold of 180 seconds or if most are waiting a full minute longer
to be answered.
The intervals also give you insight into how long callers are willing to wait before abandoning.
Perhaps many callers do not abandon until two minutes past the Service Level. This might
indicate that your Service Level goal can be modified.
You can configure the intervals individually for each call types, or set a global interval for
all call types.
• Call Types cannot span ACDs and Cisco Unified Contact Center Enterprise PGs. This means
that if your system uses both Cisco Unified Contact Center Enterprise components and legacy
ACDs, you must create separate call types for the ACDs and the Cisco Unified Contact Center
Enterprise components.
Planning for Agent Reporting
Follow these guidelines to ensure that you are able to obtain accurate and useful data for agents:
• Decide whether you want to view agent data in reports.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
12
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Agent Reporting
If you do want to view agent data, you must ensure that the agent reporting option is enabled
for the Cisco CallManager peripheral.
Note: The agent reporting option can be enabled in Configuration Manager -> Peripheral ->
PG Explorer in ICM AW. This option is enabled by default and for System IPCC deployments,
this option cannot be disabled.
If you are using any deployment other than System IPCC, you also must identify the Admin
Workstation distributor in the Agent Distribution list for the CallManager peripheral so that
agent data is sent to the correct Admin Workstation.
• Decide whether you want to report on agent state in the agent state trace report. If you do
want to see this information, enable the agent state trace option in the configuration tool for
each agent whose state information you want to view.
Enabling agent state trace for many agents might impact system performance as the option
causes more records to be written to the database. If you notice a performance problem, you
might want to disable agent state trace, or only enable agent state trace for those agents on
whom you are reporting. Also consider this when sizing the databases.
• If you want to report on agent Not Ready reason codes, determine what reason codes you
want to use.
You configure the Not Ready Reason codes both in the ICM/IPCC configuration tool and
on the agent desktop software (CTI OS or Cisco Agent Desktop). The codes configured on
the configuration tool are the enterprise-level codes that appear in WebView reports while
the codes configured on the desktop software are the codes that the agent selects when entering
Not Ready state. Ensure that the codes that display in WebView match the desktop codes to
avoid confusion.
Also, ensure that the agent event detail option is enabled on the CallManager peripheral. (It
is enabled by default for the CallManager peripheral.) In System IPCC Enterprise deployments,
this is enabled by default and cannot be disabled.
• If you want to report on agent Logout reason codes, determine what reason codes you want
to use.
Also, configure the Logout reason codes in the agent desktop software (CTI OS or Cisco
Agent Desktop). Some codes are generated automatically by the system. In reports, you will
see the numeric equivalent of each reason code, not the textual code. For example, if Logout
reason code 1 is "End of Shift", you will see "1" in the report.
Planning for agent reporting also involves planning how you want to group agents into teams
and skill groups.
See Also
Planning for Skill Group Reporting on page 14
Planning for Agent Teams and Supervisors on page 16
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
13
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Skill Group Reporting
Planning for Skill Group Reporting
Follow these guidelines to obtain accurate and useful reporting data:
• Decide whether to implement base skill groups or sub-skill groups. For Cisco IPCC Enterprise
systems, we generally recommend that you configure base skill groups only and not configure
sub-skill groups, to avoid confusion in reporting and scripting.
For System IPCC and ARI deployments, sub-skill groups are not supported. If you have
deployed System IPCC or ARI, you can configure only base skill groups.
There may be limited instances where configuring sub-skill groups may be useful, such as
using sub-skill groups as overflow groups in scripts. For example, the script might first
attempt to select an agent in the primary sub-skill group and then, if no agents are available,
attempt to select an agent in the secondary skill group. In this way, you see how many calls
are overflowing out of the primary skill group. However, while there are benefits to using
sub-skill groups, there are also many issues that you might experience if you configure
sub-skill groups.
If you do configure sub-skill groups, understand the following issues that occur when using
sub-skill groups:
– Sub-skill groups represent primary, secondary, etc., levels of a base skill group. Agents
that are most competent in a skill group would be grouped into the primary sub-skill group.
The name of a sub-skill group is the name of its base skill group with .pri, .sec., etc.
appended to the end of the name.
– WebView reports are designed for base skill groups.
However, when you run skill group reports in WebView and have configured sub-skill
groups, do not select the base skill group for the report. Agents are not assigned to the
base skill group; they are assigned to the sub-skill group. Because the reports are designed
to gather data from base skill group metrics only, they might not be appropriate for reporting
on sub-skill groups.
– Sub-skill groups do not imply priority in scripting. You must indicate the priority of each
sub-skill group in the script.
– If you have configured sub-skill groups, queue calls only to those sub-skill groups, not to
base skill groups. If you queue to the base skill-group when sub-skill groups are configured,
queue statistics are not counted against the sub-skill groups. You must queue to the sub-skill
groups to see correct queue reporting data on the agent desktop reporting applications and
WebView.
– If you queue to multiple sub-skill groups created for the same base skill group, the number
of calls queued roll up into the base skill group data. For example, if you queue one call
to two sub-skill groups, two calls are reported as queuing to the base skill group.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
14
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Skill Group Reporting
– Each sub-skill group is treated as a separate skill group by the ICM/IPCC Central Controller,
however the data from sub-skill groups automatically rolls up into base skill groups.
– By design, all Outbound Option calls are attributed to the base skill group since that is
what is provided in the Set Device Attribute message from the Dialer. This is appropriate
when the agent is logged into the base skill group. However, if sub-skill groups are
configured under IPCC, the default behavior is to not report on the base skill group for
Agent Skill Group reports, meaning that no Outbound Option calls are reported on in this
configuration.
ICM/IPCC needs to check if the agent belongs to the base skill group for Outbound Option
calls and, if not, examine whether they belong to a sub-skill group. Reporting can then be
moved to the sub-skill group.
• Determine the Service Level (SL) for skill groups.
As pointed out earlier, call type Service Levels are used to measure customer experience
relative to configured Service Levels for call types (i.e. Service Level by Sales, or Customer
Support) independent of which skill groups answered the call. In Cisco IPCC Enterprise, you
also have the ability to configure service levels for skill groups, enabling you to measure
relative performance of skill groups for a particular call type. For example, if you have a
Service Level threshold of 120 seconds for a particular call type with abandoned calls having
negative impact on Service Level and followed the guideline pointed out earlier of configuring
a separate call type for queuing, then you can configure skill group Service Level threshold
of 120 seconds with abandoned calls having negative impact on Service Level for each of
the skill groups associated with that call type in order to get additional visibility into which
skill groups on average are positively or negatively contributing to the overall call type
Service Level.
If you are planning to use Skill Group Service Levels, it is important to understand the benefits
and limitations of skill group SLs in Cisco IPCC Enterprise deployment model.
– First, it is important to understand the relationship between call types and skill groups that
are defined through your scripts. In Cisco IPCC Enterprise, you have the flexibility to
define many to many relationships between call types and skill groups. If this is the case,
the skill group Service Level statistics will reflect call counts from all the call types.
– Second, call type Service Level and associated skill group Service Level statistics are not
expected to balance. As described earlier, a skill group can receive calls from different
call types, hence the skill group Service Level statistics reflect call counts from different
call types. Call type metrics are incremented differently depending on your scripting. For
example, if a call disconnects for any reason before it reaches the Queue to Skill Group
node, the call is included in the calculation of Service Level for the call type but not the
skill group.
– Third, determine how abandoned calls are to impact the Service Level. You decide whether
abandoned calls are ignored in the Service Level calculation, negatively affect Service
Level, or positively affect Service Level.
– Fourth, in Cisco IPCC Enterprise calls can queue to more than one skill group, and therefore
Service Level metrics are updated for each skill group to which a single call queues.
Abandon calls in this scenario could have a negative impact on the skill group service
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
15
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Enterprise Skill Group Reporting
levels. For example, if a single call is queued to multiple skill groups and the call abandons,
this impacts Service Level metrics for Offered and abandon for all those skill groups.
You can configure the Service Level setting individually for each skill group, or globally for
skill groups grouped by MRD or peripheral. For System IPCC deployments, you set the
global Service Level grouped by MRD only.
Planning for Enterprise Skill Group Reporting
Determine which skill groups you want to group into an enterprise skill group. These skill groups
might be from several peripherals and/or from different media. For example, you may have a
skill group called Boston_Sales on one peripheral and a skill group called NewYork_Sales on
another peripheral. You could create an Enterprise skill group called Enterprise_Sales.
If you group skill groups from the same peripheral into an Enterprise skill group, you will see
double-counting of some metrics in your reports.
If you are using an IPCC Gateway deployment, in which Cisco IPCC Enterprise acts as an IP
ACD to a parent ICM Enterprise system, decide which skill groups on the Cisco IPCC Enterprise
system are to be grouped into enterprise skill groups as the parent level. Refer to the Cisco IPCC
Gateway Deployment Guide for more information about IPCC Gateway deployment and
considerations.
Planning for Agent Teams and Supervisors
Follow these guidelines if you want to report on agents grouped into teams:
• Organize your agents into teams. An individual agent can be assigned to one team only. You
create agent teams and assign agents to the teams using the configuration tool. Teams are
peripheral-specific.
• Optionally, select one primary supervisor for each team. You can select multiple secondary
supervisors for each team. Each supervisor can be a supervisor for multiple teams.
Note: All agents on a team and the supervisor(s) for the team must reside on the same
peripheral.
Supervisors can only view data for their own team(s) in agent reports.
Planning for Transfer and Conference Reporting
If you are planning to allow agents to transfer and conference calls, follow these guidelines to
obtain accurate and useful data from transfers and conferences:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
16
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Supervisor Assist and Emergency Assist Reporting
• Configure the dialed numbers with associated route points for transfer and conference to
agents and skill groups.
• Plan to create a separate script for transfers that use the dialed numbers you configured. In
the initial script, change the call type when the call is transferred to direct the call to the
transfer script. Having a separate script allows you to track data across call types and skill
groups, instead of the agent's default skill group.
Planning for Supervisor Assist and Emergency Assist Reporting
If you are planning to allow Supervisor Assist and Emergency Assist, follow these guidelines
to ensure that you are able to obtain accurate and useful data from these features:
• Plan to configure skill groups for supervisors handling Supervisor Assist and Emergency
Assist requests. For example, you might configure one skill group for the primary and
secondary supervisors of each agent team. This way, you can direct requests to these skill
groups and report on Supervisor and Emergency Assist call activity for these skill groups.
• Plan to create call types, and configure dialed numbers that map to the created call type, to
run scripts that direct the requests to the appropriate supervisor skill group. In the script, first
target the primary supervisor and then, if you have configured secondary supervisors, queue
to secondary supervisors.
Planning for Redirection on No Answer Reporting with IP-IVR
If you are implementing Redirection on No Answer and have deployed IP-IVR as the VRU,
follow these guidelines to obtain accurate and useful data from Redirection on No Answer
situations:
• Decide how long a call is to ring before being redirected to a new agent or skill group. When
deciding this, consider how Redirection on No Answer calls are to affect the Service Level.
If you want want Redirection on No Answer calls to adversely affect the Service Level, the
amount of time the call is allowed to ring before being redirected must be above the Service
Level threshold time. You configure the ring no answer time in the configuration tool.
• Decide what number be dialed in order to redirect calls that are not answered by agents within
the ring no answer time. You configure the ring no answer dialed number in the Agent Desk
Settings tool in the configuration tool.
• Plan to create a separate call type for Redirection on No Answer situations and to associate
this call type with the ring no answer dialed number.
You create a separate script for Redirection on No Answer that is associated with the
Redirection on No Answer call type. In the Redirection on No Answer Script, queue the calls
at a higher priority. The call variables set in the first script are carried over into the second
script and you can use these variables if you choose.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
17
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Redirection on No Answer Reporting with Customer Voice Portal
Using a separate call type not only enables you to redirect calls that are not answered to a
script that queues the calls at a higher priority, but also enables you to report on activity for
the Redirection on No Answer call type. Viewing data for this call type helps you gain insight
into the number of calls that redirect on no answer and to see how the calls are finally handled.
Planning for Redirection on No Answer Reporting with Customer Voice Portal
Note: In Releases prior to Release 3.0, the Customer Voice Portal (CVP) product was named
Internet Service Node (ISN)
If you are implementing Redirection on No Answer and have deployed CVP as the VRU, follow
these guidelines to obtain accurate and useful data from Redirection on No Answer situations.
• Decide how long a call ring before being redirected to a new agent or skill group.
You configure the ring no answer time in two places: CVP software and ICM/IPCC software.
Configure the CVP Ring No Answer timeout in the CVP Voice Browser Administration
application. This timer will be used to requery the call if the call is not answered. Configure
the ICM/IPCC Agent Desk Settings Ring no answer time. This time determines when the
agent is made Not Ready so that additional calls are not assigned to the agent. CVP Ring No
Answer timeout be approximately 2 seconds higher than the Ring no answer time configured
in Agent Desk Settings. The CVP Ring No Answer timeout also be less than 30 seconds
because the ICM/IPCC Central Controller waits up to 30 seconds for a response to arrive
from the CVP. If the response is not received within 30 seconds, the call fails.
• Within the routing script, plan to enable the Target Requery option in the routing script.
Target Requery is available from the Queue, Queue to Agent, Label, Select, and RouteSelect
nodes. Change the call type in the script after the requery and create a path for calls that are
requeried within the script. Queue calls that are requeried at a higher priority.
Using a separate call type enables you to report on activity for that call type. Viewing data
for this call types helps you gain insight into the number of calls that are requeried and to
see how the calls are finally handled.
Planning for VRU Application Reporting
For all deployments, follow these guidelines to obtain accurate and useful data for VRU
applications:
• If you have Self-Service or Information Gathering IVR applications and want to separate
self-service/digit collection metrics from queuing metrics, plan to change the call type in the
routing script before the call is queued. This 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.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
18
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for VRU Application Reporting
• If you want to track how callers have progressed through a Self-Service or Information
Gathering IVR application, plan to 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. Use the
VRU Activity reports to view how callers have progressed through the VRU script. You can
use this variable to determine how many calls the application did not handle, how many were
handled, how many were transferred to an agent at the caller's request, how many calls were
not able to navigate and were redirected to an agent, and how many encountered error
conditions and were redirected to an agent.
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 VRUProgress variable when the call reaches the end of a transaction and then change the
call type. This enables you to report on each transaction separately using the call type VRU
Activity reports.
For all deployments other than System IPCC and ARI deployments, follow these additional
guidelines to obtain accurate and useful data for VRU applications:
• 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. This is applicable if you
are using the IPCC System PG with CVP in your deployment and not applicable if you are
using only the IPCC System PG in your deployment.
• Determine the Service Level for VRU services. This is not available in System IPCC or ARI
deployments.
Service Level indicates how well you are meeting your goal for answering calls. For example,
your goal might be to answer 80% calls within two minutes. In this case, you would set the
Service Level Threshold to 120 seconds. Reports show you the percentage of calls that are
answered within that time threshold, enabling you to see whether you are meeting your goal.
Also, determine how abandoned calls impact the Service Level. You decide whether
abandoned calls be ignored in the Service Level calculation, negatively affect Service Level,
or positively affect Service Level. For example, for VRU Self-Service applications, all calls
that terminate are considered abandoned, even if the caller received the information he or
she required. You might want to ignore these calls or have them positively affect Service
Level. You might want calls that abandon while queuing or while ringing to negatively impact
Service Level.
You can configure global Service Level for all VRU services or configure Service Level for
individual services.
• You will need to configure services on ICM/IPCC software 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 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 CRS Application Administration as the ICM/IPCC post routing ID.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
19
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Reporting on Unexpected Scripting Conditions
Remember the ICM/IPCC post routing ID that you configure for use when creating services
on ICM/IPCC software.
– If you are using CVP, the peripheral ID that you enter depends on the VRU type.
If the CVP is a routing client that handles new calls (VRU type 5), the peripheral service
ID be 1.
If the CVP receives pre-routed calls (VRU types 2, 3, 7, or 8), the peripheral service ID
be 2.
• Optionally, if you are using CVP as your VRU and want to perform advanced custom reporting
on VRU application details, configure 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. You must name the script "CAP" or "CAP, xxx", where xxx is any
string that makes the script name unique. (For example CAP, bankingApplication). You
might want to trigger TCD creation at important points in a script, such as when a caller
completes a transaction.
• There might be cases when a call is not queued, but instead sent to the agent directly (using
the LAA Select node) from the VRU. You must ensure the VRU PG is configured correctly
to ensure that such a call is considered answered at the VRU service rather than abandoned.
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. Do not set this parameter if you are using CVP as the
VRU.
Planning for Reporting on Unexpected Scripting Conditions
Follow these guidelines to ensure that you are able to identify when a routing script encounters
unexpected conditions:
• Decide whether you want calls that encounter unexpected scripting conditions to be counted
as default routed or as errors.
In deployments other than System IPCC, if you want the calls to count as default routed, plan
to configure default labels for each dialed number if you do not want calls that cannot be
routed to be reported as errors. When a call is routed to a default label, the call is added to
the count of default routed calls to the call type. If the call cannot be routed and a default
label is not assigned, the call is counted as an error. In System IPCC you do not configure
default labels.
Also, plan to include a Termination Node with Termination type of default label for all scripts
in which there is some unexpected input (else condition). This ensures that the call is added
to the count of default routed calls to the call type. If the call cannot be routed and a default
label is not assigned, the call is counted as an error.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
20
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Reporting on Short Calls
• In all scripts, account for failure by creating a path for calls that encounter unexpected
conditions. You might want to route these calls to voice mail, an announcement, or a busy
signal.
Planning for Reporting on Short Calls
If you are planning to use Short Calls in your system to filter out false abandons or to detect
when calls are answered and terminated too quickly to be considered handled, follow these
guidelines to obtain reporting data for short calls:
• You can configure abandoned short calls globally for all call types. Set the Abandon Call
Wait Time to the number of seconds that you want. If you want abandoned calls to adversely
affect the Service Level, define the Service Level threshold at the call type to be less than
the Abandon Call Wait time
Note: If you do not want to count any abandoned calls as short calls regardless of how quickly
they abandon, you can disable abandoned short calls by leaving the Abandon Wait Time
field blank for the Call Type.
• You can configure abandoned short calls for the peripheral. These are tracked for the services
that are configured for that peripheral. This does not apply to System IPCC or ARI
deployments, as those deployments do not use services. Set the Abandon Call Wait Time to
the number of seconds that you want. If you want abandoned calls to adversely affect the
Service Level, define the Service Level threshold at the service to be less than the Abandon
Call Wait time.
Note: If you do not want to count any abandoned calls as short calls regardless of how quickly
they abandon, you can disable abandoned short calls by leaving the Abandon Wait Time
field blank.
• You can configure answered short calls for agents and skill groups. This is not applicable
for System IPCC or ARI deployments. Set the Answered Short Call Threshold to the number
of seconds that you want when configuring the peripheral using the configuration tool. All
calls that have talk times less than the configured threshold will be considered as short calls.
These calls are incremented in the ShortCalls field in the Agent_Skill_Group_Half_Hour
and Skill_Group_Half_Hour database tables. If you do not want answered short calls to
impact Service Level, set the value to be less than the Service Level threshold.
Answered short calls are not available for the call type.
Note: If you do not want to count any answered calls as short calls regardless of how quickly
they terminate, you can disable answered short calls by leaving the Answered Short Call
Threshold field blank.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
21
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning the Historical Data Server for Reporting
Planning the Historical Data Server for Reporting
If you plan to use WebView as your reporting tool, you must configure an ICM/IPCC Distributor
Admin Workstation as a Historical Data Server (HDS). The HDS stores historical reporting
data and WebView connects to the HDS to retrieve report information.
If you are using the System IPCC deployment, the HDS is installed for you in each deployment
other than the All-In-One deployment. The All-In-One deployment is for lab use only; in this
deployment reporting data is stored on the Central Database and WebView connects to this
database to retrieve report information.
Follow these guidelines to ensure that your Historical Data Server is configured to meet your
reporting needs:
• Determine the size of the HDS. This section does not apply to System IPCC.
The size of the database depends on the size of your configuration and the amount of time
for which you want to retain data. Configuration that impacts the size of the HDS includes
the number of call types, skill groups, agents, skills per agent, routing clients, trunk groups,
services, peripherals, scripts, calls routed daily, and calls terminated daily. The larger the
configuration, the bigger the HDS must be to store data. For example, the historical Call
Type database tables store data for each call type for each five minute and half hour interval.
The amount of time that you want to retain data on the HDS also affects database size. Decide
how long you want to retain reporting data before it is purged automatically from the databases.
Data beyond the configured retention time is purged automatically each day at 12:30.
You can use the ICM/IPCC Database Administration (ICMDBA) tool to estimate the sizes
of your databases. The tool prompts you for your configuration information and the amount
of time that data is retained in the databases.
• In System IPCC deployments, the HDS size is configured automatically during installation.
During configuration, you determine how long you want to retain reporting data before it is
purged automatically from the databases. Data beyond the configured retention time is purged
automatically each day at 12:30.
• Determine how you want to back up the HDS.
You can back up the HDS either while the HDS is running or while it is offline (generally
when the contact center is closed or during a time with low call volume).
Generally, performing a backup during peak hours while running is not recommended.
Backing up while the HDS is running might impact performance, especially if you are backing
up a large amount of data. While the HDS database is being backed up, new data from the
Logger is stored in the transaction log. If the transaction log reaches it maximum capacity
before the HDS has completed the backup, updates to the database stop until an administrator
manually empties the log.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
22
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning which Report Templates to Use
Instead, back up at a regularly scheduled time when the contact center is not busy. You can
also take the HDS offline and perform a backup. However, the HDS is not available for
reporting when offline. If you plan to back up the HDS database while offline, you might
want to configure a secondary HDS to use for reporting during the backup interval.
• Determine the HDS backup schedule and the number of days for which data is retained on
the Logger.
Configure the number of days for which data is stored in the Logger central database and the
HDS. The Logger stores data for less time than the HDS. For example, you might store two
weeks of data on the Logger and a year of data on the HDS. You configure the amount of
time that data is stored on the Logger in relation to the schedule for HDS backups to ensure
that you do not lose data in the event that the HDS goes offline. When the HDS recovers
after going offline, it retrieves all data from the Logger for the interval for which data is
missing from the backup.
For example, if the HDS backup has data up to the last two weeks, the HDS would replicate
the last two weeks of data from the Logger when recovering from a failure. The amount of
data retained on the Logger cover, at a minimum, the time period between HDS backups.
For example, if the Logger stores data for two weeks, then you need to back up at least every
other week to ensure that you can recover all historical data after a HDS failure.
• Decide how many Historical Data Servers you require. For System IPCC deployments, the
required number of HDSs are installed automatically for your selected deployment.
The number of Historical Data Servers that you configure depends on how long the HDS
will take to backup and your reporting needs. If you are storing large amounts of data, backup
might take several hours. The HDS not be used to run historical reports while it is backing
up as this might decrease performance. If you want to run reports while the HDS is backing
up, you configure at least one additional HDS to use to run WebView reports.
See the Cisco ICM/IPCC Enterprise & Hosted Editions Release 7.1(1) Hardware and System
Software Specifications (Bill of Materials) for guidelines on Reporting Users per HDS and
HDS capacity.
See Also
Pre-Installation Planning Guide for Cisco ICM Enterprise Edition
ICM Installation Guide for Cisco ICM Enterprise Edition
Cisco IPCC Enterprise Edition System IPCC Installation and Configuration Guide
Planning which Report Templates to Use
Refer to the following sections of this guide to determine which report templates meet your
reporting needs:
• Useful Agent Statistics and Report Templates (page 45)
• Useful Customer Experience Statistics and Report Templates (page 77)
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
23
Chapter 1: Planning the IPCC Enterprise System to Meet Reporting Needs
Planning for Custom Reporting
• Useful Operational, Configuration, and Scripting Statistics and Report Templates (page 98)
Planning for Custom Reporting
To determine whether you require custom templates to meet your reporting needs, decide what
data you need and review the data available through WebView IPCC reports. If the existing
reports do not meet your needs, you can modify existing report templates or create custom report
templates. If you want to include the same types of data provided by the WebView reports in
new or modified templates, the customization might not impact database or WebView
performance.
However, if you require more detailed or application-specific data, the customization might be
more resource intensive and decrease the performance of the database or WebView. You
understand the performance impact of custom reports before running the reports using WebView.
Refer to the Template Design Guide Using InfoMaker for more information about creating
custom reports.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
24
Chapter 2
Understanding Cisco IPCC Reporting Architecture
The Cisco IPCC Enterprise system functions as a virtual ACD. Some of the capabilities include
intelligent multichannel contact routing, ACD functionality, network-to-desktop computer
telephony integration (CTI), voice response unit (VRU) integration, call queuing, and
consolidated reporting.
The Cisco IPCC Enterprise architecture affects reporting and differs considerably from the
architecture of ICM configurations that use ACDs.
To understand Cisco IPCC Enterprise reporting, you first understand the components, how the
Cisco IPCC Enterprise architecture differs from ICM with ACD configurations, and data flow
in Cisco IPCC Enterprise systems.
If you are using the System IPCC deployment, note that some of the IPCC Enterprise components
have been renamed with different naming conventions, although their functionality remains the
same. This guide refers only to the non-rebranded components. If you are using System IPCC
deployment, carefully read the section below that maps System IPCC components to
non-rebranded IPCC Enterprise components.
This chapter contains the following topics:
•
•
•
•
•
•
•
•
•
•
System IPCC to ICM Component Mapping, page 26
Overview of IPCC Enterprise Components, page 26
IPCC Enterprise Deployments Presented In This Guide, page 27
IPCC Enterprise Versus ICM Enterprise with ACD Architecture, page 28
IPCC Enterprise with Multichannel Applications Architecture, page 30
Understanding the Historical Data Server, page 32
Reporting Intervals , page 33
Data Comparisons, page 35
Reporting in a Multichannel Environment, page 37
Entities that Capture Reporting Data, page 42
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
25
Chapter 2: Understanding Cisco IPCC Reporting Architecture
System IPCC to ICM Component Mapping
System IPCC to ICM Component Mapping
The table below maps System IPCC machine types to their equivalent ICM components.
System IPCC Machine Type
Corresponding ICM Component
Central Controller
CallRouter, Logger
Agent/IVR Controller
System PG, CTI Server, CTI OS Server
Administration & WebView Reporting
Distributor Admin Workstation, Historical Data Server (HDS),
WebView
Multichannel Controller
Media Routing Peripheral Gateway (MR PG)
Outbound Controller
Outbound Dialer, MR PG
Overview of IPCC Enterprise Components
Basic components in an IPCC Enterprise system include:
• Cisco Intelligent Contact Management (ICM) software
The ICM software on the Central Controller provides ACD functionality, including monitoring
and controlling of agent state, routing and queuing of tasks, CTI capabilities, collecting
real-time data for agents and supervisors, and historical reporting for management. The
ICM/IPCC Central Controller consists of two components: CallRouter and Logger. ICM/IPCC
software also provides Outbound Option, which enables agents to make automated outbound
calls to customers.
• Cisco CallManager
Cisco CallManager provides features comparable with those of a traditional PBX system to
Voice over IP telephony devices such as Cisco IP phones and VoIP gateways. Cisco
CallManager handles the switching requirements of the IPCC system and allows deployment
of voice applications and the integration of telephony systems with Intranet applications.
• Voice Response Unit (VRU)
The Voice Response Unit serves several purposes. It acts as the routing client, is used for
information gathering through DTMF digit or ASR (Automatic Speech Recognition) collection,
provides self-service functionality, and serves as the queue point for the IPCC Enterprise
solution by playing announcements and/or music to the caller. This guide discusses two
VRUs supported by IPCC Enterprise: Cisco Customer Voice Portal (CVP) and Cisco IP-IVR.
Because these VRUs support different features and behave differently, IPCC Enterprise
reporting data is affected by the type of IVR you have deployed in your system. Note that
several other VRUs are also supported for IPCC Enterprise.
In System IPCC deployments, ARI deployments, and IPCC Enterprise deployments that use
the IPCC System PG, both IP-IVR and CVP is supported.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
26
Chapter 2: Understanding Cisco IPCC Reporting Architecture
IPCC Enterprise Deployments Presented In This Guide
• Peripheral Gateways (PGs)
Peripheral Gateways act as proxies for the Cisco CallManager and IVR components to the
ICM/IPCC Central Controller. They are also responsible for collecting historical and real-time
data on the IVR and agent activities and sending this data to the ICM/IPCC Central Controller.
PGs contain Peripheral Interface Managers (PIMs), which provide communication between
ICM/IPCC software and peripherals such as Cisco CallManager and IVR. If multichannel
options and/or Outbound Option have been integrated into the IPCC Enterprise system, the
configuration also includes Media Routing Peripheral Gateways (MR PGs) used to send
routing requests from the multichannel applications to ICM/IPCC software. A single Media
Routing Peripheral Gateway (MR PG) can support multiple applications; you configure a
separate PIM for each application.
• Agent/Supervisor Desktops
IPCC Enterprise supports two agent/supervisor desktop solutions: Cisco CTI Object Server
(CTI OS) and Cisco Agent/Supervisor Desktop (CAD). CTI OS and CAD are server-based
CTI solutions that provide desktops used by contact center agents and supervisors. CTI OS
is a toolkit that enables you to create customized agent and supervisor desktops.
• Multichannel options
Multichannel options include Cisco Collaboration Server and Cisco E-Mail Manager. Cisco
Media Blender and Cisco Dynamic Content Adapter are optional components of Collaboration
Server. Collaboration Server provides the ability for agents to share information with customers
over the Web, such as Web pages, forms, and applications, while at the same time conducting
a voice conversation or a text chat. Cisco E-Mail Manager manages high volume of customer
inquiries submitted to company e-mail boxes or a Web site. E-Mail Manager selects agents
and teams to receive incoming messages, categorizes and prioritizes messages, suggests
response templates, and, if desired, sends automatic responses. If included in the IPCC
Enterprise system, multichannel options connect to ICM/IPCC software component in the
system. The multichannel options are responsible for sending the incoming task request to
ICM/IPCC software for agent/skill group selection through the MR PG and placing the
selected agent into session with the task. Agent status and activity for Collaboration Server
and E-Mail Manager is sent to ICM/IPCC software through the Agent PG.
IPCC Enterprise Deployments Presented In This Guide
This guide discusses several types of IPCC Enterprise deployments, and there are reporting
differences between these configurations. When necessary, this guide calls out the differences
between the deployments for reporting. If no differences are noted, the reporting information
is the same for all deployments.
The configurations presented are:
• IPCC Enterprise deployments with an IPCC System PG. In these deployments, the PG
contains a single peripheral for Cisco CallManager and IP-IVR. The metrics gathered for
reporting are consolidated from a single peripheral. However, when System PG with CVP
is used in these deployments, there are two peripherals present and the metrics for reporting
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
27
Chapter 2: Understanding Cisco IPCC Reporting Architecture
IPCC Enterprise Versus ICM Enterprise with ACD Architecture
are gathered from the two peripherals (As the System PG and CVP are on different
peripherals).
• System IPCC deployments. These deployments use the IPCC System PG. While the manner
in which reporting data is gathered for IPCC Enterprise deployments with an IPCC System
PG and System IPCC deployments is largely the same, the two deployments are configured
differently. System IPCC deployments are configured through IPCC Web Administration,
while IPCC Enterprise deployments with an IPCC System PG are configured through ICM
Configuration Manager.
• IPCC Enterprise deployments with PGs other than the IPCC System PG. In these
deployments, the Cisco Callmanager and VRU are connect to the ICM/IPCC using different
PIMs in the case of the Generic PG or using different PGs, such as CallManager PG and
VRU PG. The metrics gathered for reporting therefore span two different peripherals.
• ARI deployments. In these deployments, an ACD/PBX is connected to Unified ICM by an
ARS PG. This allows Unified ICM to select an agent and to route calls directly to that agent.
IPCC reporting templates are selected to report on the ACD/PBX. Peripheral Service and
Truck Group reports are not applicable for an ARI deployment.
IPCC Enterprise Versus ICM Enterprise with ACD Architecture
This section describes the differences in architecture and reporting between ICM Enterprise
with ACD systems and IPCC Enterprise systems.
ICM Enterprise with ACD Architecture
In an ICM Enterprise system with an ACD, the configuration includes one PG that connects to
the ACD. An IVR could be used for information gathering or self-service, but is not mandatory.
The calls are queued within the legacy ACD system.
The following image depicts the topology of a basic legacy ACD site.
Figure 1: ICM Enterprise with ACD architecture
Note: Traditional ICM Enterprise with ACD configurations might also include a VRU. However,
in an ACD configuration VRUs are optional and serve the purpose of collecting caller
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
28
Chapter 2: Understanding Cisco IPCC Reporting Architecture
IPCC Enterprise Versus ICM Enterprise with ACD Architecture
information. A VRU cannot be used for call queuing in traditional ACD configurations; the
ACD is used to queue the call.
This deployment could also be an IPCC Gateway deployment, in which a parent ICM Enterprise
system connects to a child IP ACD (either IPCC Enterprise with the IPCC System PG or IPCC
Express). In this case, the ACD PG would be the IPCC Gateway PG.
IPCC Enterprise Architecture
Unlike the ICM Enterprise with ACD configuration which performs its own queuing, the IPCC
Enterprise system requires a VRU in order to queue calls. The VRU can be used for information
gathering and self-service in addition to queuing. The IPCC Enterprise system therefore connects
to both a VRU and the Cisco CallManager. The Cisco CallManager supports the agent activity
and the VRU interacts with ICM/IPCC software for task queuing. Reporting data is gathered
both while tasks are at the CallManager and while they are at the VRU.
The following image depicts the topology of an IPCC Enterprise site that uses separate PGs for
the Cisco CallManager and IP-IVR, with IP-IVR as the VRU, in which multichannel applications
have not been deployed. Note that for System IPCC deployments and IPCC Enterprise with
IPCC System PG deployments, the Cisco CallManager and VRU are on the same peripheral.
However, when IPCC System PG with CVP is used in the System IPCC and IPCC Enterprise
deployments, the Cisco CallManager and VRU are on different peripherals
Figure 2: IPCC Enterprise Architecture
Refer to either the Cisco IPCC Enterprise Installation and Configuration Guide or the Cisco
IPCC Enterprise Edition System IPCC Installation and Configuration Guide for more details
about your specific deployment.
IPCC Enterprise call flows differ significantly from ICM/IPCC with traditional ACD call flows.
In ICM/IPCC with traditional ACD systems, ICM software identifies the ACD service to which
to route the call and notifies the routing client. The call is queued and answered by an agent
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
29
Chapter 2: Understanding Cisco IPCC Reporting Architecture
IPCC Enterprise with Multichannel Applications Architecture
selected by the ACD at the ACD service. The ACD service retains and tracks all the queuing
and agent information.
While legacy ACD systems track statistics using the ACD service, IPCC Enterprise systems
disperse statistics among several components, including
• Call type. These statistics are gathered by the ICM/IPCC Central Controller. While the service
in the ICM/IPCC Enterprise with ACD system determines call treatment, the call type in the
IPCC Enterprise system determines call treatment and can be used to report on calls and how
they were handled.
• Service associated with the VRU, for deployments other than System IPCC and ARI, which
tracks statistics such as wait times and VRU activity. These statistics are gathered by the
VRU PG. In System IPCC and ARI deployments, the VRU services are not configured. You
monitor these statistics using call type.
• Skill groups associated with the agent, which track statistics such as talk/active time,
hold/paused time, and wrap up time.
The IPCC Enterprise system disperses statistics in this manner because the ICM/IPCC software
component does not have media termination points; physical voice calls must be sent to the
VRU while being queued by the ICM/IPCC Router.
The data is stored in ICM/IPCC software databases for centralized reporting. Real-time data is
stored in the ICM/IPCC Central Controller local database and historical data is stored in the
ICM/IPCC historical database located on the ICM/IPCC Historical Data Server (HDS).
IPCC Enterprise with Multichannel Applications Architecture
The E-Mail Manager and Collaboration Server provide multichannel capabilities to the IPCC
Enterprise system. Agents can be configured to handle voice calls, e-mail messages, online chat
sessions, and integrated voice/Web content sharing sessions. Both the E-Mail Manager and
Collaboration Server connect to the ICM/IPCC Central Controller through an Media Routing
MR PG (MR PG), which is used for routing and to the Cisco CallManager PG (or agent PG),
which sends agent status to the ICM/IPCC Central Controller. This architecture is illustrated in
the following diagram.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
30
Chapter 2: Understanding Cisco IPCC Reporting Architecture
IPCC Enterprise with Multichannel Applications Architecture
Figure 3: IPCC Enterprise with Multichannel Options
When the E-Mail Manager receives an e-mail task request, it sends the task information to the
ICM/IPCC Central Controller for routing purposes. The ICM/IPCC Central Controller returns
an agent and skill group, and the E-Mail Manager pushes the task to the agent. If an agent is
not available, the task queues logically at the E-Mail Manager until the agent becomes available.
Because the task does not involve voice, physical queuing is not needed.
When the Collaboration Server receives a single-session or multi-session chat task request, it
sends the task information to the ICM/IPCC Central Controller for routing purposes. The
ICM/IPCC Central Controller returns an agent and skill group, the Collaboration Server pushes
the task to the agent. If an agent is not available, the task queues logically in the ICM/IPCC
queue of the Web Collaboration Option until the agent becomes available. Because the task
does not involve voice, physical queuing is not needed.
If the Collaboration Server is used for callback, delayed callback, or blended collaboration
sessions, it also sends the task information request to the ICM/IPCC Central Controller for
routing purposes. However, the Media Blender component is also involved in the task process.
When the ICM/IPCC Central Controller returns an agent and skill group, the Media Blender
ensures the correct agent and caller engage in an automatic phone call and Web collaboration.
If an agent is not available, the task queues logically in the ICM/IPCC queue of the Collaboration
Server until the agent becomes available. Because the task does not involve voice until the
Media Blender actually places the call, physical queuing is not needed.
The Collaboration Server implementation might also include the Dynamic Content Adapter
(DCA) component that enables agents and customers to share Web content that is secure,
personalized, live, interactive, or transactional (SPLIT content).
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
31
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Understanding the Historical Data Server
Understanding the Historical Data Server
Historical data is stored in the ICM/IPCC Logger's central database and in the Historical Data
Server (HDS) on the Distributor Admin Workstation.
You must use the HDS if you want to use WebView for reporting. Using the Logger's central
database for reporting with WebView is not supported. The only exception to this is for the
System IPCC All-In-One deployments that are for lab use only.
Typically, you set up two Distributor Admin Workstations as HDS machines. The same
fault-tolerant strategy that applies to the real-time Distributor AW also applies to the HDS; that
is, when the primary HDS fails, the Client Admin Workstation automatically switch over to use
the backup HDS. In System IPCC deployments, the appropriate number of HDSs for your
configuration are installed automatically.
Relationship Between the Logger and Historical Data Server
Each Historical Data Server (HDS) is connected to a single Logger. The Logger's central database
replicates historical data to the HDS. The replication process may have a latency of about one
to five minutes because the Logger replicates data table-by-table on the HDS.
You configure the number of days for which data is stored in the Logger central database and
the HDS. The Logger stores data for less time than the HDS. For example, you might store two
weeks of data on the Logger and a year of data on the HDS. You configure the amount of time
that data is stored on the Logger in relation to the schedule for HDS backups to ensure that you
do not lose data in the event that the HDS goes offline. When the HDS recovers after going
offline, it retrieves all of the data on the Logger for the interval for which data is missing from
the backup, and you manually restore the rest of the data from the last HDS backup. For example,
if the HDS backup has data up to the last two weeks, the HDS would replicate the last two weeks
of data from the Logger when recovering. The amount of data retained on the Logger cover, at
a minimum, the time period between HDS backups. For example, if the Logger stores data for
two weeks, then you need to back up at least every other week to ensure that you can recover
all historical data.
Logger and Historical Data Server Failure and Recovery
If the Logger connected to the HDS goes offline, the HDS does not connect to a different Logger.
For example, if the HDS is connected to Logger B, it does not connect to Logger A if Logger
B fails. When Logger B comes back up, it recovers data from Logger A and begins to receive
current historical information. Once the Logger has recovered all of the data from Logger A, it
begins to replicate this data to the HDS. If reports are run from this HDS for recent intervals
while the Logger is offline, or while the Logger is in the process of recovering or replicating
data, you might not see data for those intervals in reports. This is temporary and you will see
the data once the replication process for the tables utilized by the reports is complete. If you are
using a fault-tolerant system with two HDS Distributor Admin Workstations, you can run reports
using the backup HDS while the primary HDS is not receiving data.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
32
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting Intervals
If the HDS goes offline and you are using a fault-tolerant system with two HDS Distributor
Admin Workstations, you can run reports using the backup HDS. When the HDS comes back
up, it recovers data from the last HDS data backup. It also replicates data from the Logger for
the most recent data not available in the backup. The recovery data replication is faster than
regular Logger-HDS data replication. Once the HDS has recovered to its typical Logger-HDS
latency of one to 5 minutes, data replication proceeds as usual. If you are not using a fault-tolerant
system, you will not see data in historical reports until the HDS is restored. You might also
notice missing data as the replication process is in progress. This is temporary and you will see
the data once the replication process for the tables utilized by the reports is complete.
See Also
Pre-Installation Planning Guide for Cisco ICM Enterprise Edition
ICM Installation Guide for Cisco ICM Enterprise Edition
Cisco IPCC Enterprise Edition System IPCC Installation and Configuration Guide
Reporting Intervals
The ICM/IPCC Central Controller collects historical and real-time data.
The historical data is stored in the ICM/IPCC historical database in summary five-minute and
half-hour intervals. The ICM/IPCC Router forwards real-time contact center data to the
Distributor AW local database. This real-time and historical data can be accessed by client AWs
and the WebView reporting software.
The Central Controller also collects event-driven records, which include Route_Call_Detail
(RCD) and Termination_Call_Detail (TCD) records. RCD records contain details for each task
routed and TCD records contain details for every task that is connected and the terminated.
In IPCC Enterprise deployments with IPCC System PG with CVP and System IPCC with CVP,
the following three TCD Reports are generated and stored in ICM/IPCC historical database:
• One record from the initial CTI route point (Cisco CallManager PG)
• One from the VRU (VRU PG)
• One from the agent (Cisco CallManager PG)
In IPCC Enterprise deployments with the IPCC System PG and System IPCC deployments,
one TCD record is generated and in IPCC System PG deployments with CVP, the TCD records
are generated as in the IPCC Enterprise.
Note: For accurate reporting, the time on the Peripheral Gateways and Central Controller be
synchronized.
Real-time Data
In real-time, each PG passes current status information to ICM/IPCC software. Every 15 seconds
(by default), the ICM/IPCC system forwards the latest data to the Distributor AW local database.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
33
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting Intervals
The current, or real-time data, which is kept in the Router's memory, includes data about agents,
skill groups, services, call types, trunk groups, and other ICM/IPCC entities. The following
image illustrates how data is moved to the local database.
Figure 4: Real-time Data Moved to Local Database
Note: This refresh rate applies only to real-time reporting with WebView, which is not the same
mechanism used on the CTI agent desktop.
Real-time data is stored in several increments, as described in the following table.
Table 1: Real-time Database Data Increments
Real-time Data
Increment
Description
Half
"Half" values contain a value for the current half-hour. The current half-hour is defined as the time
period falling between xx:00:00 and xx:29:59, or xx:30:00 and xx:59:59.
For example, if it is currently xx:18:33, the CallsOfferedHalf real-time element contains a value
that reflects the first 18 minutes and 33 seconds of the specific half-hour. When a new half-hour
begins, at time (xx:00:00 or xx:30:00), the database element is reset to zero.
Now
In the real-time tables, "Now" values contain a snapshot of activity at a particular instant.
For example, ICM/IPCC software tracks CallsQNow, which is the number of calls currently in queue
for a service or route. When a call is answered, the CallsQNow count is reduced immediately by
one (-1) because the call has left the queue. This change is seen at the next real-time update of the
WebView report screen.
To5
The "To5" values track data on a rolling five-minute basis. The rolling five-minute data employs a
"sliding" five-minute window. The To5 data is updated every ten seconds in the database.
Today
To arrive at values for today, ICM/IPCC software adds the values at the end of each half-hour interval
since midnight. It also counts the values for the current half-hour. At the end of each half-hour, half
hour data (for example CallsOfferedHalf) is summed into the Today data. At midnight, the real-time
Today count is cleared in the database. Midnight is defined using the time of the peripheral.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
34
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Data Comparisons
Historical Data
ICM/IPCC software stores historical information in five-minute and half-hour intervals. The
ICM/IPCC Central Controller writes these records to the central database (on the Logger). These
records are replicated to the Historical Data Server (HDS) and are used for historical reporting.
The five-minute data includes many of the same data elements as found in the real-time data.
Every five-minutes, ICM/IPCC software copies the real-time data to the five-minute tables in
the historical database. In this way, a snapshot of the real-time data is kept in the historical
database and used as historical data. The real-time data, which is written to the Admin
Workstation local database, continues to be overwritten with new values at each real-time update.
The historical data fields are stored in the database with the extension "ToHalf" (for example,
Skill_Group_Half_Hour.CallsHandledToHalf). These elements contain a value for a completed
half-hour interval. The completed half-hour interval is the time period falling between xx:00:00
and xx:29:59, or xx:30:00 and xx:59:59.
Half-hour data is populated in the database only for completed half-hour intervals. For example,
if a call is offered at 15:47:00, it will be counted as an offered call in the 15:30:00 to 15:59:59
half-hour interval. Data for this half-hour interval is not written to the database until the interval
is complete (for example 16:00:00). Therefore, the latest calls offered half-hour data is available
for the previous completed half-hour interval (that is, the 15:00:00 to 15:29:59).
Data Comparisons
When running reports, you might compare data within a report and across reports. This section
explains how you compare data and describes issues that you might encounter when comparing
data that not be compared because of configuration, scripting, or when the records are written.
Real-time and Historical Record Comparison
Data in real-time and historical records not be compared. Counts in real-time data (for example
CallsHandledTo5) do not match up with counts in the historical half-hour records (for example,
CallsHandledToHalf) because the real-time data is moved to the historical database at the end
of each half-hour interval.
Consider this example, at 8:55 a call comes into the contact center and is answered by an agent.
The real-time count for CallsAnswered would be increased by one (+1). However, the answered
call would not be populated in the half-hour data until 9:00, when the half-hour interval ends.
Therefore, between 8:55 and 9:00 the real-time data would show the answered call, but the
half-hour data would not because the latest data in the historical database is for the 8:00 to
8:29:59 interval.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
35
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Data Comparisons
Call Type and Skill Group Record Comparison
In ICM Enterprise with ACD environments, services define call treatment. All skill groups
belong to specific services and, therefore, skill group data rolls up to the service. Reports for
services provide call treatment information for all of the skill groups assigned to those services.
In IPCC Enterprise systems, call types define call treatment and provide the types of statistics
that services provide in ACD environments. However, skill groups are associated with call types
only through routing scripts; they are not assigned to call types through static configuration. In
routing scripts, you first determine the call type of a call then base routing decisions on which
skill groups are capable of handling that type of call. You can assign multiple skill groups to a
call type in a routing script and can assign a skill group to multiple routing scripts for different
call types. Therefore, there is not necessarily a 1:1 relationship between call types and skill
groups.
You might notice that data for a call type and the skill group(s) related to the call type through
a routing script do not match. If a skill group is used in multiple scripts, reporting for that skill
group includes data for all of the call types to which it is assigned. If a call type routes to multiple
skill groups, data for the call type is distributed among those skill groups.
You compare call type and skill group records only if all of the following are true:
• There is a 1:1 correlation between a call type and skill group. Your routing script cannot
queue to two skill groups simultaneously if you want a 1:1 correlation. This 1:1 correlation
is not a useful configuration; in production environments, the routing scripts might queue to
multiple skill groups, and an individual skill group might be used in several scripts that are
associated with different call types. For example, if you configure a separate call type for
Redirection on No Answer calls, you might want to queue to the same skill groups to which
the call was queued initially.
• The call type is qualified again in the routing script before the call is offered to an agent using
the LAA and/ or Queue node to avoid extraneous offered and flow out information.
However, even if you configure your scripts using the 1:1 call type to skill group correlation
and change the call type when appropriate, you will still notice some reporting discrepancies
for the number of tasks offered and the manner in which hold time for consult calls is reported.
The number of tasks offered to the call type and skill group will not match because call type
tasks offered is incremented for each task routed using that call type, but skill group tasks offered
is only incremented when the task is offered to an agent in that skill group.
The call type and skill group hold time and talk time might not balance for agents who are in
hold state in a consult call. This is reported as hold time for the call type and talk time for the
skill group because the state of the consult call is hold, but the agent not on hold is in talking
state as he or she is talking to the customer on the other line.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
36
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting in a Multichannel Environment
Half-hour Boundary Issues for Reporting Data
Counts that would typically match up for a day, such as CallsOffered and CallsHandled, might
not always match up over specific half-hour intervals. This is because the counts for some data
elements might be increased across half-hour boundaries. Consider this example, at 8:55 a call
comes into the contact center and is answered by an agent. The agent completes the call at 9:05.
In the historical database, the call is counted as offered in the 8:30:00 to 8:59:59 interval. The
call is also counted as handled in the 9:00:00 to 9:29:59 interval. Therefore, if you run a report
for the 9:00:00 to 9:29:59 interval, you will see in reports that tasks handled does not equal
tasks offered for the interval.
You also might notice that tasks offered does not equal task abandoned + tasks handled for a
half-hour interval. Tasks offered reflects the number of calls and tasks that were offered to
agents in this interval, while tasks handled and tasks abandoned might include calls that were
offered in the last interval and completed in this interval. Some historical report templates group
statistics into "Completed Tasks", to indicate that the statistics represent all calls and tasks that
completed in this half hour interval.
In general, half-hour boundary issues are reduced if you run daily reports. However, if your
contact center runs 24 hours a day, you might still notice half-hour discrepancies for the 11:30:00
to 11:59:59 and 12:00:00 to 12:29:59 intervals.
Reporting in a Multichannel Environment
WebView reporting provides data on task and agent activity for multichannel options, including
Collaboration Server and E-Mail Manager, if they are deployed in your IPCC Enterprise system.
To interpret report data correctly, you have a good understanding of how Media Routing Domains
and Media Classes are used, how agent availability and routing ability are determined, and
differences in report data between voice tasks and non voice tasks.
Media Routing Domains
ICM/IPCC software uses Media Routing Domains (MRDs) to organize how requests for different
media are routed. A MRD is a collection of skill groups and services that are associated with a
common media, such as voice, chat, e-mail, or blended collaboration which blends voice and
Web collaboration. ICM/IPCC software uses the MRD to route a task to an agent who is
associated with a skill group and a particular medium. When configuring your IPCC Enterprise
system, you first configure MRDs on ICM/IPCC software and then enable the appropriate MRDs
on the Collaboration Server and E-Mail Manager applications. MRDs have unique IDs across
the enterprise. Each skill group is assigned to a Media Routing Domain.
Note: Multimedia integration is not supported for ARI.
The Voice MRD is created by default for all deployments. In System IPCC deployments, MRDs
for all media are configured by default.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
37
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting in a Multichannel Environment
Media Classes
A Media Class describes the type of requests that you want to set up for routing on ICM/IPCC
software.
Each Media Routing Domain belongs to a Media Class.
Media Classes available in IPCC Enterprise systems include:
• Voice, which includes incoming and outgoing phone calls. Voice also includes Web Callback
and Delayed Callback through the Web Collaboration Option.
• Single-session chat, through Web Collaboration Option
• Multi-session chat, through Web Collaboration Option
• Blended collaboration, through Web Collaboration Option
• E-mail, through E-Mail Manager Option
If your system is designed to handle voice-calls only, you only have the Voice Media Class.
Agent Availability and Route Ability
The ability for ICM/IPCC software to route a call or multichannel task to an agent depends on
the agent's route ability and availability within the MRD of the call or task. WebView reports
contain fields indicating agents' availability in the MRD.
An agent might be in Routable or Not Routable mode for each MRD to which he or she belongs.
Route ability refers to whether the ICM/IPCC or the Web Collaboration Option or E-Mail
Manager Option is configured to assign tasks to the agent. For example, your IPCC Enterprise
system might be configured to allow the Web Collaboration Option to select an agent to handle
a task. In this case, ICM/IPCC software gathers reporting data for those tasks, but does not
perform the routing. If ICM/IPCC software is configured to assign the task, it both routes and
reports on the task.
For voice calls, ICM/IPCC software is always configured to route the call. Therefore, the agent
is always Routable.
The following table describes what it means when an agent is Routable and Not Routable.
Table 2: Agent Route ability
Term
Description
Routable
ICM/IPCC software is configured to assign tasks to the agent
Not Routable
The Web Collaboration Option or E-Mail Manager Option is configured to assign
tasks to the agent.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
38
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting in a Multichannel Environment
While Route ability determines whether the ICM/IPCC Router is allowed to assign tasks for
this MRD, the agent's Availability determines whether the agent is capable of handling new
tasks.
An agent is Available, or eligible to be assigned a task in this MRD, if the agent meets all of
these conditions:
• The agent is in any state other than Not Ready state for this MRD.
• The agent is not working on a non-interruptible task in another MRD. Only e-mail tasks are
interruptible, meaning that ICM/IPCC software can assign the agent another task while he
or she is working on an e-mail. Voice calls, single-session chat sessions, multi-session chat
sessions, and blended collaboration chat sessions cannot be interrupted.
• The agent has not reached the maximum task limit for this MRD. For Voice, single-session
chat, e-mail and blended collaboration MRDs, the task limit is always one task. For the
multi-session chat MRD, the task limit is customized through the Web Collaboration Option
administration application.
An agent is Not Available in this MRD if the agent is Not Ready, working on a voice,
single-session chat, multi-session chat, or e-mail task, or has reached his or her maximum task
limit.
Therefore, an agent is:
• ICM available if he or she is Routable and Available for the MRD. This means that the agent
can be routed a task by ICM/IPCC software.
• Application available if he or she is Not Routable and Available for the MRD. This means
that the agent can be routed a task by the Web Collaboration Option or E-Mail Manager.
Consider the following call/task scenarios and how they affect agent mode and availability.
Table 3: Scenario 1: Not Routable - Multi-session Chat, then Voice
Scenario
Result
The agent is logged into two MRDs, multi-session chat and ICM/IPCC software does not assign a task to the agent
voice.
from the Voice MRD, since the agent is working on a
non-interruptible task in the Multi-session Chat MRD.
The agent is not routable in the multi-session chat MRD.
The agent is Not Available in Voice.
The agent is assigned a task in the multi-session chat MRD
by the Web Collaboration Option.
Table 4: Scenario 2: Not Routable - Voice then E-Mail
Scenario
Result
The agent is logged into two MRDs,
multi-session chat and voice.
ICM/IPCC software does not assign e-mail tasks to the agent. The agent
is Not Available in the e-mail MRD.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
39
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting in a Multichannel Environment
Scenario
Result
The agent is not routable in the e-mail MRD. e-mail tasks can still be placed in the agent's personal queue in this scenario
by the E-Mail Manager Option. e-mail tasks might also be sent to the
The agent is assigned a call in the Voice
agent's queue as a result of a customer responding to an E-Mail from the
MRD.
agent. See ICM software: Cisco E-Mail Manager documentation for
complete information on routing E-Mail tasks.
Table 5: Scenario 3: Not Routable - Voice then Single-session Chat
Scenario
Result
The agent is logged into two MRDs, single-session chat and
voice.
Web Collaboration Option does not assign
single-session chat tasks to the agent. The agent is Not
Available in single-session chat.
The agent is not routable in the single-session chat MRD.
The agent is assigned a call in the Voice MRD.
Table 6: Scenario 4: Routable - Maximum task limit
Scenario
Result
The agent is logged into a multi-session chat MRD
(maximum task limit for the agent in this MRD is 6).
ICM/IPCC software continues to assign tasks to the agent
until the agent has reached his or her maximum task limit.
The agent is ICM Available in the multi-session chat MRD,
even though the agent is Active on a task.
The agent is routable in the multi-session chat MRD.
The agent is assigned a task in the multi-session chat MRD.
Table 7: Scenario 5: Routable (busy on non-interruptible task)
Scenario
Result
The agent is logged into two MRDs, multi-session
chat and voice.
ICM/IPCC software does not assign a multi-session chat task to
the agent, since the agent is working on a non-interruptible task
in the voice MRD. The agent is Not Available in the multi-session
The agent is routable in the multi-session chat MRD. chat MRD even though the agent is Not Active in multi-session
chat skill groups.
The agent is assigned a voice call in the voice MRD.
Table 8: Scenario 6: Routable (busy on interruptible task)
Scenario
Result
The agent is logged into two MRDs, e-mail and voice.
ICM/IPCC software can assign a voice call to the agent, since
the agent is working on an interruptible task in the e-mail
MRD. The agent is ICM Available in Voice MRD.
The agent is routable in the e-mail MRD.
The agent is assigned a task in the e-mail MRD
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
40
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Reporting in a Multichannel Environment
Multichannel Reporting Data
The ICM/IPCC databases store information about agent activity and tasks routed by ICM/IPCC
software, including tasks that are submitted to ICM/IPCC software by the Web Collaboration
Option or E-Mail Manager Option. Reports contain a Media field, when appropriate, to identify
the MRD of each task included in the report.
The following table describes major differences between voice and non-voice tasks in reports.
Non-voice tasks include single-session chat, multi-session chat, e-mail, and blended collaboration.
Table 9: Report Data for Multi-Channel Options
Type of
Data
Data for Voice Tasks
Data for Non-Voice Tasks
Task
direction
Task direction can be both incoming (agent Task direction is always incoming, and values of report fields
receives call) and outgoing (agent places pertaining to outgoing non-voice tasks are set to null.
call).
Note that calls placed by Cisco Outbound
Option appear as incoming calls because of
the manner in which the Outbound Option
Dialer places calls between agents and
customers.
Session
ownership
changes
The ownership of a voice task can change
through the life of the call. Agents can
transfer the call, conference in another agent
or supervisor, and request supervisor
assistance. Supervisors can barge into a call,
meaning that they join the call, or intercept
a call to take ownership of the call
immediately.
Non-voice tasks do not change session ownership. These tasks
cannot be transferred and conferencing is not possible , and
supervisors cannot barge into or intercept the task.
Note that while it is possible for a Web Collaboration agent
to allow another agent to join a session and then drop the
session, leaving the second agent and the caller in session
together, this is not the same as a voice call transfer.
ICM/IPCC software interprets this as two different sessions,
one for the original agent and one for the second agent.
Also, while E-Mail Manager agents can forward messages to
other agents, this is not the same as a voice call transfer.
ICM/IPCC software interprets messaging forwarding as two
different sessions, one for the original agent and one or the
receiving agent.
Values of report fields pertaining to transfer, conference,
supervisor assist, barge in, and intercept are set to zero.
Short calls
Voice calls are considered to be short calls
if they disconnect within the time boundaries
defined in the Agent Desk Settings in
ICM/IPCC software for short tasks.
The Collaboration Server and E-Mail Manager do not enable
administrators to configure a short task time boundary.
Therefore, non-voice tasks are not reported as short tasks,
even if they disconnect within the short task time defined in
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
41
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Entities that Capture Reporting Data
Type of
Data
Data for Voice Tasks
Data for Non-Voice Tasks
Agent Desk Settings. Values of report fields pertaining to
short calls are set to zero.
Multiple
tasks
Agents can handle one voice task at a time. Agents might be configured to handle multiple non-voice
Agents can handle a voice task and an e-mail tasks, such as multi-session chat, at the same time. If an agent
task simultaneously.
is engaged in several non-voice tasks, the reports contain data
for each of the tasks.
e-mail is an interruptible MRD and agents
handling e-mail tasks can be interrupted with These tasks might be from multiple skill groups. For instance,
a voice call. Reports show the agent as
because e-mail is an interruptible MRD, an agent can be
Active for both the e-mail and voice task. working on an e-mail tasks while also working on a task or
call in any other medium.
Also, an agent might be working on three multi-session chat
sessions, each from a different skill group. Note that task
duration fields are also affected in reporting. For instance,
the half-hour duration fields might have a value greater than
30 minutes for non-voice tasks.
Service
Level
You determine which Service Level type
you want to use for voice tasks and this
setting affects the reporting data.
The Service Level for non-voice tasks is always set to "ignore
abandoned calls". The Service Level setting affects the Service
Level data in reports for non-voice tasks.
Reporting Tools for Multichannel Applications
You can use the WebView report templates provided by ICM/IPCC software to report on
multichannel skill groups, agents and tasks. However, the IPCC Enterprise WebView reports
do not contain details regarding the Collaboration Server or E-Mail Manager-specific events
that transpire during a Collaboration Server or E-Mail Manager task. For example, these
WebView reports show that an agent handled a chat task, but do not provide the text of a sent
chat message. Also, the reports show than an agent is currently Active on an e-mail task, but
do not show the number of e-mails received by an agent. The multichannel applications have
separate reporting tools, available through the applications, that provide application-specific
details about the sessions.
Entities that Capture Reporting Data
For each task flow, a single task, such as a voice call or Web collaboration chat session, passes
through several reporting entities. Reporting entities are objects configured in ICM/IPCC
software, including Call Types, Services, Skill Groups, and Agents. These entities capture
particular information about the task. IPCC Enterprise reporting entities are described in the
following table.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
42
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Entities that Capture Reporting Data
Table 10: Reporting Entities
Reporting Entity
Description
Call Type
The Call Type object determines which routing script to run for a particular task,
and may represent a service that a contact center provides. The Call Type is matched
to a Dialed Number for voice calls, or a Script Selector for non-voice calls.
For voice calls, a call type can be comprised of caller entered digits (CED) and
calling line ID.
For non-voice calls, call types can be comprised of the script selector, AppString1,
and AppString2.
Peripheral VRU Service - Service The Service identifies a function that the contact center provides. A Service
associated with VRU application(s) associated with VRU applications tracks application activity including queuing,
self-service and information gathering.
This does not apply to System IPCC
or ARI deployments.
Note that if you are using CVP, you only configure one or two services, depending
on your configuration.
Skill Group
A Skill Group represents a group of agents, who might be grouped together because
of common expertise, common skill level, or other business reasons.
Agent
An agent is a person who handles tasks in a contact center.
Note: Outbound Option calls (outbound campaign voice calls) do not pass through the Call
Type reporting entity and Call Type data is not gathered for Outbound Option calls.
The following table illustrates the reporting entities that are traversed by different kinds of tasks.
Table 11: Reporting Entities for Types of Tasks
Type of Task
Call Type
Affected?
Peripheral VRU Service
Skill Group Affected?
Affected?
Not Applicable for System
IPCC or ARI Deployments.
Agent
Affected?
ICM-routed voice call using
Queue to Skill Group script
node
yes
yes, if the call goes to the
VRU
yes
yes
Incoming voice call to an agent's no
direct extension
no
yes, default skill group
yes
ICM-routed call using
Agent-to-Agent script node
yes
yes, if the call goes to the
VRU
yes, default skill group
yes
ICM-routed call using Queue to yes
Agent script node
yes, if the call goes to the
VRU
yes. If the agent is not logged yes
into the skill group specified
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
43
Chapter 2: Understanding Cisco IPCC Reporting Architecture
Entities that Capture Reporting Data
Type of Task
Call Type
Affected?
Peripheral VRU Service
Skill Group Affected?
Affected?
Not Applicable for System
IPCC or ARI Deployments.
Agent
Affected?
in the Queue to Agent node,
the default skill group is used.
To understand how reporting entities are used in reporting, consider an example of a typical
voice call. In this example, the routing script uses the Queue to Agent, TranslationRoutetoVRU,
Queue to Skill Group and LAA Select nodes.
Note that for IPCC Enterprise with the IPCC System PG and System IPCC deployments,
TranslationRoutetoVRU is not necessary. However, TranslationRoutetoVRU is required when
System PG with CVP is used for IPCC Enterprise and System IPCC deployments.
In the simplest scenario, a voice call comes into a CTI route point on the Cisco CallManager
and then either goes to an initial Call Type or is queued to an agent using the Queue to Agent
script node. If no agents are available, the call then goes to the VRU through the
TranslationRtetoVRU script node. After the call is sent to the VRU, the call is queued to a skill
group through the Queue to Skill Group node. At this point, the Skill Group is also affected by
this call. When an agent becomes available, the Agent is affected by this call. The route associated
with the peripheral agent service is also affected.
If agents are available when the call comes in, the call does not have to go the VRU. The call
is routed directly to the agent through the LAA Select node within the routing script. For this
task, the Agent and the default skill group are affected by this call.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
44
Chapter 3
Managing Agents
Managing agents in a contact center might involve measuring performance, determining
incentives, and identifying training needs. IPCC Enterprise WebView reports provide metrics
that enable you to monitor real-time agent activity and review historical trends for agents.
This section explains which reporting metrics are useful for managing IPCC Enterprise agents
and which report templates contain these metrics. This section also describes how the system
gathers agent metrics and explains how to configure and script your system so that your reports
contain appropriate data.
This chapter contains the following topics:
•
•
•
•
•
•
•
Useful Agent Statistics and Report Templates, page 45
Monitoring Agent States, page 50
Configuration and Scripting Considerations for Reporting on Agent States, page 57
Reporting on Agent Task Handling, page 58
Configuration and Scripting Considerations for Task Reporting, page 64
Reporting on Agent Call Transfers and Conferences, page 66
Configuration and Scripting Considerations for Transfer and Conference Reporting, page
71
• Reporting on Supervisor Action, page 72
• Configuration and Scripting Considerations for Reporting on Supervisor Action, page 74
Useful Agent Statistics and Report Templates
WebView reports enable you to monitor real-time agent activity and review historical agent
performance trends.
These factors determine the reports that you use to manage agents:
• Whether you need to view current activity or past performance data
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
45
Chapter 3: Managing Agents
Useful Agent Statistics and Report Templates
• Whether you want to view individual agent records or compare an agent to other members
of a skill group, peripheral, or team
• Whether you want to monitor agent state and login status or review how agents are handling
the tasks to which they are assigned.
How Do You Want to Report on Agent Performance?
The reporting templates that you use to monitor agent activity and task performance depend on
several factors, including your role in the contact center and the type of data that you want to
see.
First, determine whether you want to view real-time agent activity or past performance trends.
For real-time activity, such as agent state, duration in state, login time and current task
information, use the real-time templates. Real-time templates are designated by the words
"real-time" in their titles. For past performance trends, such as the number of tasks an agent has
handled, how the agent handled the tasks and whether tasks redirected from the agent's phone,
use the historical templates. Historical templates are designated by the words "Half Hour",
"Summary" or "Daily" in their titles.
Once you have determined whether you want to view real-time or historical templates, you
decide how you want to measure the agent's performance: by individual agent, peripheral, team,
or skill group. The following table describes the WebView options for measuring agent
performance. These options are available from the Agent category in WebView
Table 12: Report Categories for Managing Agents
Reporting Needs
Report Category
Who Use this Category
You want to view current activity for an
Agent > By Agent
individual agent or measure an individual agent's
performance trends.
This category is useful to Contact Center
Administrators with global responsibility for all
of the agent in the contact center, regardless of
the skill group, peripheral, or team.
You want to view current activity for agents on Agent > By
a common peripheral or measure/compare
Peripheral
agents' performance trends for a common
peripheral.
This category is useful to Contact Center
Administrators who are responsible for a certain
site within the enterprise. In an IPCC Enterprise
environment, each site is designated by one or
more peripherals.
You want to view current activity for agents in Agent > By Team
a team or measure/compare agents' performance
trends for a team.
This category is useful for Contact Center
Supervisors who manage teams of agents.
You want to view current activity for agents in Agent > By Skill
a skill group or measure/compare agents'
Group
performance trends for a skill group. You want
to view data for queue management.
This category is useful for Contact Center
Supervisors or team leads who are responsible for
certain skill groups.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
46
Chapter 3: Managing Agents
Useful Agent Statistics and Report Templates
Note: The Agent > By Skill Group templates report only on skill groups that reside on a single
peripheral. If you need to report on Enterprise skill groups (skill groups that span several sites,
several peripherals at one site, or several Media Routing Domains (MRDs)) you use the Enterprise
Skill Group report templates.
Each Agent report category provides the same types of data, organized according to the manner
in which you have chosen to view the data. For example, the Agent > By Agent templates
contain generally the same fields as the Agent > By Skill Group, but the Agent > By Agent
templates organize the data by individual agents while the Agent > By Skill Group templates
organize the data first by skill group and then by agent.
What Data Do You Want to See?
The reports you use depend on whether you are monitoring agent real-time status or historical
performance.
Real-time agent data helps you identify immediate issues, such as agents who are talking too
long on a call, putting callers on hold for too long, spending too much time in certain states
such as Not Ready and logging out when they be handling tasks.
If you are monitoring agents in real-time, you might be interested in these types of statistics:
• Agent's current state and applicable reason codes
• The amount of time the agent has spent in that state
• Agent availability for handling tasks within the Media Routing Domain (MRD)
• The amount of time that the agent has been logged into the system
• Details for the current task on which the agent is working, including whether the agent has
requested supervisor assistance for the task
• Number of calls queued to an agent's skill group that can be answered by the agent
• Which agents are currently logged out
The following table describes suggested IPCC Enterprise report templates that provide agent
real-time statistics. For details of all IPCC Enterprise report templates, refer to the WebView
Template Reference Guide for Cisco IPCC Enterprise & Hosted Editions.
Table 13: Report Templates for Real-time Monitoring
Template
Statistics Provided
agent20: Agent Real Time
Reports on current skill group, agent state, login time, task direction, applicable
reason codes, supervisor assistance requests and MRD availability
agtper20: Agent Peripheral Real
Time
Reports on current skill group, agent state, login time, task direction, applicable
reason codes, supervisor assistance requests and MRD availability for agents on a
specific peripheral.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
47
Chapter 3: Managing Agents
Useful Agent Statistics and Report Templates
Template
Statistics Provided
agtskg30: IPCC Agent Skill Group Reports on current skill group, agent state, login time, task direction, applicable
Real Time
reason codes, supervisor assistance requests, and MRD availability for agents in
specific skill groups. This report also provides the number of calls queued to an
agent's skill group that can be answered by the agent.
If you are reporting on agents who handle multi-session chat tasks, note that these
agents can work on more than one task at a time; you gather agent state information
from both the Available in MRD and Agent State columns.
agteam20: Agent Team Real Time Reports on current skill group, agent state, login time, task direction, applicable
reason codes and MRD availability for agents in specific skill groups.
If you are reporting on agents who handle multi-session chat tasks, note that these
agents can work on more than one task at a time; you gather agent state information
from both the Available in MRD and Agent State columns.
agteam32: Agent Team State
Counts Real Time
Reports on the number of agents in different agent states, including logged in, active
in/out/other, held, not active, wrap up, not ready, reserved, and eligible for task.
perskg39: Peripheral Skill Group Reports on agents who are currently logged out from specific peripheral skill groups.
Logout Real Time
Historical agent data helps you identify how agents compare to their peers, whether agent
performance is improving and whether additional training is required.
If you are measuring agents' past performance or performance trends, you might be interested
in these types of statistics:
• How many inbound tasks the agent handled
• How many outgoing calls the agent placed
• Average Handle Time (AHT) for the agent
• Average Hold Time for the agent
• How many transfers and consultations the agent performed
• How many transfers the agent received
• How many tasks abandoned while ringing on the agent's phone
• How many tasks abandoned while on hold
• How many tasks were redirected off the agent's phone
• How much time the agent is spending in Not Ready state
• Whether the agent is logging in and out at the appropriate times
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
48
Chapter 3: Managing Agents
Useful Agent Statistics and Report Templates
• How many times the agent has requested supervisor assistance
• How many times a supervisor has had to barge in or intercept a call
The following table describes suggested IPCC Enterprise report templates that provide agent
historical statistics. For details of all IPCC Enterprise report templates, refer to the WebView
Template Reference Guide for Cisco IPCC Enterprise & Hosted Editions.
Table 14: Report Templates for Historical Reporting
Template
Statistics Provided
agent21: Peripheral Agent Task Summary Reports on agent task activity for half-hour intervals, including the number
Half Hour
of tasks handled, transferred in and out, conference in and out, redirected
on no answer, abandoned while ringing and on hold and supervisor assistance
and intervention.
agtper21: Agent Peripheral Task Summary Reports on agent task activity for half-hour intervals, including the number
Half Hour
of tasks handled, transferred in and out, conference in and out, redirected
on no answer, abandoned while ringing and on hold and supervisor assistance
and intervention.
agtskg21: Agent Skill Group Summary Half Reports on agent task activity for half-hour intervals, including the number
Hour
of tasks handled, transferred in and out, conferenced in and out and on hold.
agent30: Agent Not Ready Summary
Reports on Not Ready reason codes, duration the agent used that reason
code, what percentage of logon time the agent spent in Not Ready and what
percentage of Not Ready time the agent used a particular reason code.
agent03: Agent Media Status Logout
Reports on agent login duration and logout date and time.
agtper03: Agent Peripheral Media Status
Logout
Reports on agent login duration and logout date and time for a specific
peripheral.
agtskg03: Agent Skill Group Media Status Reports on agent login duration and logout date and time for a specific skill
Logout
group.
agteam03: Agent Team Media Status
Logout
Reports on agent login duration and logout date and time for a specific team.
See Also
WebView Template Reference Guide for Cisco IPCC Enterprise & Hosted Editions
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
49
Chapter 3: Managing Agents
Monitoring Agent States
Monitoring Agent States
You can monitor agent states in real-time to view current agent activity, or review past
performance data to identify trends in agent states. For example, using historical reports you
can see how much time an agent spends in Not Ready state, which indicates whether the agent
is adhering to the schedule. This section describes the meaning of agent states in an IPCC
Enterprise environment.
Agent States
Agent states are determined based on an agent’s activity within a skill group. Agent state is
recorded in the Agent_Real_Time and Skill_Group_Real_Time database tables.
Certain reports indicate how many agents are in different states. In these reports, the Hold
column is used to report on agents in Hold and Paused states, and the Active column is used to
report on agents in the Active and Talking states.
The following table describes agents states that appear in reports. Note that information for
some states is different for the Multi-session Chat MRD. This table highlights these differences.
Table 15: Agent States
State in Skill
Group
Description for all Cisco Voice
Description for all MRDs except for Cisco Voice
Active/Talking The agent is working on a task or a call in this skill The agent is working on one or more chat requests
group.
associated with this skill group. For these agents,
the state is reported as Active.
For agents who handle non-voice tasks, this state
is reported as Active.
For agents who handle voice-tasks, this state is
reported as Talking.
Work Ready
The agent is performing wrap up work for a call The agent is performing wrap up work for a task
or task in this skill group.
associated with this skill group. The agent is not in
the Active state with respect to a task associated with
If the agent is handling a voice call, the agent
this skill group.
enters Not Active state when wrap up is complete.
If the agent is handling a non-voice task, the agent
might enter Not Active or Not Ready state when
wrap up is complete.
Paused/Hold
The agent is paused with respect to a call or task The agent is not in Active or Work Ready state with
associated with this skill group.
respect to a task associated with this skill group. The
agent is Paused with respect to a task associated
with this skill group.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
50
Chapter 3: Managing Agents
Monitoring Agent States
State in Skill
Group
Description for all Cisco Voice
Description for all MRDs except for Cisco Voice
For agents who handle non-voice tasks, the state
is reported as Paused. Note that only multi-session
chat tasks can be Paused; single-session chat,
blended collaboration, and e-mail tasks cannot be
paused by the agent.
For agents who handle voice tasks, the state is
reported as Hold.
For agents handling Outbound Option calls, the
Hold state indicates that the agent has been
reserved for a call because the Outbound Dialer
puts on the agent on hold while connecting the
call.
Reserved
The agent has been offered a call or task associated The agent is not in Active, Work Ready, or Paused
with the skill group.
state in this skill group. The agent has been offered
one or more tasks associated with this skill group.
Agents handling Outbound Option calls are never
placed in Reserved state; the Outbound Option
Dialer puts the agent on hold when reserving
him/her for a call.
Busy Other
The Agent is Active, Work Ready, Reserved, or The agent is not in Active, Work Ready, Reserved,
on Hold/Paused in another skill group in the same or Paused state with respect to a task associated with
MRD.
this skill group. The agent is in Active, Work Ready,
Reserved, or Paused in another skill group in the
same MRD.
Not Active
The agent is not working on any task or call
associated with this skill group.
Work Not
Ready
The agent is performing wrap up work for a call A basic non voice MRD agent state, which is used
in this skill group. The agent enters Not Ready to indicate that IPCC/ICM has lost connection with
state when wrap up is complete.
the application instance that supports MRD. That is,
when IPCC/ICM loses connection with the
application instance supporting MRD X, agent A's
state is set to WORK_NOT_READY.
The agent is not working on any task or call
associated with this skill group.
Note: The MRD agent state allows IPCC/ICM
software to capture the duration of a lost contact.
The cause for losing the contact can be:
• Failure in the network connection between the
application instance and IPCC/ICM.
• Failure of application instances.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
51
Chapter 3: Managing Agents
Monitoring Agent States
State in Skill
Group
Description for all Cisco Voice
Description for all MRDs except for Cisco Voice
• The CTI server associated with the Agent PG is
not active or inaccessible.
The WORK_NOT_READY state does not change.
That is, the agent is performing wrap-up work after
the call. The agent enters Not_Ready state when
wrap-up is complete.
Not Ready
The agent is not available to be assigned a task. If
an agent is Not Ready in one skill group, the agent
is Not Ready in all skill groups within the same
Media Routing Domain.
The agent is not available to be assigned a task. If
an agent is Not Ready in one skill group, the agent
is Not Ready in all skill groups within the same
Media Routing Domain.
Agent States and Skill Groups
Agents can belong to multiple skill groups in a Media Routing Domain. When an agent is
handling a task that was routed to a skill group, the agent is Active in that skill group.
For ICM/IPCC routed calls or transferred ICM-routed calls that use the dialed number, the
active skill group is the skill group to which the task was queued.
For direct incoming calls or transferred ICM/IPCC routed calls that do not use the dialed number,
the active skill group is the default or first skill group defined for the agent.
For new outgoing calls (AgentOutCalls or InternalCalls) or transferred outbound calls, the active
skill group is either the default skill group or the first skill group defined for the agent.
The agent's state in the active skill group dictates his or her state in other skill groups in the
Media Routing Domain to which the agent belongs, as follows:
• If the agent is Active, Work Ready, Reserved, or Hold/Paused in one skill group in the MRD,
the agent state is Busy Other for all other skill groups in the MRD.
• If the agent is Not Ready in one skill group in the MRD, the agent is Not Ready in all skill
groups in the MRD.
Agent State Hierarchy for Multi-session Chat Media Routing Domain
Agent state on a task determines the agent state in a skill group, and agent state in a skill group
determines agent state in the MRD. For example, if an agent is Active on a call for SkillGroup
A, then the agent state is Active in SkillGroup A and the agent state is Active for the MRD to
which SkillGroup A belongs.
However, agents handling multi-session chat tasks can work on more than one task in the same
skill group and more than one skill group can belong to a MRD. In this case, a state hierarchy
is used to determine how the agent's state in the skill group and in the MRD is reported.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
52
Chapter 3: Managing Agents
Monitoring Agent States
The agent state hierarchy is:
1. Active
2. Work Ready
3. Paused
4. Reserved
5. Busy Other (for different skill groups in the same MRD)
6. Not Active
Consider the following diagram:
Figure 5: Agent State Hierarchy in Skill Group and MRD
In the above diagram, an agent belongs to two skill groups in the Multi-session Chat MRD and
is configured to work on up to six simultaneous multi-session chat tasks in each MRD. In the
first skill group, the agent is working on three tasks, and the agent's states for those tasks are
Work Ready, Reserved, and Paused. Work Ready is the state reported for the agent at the skill
group level, because Work Ready is higher than Reserved and Paused in the state hierarchy. In
the second skill group, the agent is working on two tasks, and the agent's states for those tasks
are Active and Reserved. Active is the state reported for the agent at the skill group level, because
Active is higher than Reserved in the state hierarchy. For the Multi-session Chat MRD, the
agent's state is Active because Active is higher than Work Ready in the hierarchy.
Agent State and Task State Relationship
Agent state times are reported on half hour boundaries regardless of whether the call or task is
finished or not. Call and task state times are reported only when the task ends. The call/task
ends when wrap up is complete.
The following figure illustrates the correlation between agent state and call state for a Voice
call. The agent reserve time includes the time it took the call to arrive at the agent’s phone or
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
53
Chapter 3: Managing Agents
Monitoring Agent States
desktop (network time) as well as the amount of time that the call rang on the agent’s phone or
waited on the agent’s desktop (offer/ring time).
Figure 6: Agent State and Task State Relationship
If the half hour boundary ends when the call is ringing on the agent’s phone, the reserved time
for the agent includes the network time and part of the ring time. At the next half hour interval,
the remaining ring time is reported in the reserved time of the agent. However, the call’s time
does not appear on a report until wrap up has been completed on the call.
Agent Not Ready Reason Codes
WebView Agent Not Ready Reason Code reports enable you to report on the Not Ready
reason codes that agents select when entering Not Ready state. These reports help you identify
whether agents are taking the appropriate number of breaks and whether their breaks are the
appropriate length.
You configure these Not Ready reason codes in the ICM/IPCC configuration tool and in the
agent desktop software. The ICM/IPCC configuration tool enables you to specify alphanumeric
reason codes and their numeric equivalent. For example, you might configure Break and Lunch
reason codes with corresponding numeric values of 1 and 2, respectively. You also configure
these reason codes in the agent desktop software so that the agent can select a reason code when
entering the Not Ready state. The Not Ready reason codes configured on ICM/IPCC software
are system-level codes, while the Not Ready reason codes configured on the agent desktop
software are peripheral-specific. You configure reason codes to have the same meaning in both
applications.
The WebView Agent Not Ready Reason Code reports (agent30 and 31) provide the
alphanumeric name of the reason code and the corresponding number in the agent Not Ready
detail and Not Ready summary reports. For example, if an agent enters Not Ready state and
selects "Break" as the reason code, the report displays "Break [1]". The reason code text that
displays is the code configured in ICM/IPCC configuration tool. Not Ready reason codes that
do not have an alphanumeric reason code defined in the ICM/IPCC configuration tool appear
as numbers in the reports. For example, if you configure reason code "3" and do not specify a
text reason code, such as Training, only "3" appears in the reports.
Note: In all other reports with the Reason Code field, the report displays the numeric Not Ready
reason code.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
54
Chapter 3: Managing Agents
Monitoring Agent States
In addition to Not Ready reason codes that you have defined, the IPCC Enterprise system uses
predefined Not Ready reason codes for situations in which the agent is made Not Ready
automatically by the software. The following table describes these predefined Not Ready reason
codes.
Table 16: Predefined Not Ready Reason Codes
Predefined Not Ready Reason Code Description
50002
A CTI OS component failed, causing the agent to be logged out. This could
be due to closing the agent desktop application, heartbeat time out, a CTI OS
Server failure, or a CTI OS failure.
50010
The agent did not receive multiple consecutive calls routed to him/her. The
system makes the agent Not Ready automatically so that additional calls are
not routed to the agent. By default, the number of consecutive calls missed
before the agent is made Not Ready is 2.
50041
The agent's state was changed to Not Ready because the call fails when the
agent's phone line rings busy.
32767
The agent's state was changed to Not Ready because the agent did not answer
a call and the call was redirected to a different agent or skill group.
20001 - applicable if you are using the The agent's state was changed to Not Ready and the agent was forcibly logged
Cisco Agent Desktop
out.
20002 - applicable if you are using the This is the normal logout reason code condition from Not Ready.
Cisco Agent Desktop
20003 - applicable if you are using the If the agent is not in Not Ready state, a request is made to place the agent in
Cisco Agent Desktop
Not Ready state and then a logout request is made to log the agent out.
Supervisor Not Ready
This code is reserved.
Predefined Not Ready reason codes do not have associated textual reason codes by default and
appear as numbers in reports. If you want to see a textual code for these Not Ready reason codes,
enter the predefined Not Ready reason code into the Reason Code List tool with the related text.
For example, you might want to label the 32767 Not Ready reason code "Redirection on No
Answer" .
Not Ready reason code reports gather data and calculate percentage of time in Not Ready state
and in specific Not Ready reasons based on the time range you specify for the report. If an
agent's total login session is not included in the specified time range (for example, the agent
was still logged in at the end of the time range), an asterisk (*) appears next to the agent's name
in the report to indicate that data for that agent is not complete for the range.
Note: If you want to report on Not Ready reason codes, ensure that the reporting of agent event
detail data is enabled on the PG with the Cisco CallManager peripheral. This is enabled by
default.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
55
Chapter 3: Managing Agents
Monitoring Agent States
Agent Logout Reason Codes
You define agent Logout Reason codes in the agent desktop software. These reason codes appear
in historical logout reports. In WebView logout reports, the reason codes are reported as their
numeric equivalent. For example, if reason code 1 equals "end of shift" and the agent selects
"end of shift" as the reason for logging out, the WebView report displays "1".
The IPCC Enterprise system uses several predefined Logout Reason codes for situations in
which the agent is logged out automatically by the software. The following table describes these
predefined Logout Reason codes.
Table 17: Predefined Logout Reason Codes
Predefined Logout Reason Code
Description
-1
The agent reinitialized due to peripheral restart.
-2
The PG reset the agent, normally due to a PG failure.
-3
An administrator modified the agent's extension while the agent was logged in.
50002
A CTI OS component failed, causing the agent to be logged out. This could be
due to closing the agent desktop application, heartbeat time out, a CTI OS Server
failure, or a CTI OS failure.
50003
The agent was logged out because the Cisco CallManager reported the agent's
device as out of service.
50004
The agent was logged out due to agent inactivity as configured in agent desk
settings.
50020
The agent was logged out when his or her skill group assignment dynamically
changed on the AW.
50030
The agent was logged out because the agent was logged into dynamic device
target that was using the same dialed number (DN) as the PG static device target.
50040
The mobile agent was logged out because the call failed.
50042
The mobile agent was logged out because the phone line disconnected when using
nailed connection mode.
20003- applicable if you are using the Forces the logout request.
Cisco Agent Desktop
Supervisor Logout- applicable if you This code is reserved.
are using the Cisco Agent Desktop
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
56
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Reporting on Agent States
Configuration and Scripting Considerations for Reporting on Agent States
Configuration and Scripting Considerations for Agent Reporting
Follow these guidelines when configuring agent reporting:
• If you want to use the agent state trace report, enable the agent state trace option for each
agent whose information you want to view using the ICM/IPCC configuration tool.
Enabling agent state trace for many agents might impact system performance as the option
causes more records to be written to the database. If you notice a performance problem, you
might want to disable agent state trace, or only enable agent state trace for those agents on
whom you are reporting.
• To obtain agent data in reports:
– For IPCC Enterprise deployments other than System IPCC, ensure that agent reporting is
enabled on the Cisco CallManager peripheral and identify the Admin Workstation
distributor in the Agent Distribution list in ICM/IPCC software. It is not enabled by default.
– For System IPCC deployments, agent reporting is enabled by default, and cannot be
disabled.
Reporting when using the Queue to Agent Node in Script Editor.
The Queue to Agent Node in Script Editor allows you to route a call to one or more specified
agents; for example, to a primary supervisor. The agents can be specified directly from the list
of configured agents or indirectly by providing agent’s SkillTargetID or Enterprise Name.
When you use the Queue to Agent Node, certain reporting statistics are tracked for agents in
the Agent _Half_Hour table in the database schema.
Fields are tracked for calls that are offered, abandoned, abandoned in queue, dequeued, redirected,
answered, handled, and resulted in an error condition.
See Script Editor online help for more on the Queue to Agent node.
See Schema online help for more on the Agent_Half_Hour table.
See the IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition for
instructions on enabling agent reporting.
Configuration and Scripting Considerations for Not Ready Reason Code Reporting
Follow these guidelines when configuring Not Ready reason codes:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
57
Chapter 3: Managing Agents
Reporting on Agent Task Handling
• Configure the Not Ready reason codes in the ICM/IPCC configuration tool. Enter the numeric
and text value for each reason code. For example, if you want Not Ready reason code 1 to
equal Break, enter 1 for the Reason Code and Break for Reason Code Text.
• Configure the codes in the agent desktop software so that the agents can use them.
• Ensure that agent event detail is enabled on the PG with the Cisco CallManager peripheral
so that Not Ready reason codes are reported. It is enabled by default, and for System IPCC
Enterprise deployments cannot be disabled.
See the IPCC Administration Guide for Cisco IPCC Enterprise Edition for instructions on
configuring Not Ready codes.
Configuration and Scripting Considerations for Logout Reason Code Reporting
If you want to report on Logout Reason codes, configure the codes in the agent desktop software.
Also, configure the Logout non- activity time in the Agent Desk Settings tool.
See the IPCC Administration Guide for Cisco IPCC Enterprise Edition for instructions on
configuring Logout Reason codes.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
Cisco IPCC Enterprise Edition System IPCC Installation and Configuration Guide
IPCC Administration Guide for Cisco IPCC Enterprise Edition
Reporting on Agent Task Handling
Reports show you what kind of tasks agents are handling and how well they are handling them.
For example, reports display statistics for calls placed, received, transferred and conferenced.
Reports also indicate how many calls were rerouted from an agent when the agent failed to
answer the call.
Types of Tasks
Agents can receive and place many different types of tasks. You can report all of these tasks
using WebView.
Tasks can be either internal or external. Internal tasks are calls made to an agent from another
person on the same Cisco CallManager cluster. Internal tasks are also calls that encounter busy
or an overflow conditions in a script. For example, calls whose Call Type is requalified in a
script "overflow" from the first call type into second call type. Overflow might occur in VRU
application scripts, where Call Type requalify is used to separate information gathering from
queuing, or, if CVP is the VRU, in Redirection on No Answer situations in which the Router
requalifies the call type to assign the call to a different agent.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
58
Chapter 3: Managing Agents
Reporting on Agent Task Handling
External tasks are tasks that go through a voice gateway or Media Routing PG or tasks that are
routed to an agent from a person on a different Cisco CallManager cluster. For example, calls
from the call center to customers go through voice gateways and are considered external. Only
Voice calls can be external or internal; single-session chat, multi-session chat, e-mail, and
blended collaboration task are always external.
In addition to being internal or external, tasks can be incoming or outgoing. An incoming task
is a task that an agent receives. An outgoing task is a call that an agent places. For example, if
a customer calls an agent, the call is incoming for the agent. If an agent calls a supervisor, the
call is outgoing for the agent. Voice calls can be either incoming and outgoing; single-session
chat, multi-session chat, e-mail, and blended collaboration task are always incoming.
For Voice calls only, agents can also transfer calls, receive transferred calls, place consultative
calls, and engage in conference calls.
The following table describes the tasks that an agent can receive and place and how they are
reported.
Table 18: Types of Calls
Type of call
Description
Reported As
Incoming
direct/internal calls
Calls that are not routed by an ICM/IPCC routing script. Incoming Direct Internal In
Tasks are tasks that come directly to the agent’s extension. These calls
can be either internal (agent or device on same CallManager cluster or
within the VoIP network to another CallManager cluster) or external
(through a voice gateway).
Examples of this kind of call include: calls that are directly transferred
by another agent without going through a script and calls that resulted
from agent-to-agent calling.
Data for these calls are stored in the InternalCallsRcvd fields of the
Agent_Skill_Group_Half_Hour historical database table.
Outgoing external
calls
Calls initiated by agents from their extension that pass through a voice External Out Tasks
gateway. Outgoing External Tasks are always voice tasks.
Consult, conference out, and transfer out calls are counted as outgoing
external calls if they are outside the voice gateway, which could include
a Network IVR or on-premise IVR that is connected using voice gateway
or remote agent extensions at another Cisco CallManager site.
Agent-to-Agent dialing is outgoing external if the agent initiating the
call if the call must traverse a voice gateway to get to the destination
agent.
Data for these calls are stored in the AgentOutCalls fields of the
Agent_Skill_Group_Half_Hour historical database table.
Outgoing internal calls Calls initiated by agents from their extension to another extension within Internal Out Tasks
the Cisco CallManager cluster or to another Cisco CallManager cluster
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
59
Chapter 3: Managing Agents
Reporting on Agent Task Handling
Type of call
Description
Reported As
within the VoIP network. Outgoing Internal Tasks are always voice
tasks.
Consult, conference out and transfer out calls are counted as outgoing
internal calls if they are placed to another device that is on the same
CallManager cluster. The device could be any of the following: another
agent line, any other extensions to the VRU and any IP phone or CTI
route point.
Agent-to-Agent calls are outgoing internal for the agent initiating the
call if the destination agent is on the same Cisco CallManager cluster
as the source agent.
Data for these calls are stored in the InternalCalls fields of the
Agent_Skill_Group_Half_Hour historical database table.
ICM-routed/incoming All calls that are routed to the agent by an ICM/IPCC routing script.
calls
Outbound Option calls are considered ICM-routed/incoming calls.
Data for these calls are stored in the CallsHandled fields of the
Agent_Skill_Group_Half_Hour historical database table.
Transferred in calls
Note that Tasks
Handled includes all
ICM/IPCC routed calls,
including calls that are
transferred and
conferenced, and
consultative calls.
Tasks Handled
provides a high level
view of all ICM/IPCC
routed tasks. Other
report columns such as
Transfer In and Conf
Out provide more
details about how the
task was handled.
Calls that are transferred to an agent. Both incoming and outgoing calls Transfer In
can be transferred to an agent.
Note: For blind transfers in IPCC Enterprise with an IPCC System PG,
this field is updated when the call that was blind transferred to an IVR
is subsequently transferred to another agent and the agent answers the
call. For this call scenario, this field is not updated in IPCC Enterprise
without an IPCC System PG which supports only IP-IVR. This field is
updated when an IPCC System PG which supports CVP is used in IPCC
Enterprise.
Data for these calls are stored in the TransferredIn fields of the
Agent_Skill_Group_Half_Hour historical database table.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
60
Tasks Handled
Chapter 3: Managing Agents
Reporting on Agent Task Handling
Type of call
Description
Reported As
Transferred out calls
Calls that are transferred from an agent. An agent can transfer both
incoming and outgoing calls.
Transfer Out
Data for these calls are stored in the TransferredOut fields of the
Agent_Skill_Group_Half_Hour historical database table.
Consultative calls
Calls in which an agent consulted with another agent or supervisor while Cons Out
having another call on hold.
Data for these calls are stored in the ConsultativeCalls fields of the
Agent_Skill_Group_Half_Hour historical database table.
Conference in calls
Incoming calls that are conferenced.
Conf In
Note: For blind conferences in IPCC Enterprise with an IPCC System
PG, this field is updated when the call that was blind conferenced to an
IVR is subsequently answered by another agent. For this call scenario,
this field is not updated in IPCC Enterprise without an IPCC System
PG which supports only IP-IVR. This field is updated when an IPCC
System PG which supports CVP is used in IPCC Enterprise.
Data for these calls are stored in the ConferencedInCalls fields of the
Agent_Skill_Group_Half_Hour historical database table.
Conference out calls
Outgoing calls that are conferenced.
Conf Out
Data for these calls are stored in the ConferencedOutCalls fields of the
Agent_Skill_Group_Half_Hour historical database table.
Task Times
For each type of task that an agent can place, the amount of time that the agent spent working
on that task is recorded in the Agent_Skill_Group_Half_Hour database table, as follows:
• ICM routed tasks - The time for these tasks begins when the agent answers the task and ends
when the agent completes wrap up. The time is stored in the HandledCallsTimeToHalf field.
• Incoming direct tasks - The time for these tasks begins when the agent answers the task and
ends when the task disconnects. The time is stored in the InternalCallsRcvdTimeToHalf field.
• External outgoing tasks - The time for these tasks begins when the agent initiates the task
and ends when the task disconnects. The time is stored in the AgentOutCallsTimeToHalf
field.
• Outgoing internal tasks- The time for these tasks begins when the agent initiates the task and
ends when the task disconnects. The time is stored in the InternalCallsTimeToHalf field.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
61
Chapter 3: Managing Agents
Reporting on Agent Task Handling
• Transferred in tasks - The time for these tasks begins when the agent answers the transferred
task and ends when the task disconnects. The time is stored in the
TransferredInCallsTimeToHalf field.
Note: For blind transfers in IPCC Enterprise with an IPCC System PG, the
TransferredInCallsTimeToHalf field is updated when the call that was blind transferred to
an IVR is subsequently transferred to another agent and the agent answers the call. For this
call scenario, this field is not updated in IPCC Enterprise without an IPCC System PG which
supports only IP-IVR. This field is updated when an IPCC System PG which supports CVP
is used in IPCC Enterprise.
• Transferred out tasks - The time for these tasks begins when the agent activates the transfer
button and ends when the transfer is complete. The time is stored in the
InternalCallsTimeToHalf field.
• Consultative tasks - The time for these tasks begins when the agent activates the transfer
button and ends when the target agent answers and the held task is restored (drop consultative
call) or consult party drops. The time is stored in the ConsultativeCallsTimeToHalf field.
• Conferenced in tasks - The time for these tasks begins when the agent answers the task and
ends when the task disconnects. The time is stored in the ConferenceInCallsTimeToHalf
field.
Note: For blind conferences in IPCC Enterprise with an IPCC System PG, this field is updated
when the call that was blind conferenced to an IVR is subsequently answered by another
agent. For this call scenario, this field is not updated in IPCC Enterprise without an IPCC
System PG which supports only IP-IVR. This field is updated when an IPCC System PG
which supports CVP is used in IPCC Enterprise.
• Conferenced out tasks - The time for these tasks begins when the agent activates the conference
button and ends when the agent disconnects from the conference call and the supervisor drops
out of the call. The time is stored in the ConferenceOutCallsTimeToHalf field.
You might notice overlapping data in your reports for the amount of time for different types of
calls. This happens because incoming tasks, such as ICM/IPCC routed tasks and calls directly
to an agent, can be Transferred In and Conferenced In. Both incoming calls and outgoing calls
placed by agents can be Transferred Out and Conferenced Out. The total time for the incoming
or outgoing call includes transfer and conference time.
Note: Agents can transfer and conference incoming calls both in and out. However, they can
transfer and conference outgoing calls out only. This means that if an agent transfers an outgoing
task to another agent, it is still considered an outgoing task.
Outbound Option Dialing Campaign Calls
Outbound Option provides automatic outbound dialing capability. The Outbound Option Dialer
places outbound calls to customers and connects these calls with agents.
The Dialer assigns and connects calls differently than regular IPCC Enterprise routing. Report
data for agents handling Outbound Option calls therefore differs from data for agents handling
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
62
Chapter 3: Managing Agents
Reporting on Agent Task Handling
typical voice calls and multichannel tasks. In order to interpret agent data for Outbound Option
tasks, you understand how Outbound Option reserves agents, reports calls that are connected
to agents and handles calls dropped by customers before the calls are connected.
When the Outbound Dialer initiates a call to a customer, it reserves the agent assigned to handle
the call by placing a reservation call to the agent and changing the agent's state to Hold. This
reservation call is reported as a Direct In call to the agent.
For typical voice calls, the agent is placed into Reserved state when ICM/IPCC software reserves
the agent to handle a call; the agent's state is reported as Reserved. For Outbound Option calls,
reports show the agent in Hold state when reserved for a call and the time that agent spends
reserved is reported as Hold Time. However, for the Outbound Option reports perskg11,
perskg12, agtsk06, agtsk10, agtsk11, agtsk12, call reports show the agent in Reserved state
when reserved for a call.
When the customer answers the call, the Outbound Option Dialer transfers the call to an agent.
The call is now reported as a Transfer In call to the agent. When the customer call is transferred
to the agent, the reservation call is dropped by the Dialer and classified as Abandon on Hold.
For more information regarding Outbound Option termination call detail records, see the Cisco
ICM/IP Contact Center Enterprise Edition Outbound Option User Guide.
The abandoned call wait time, set in the Campaign Configuration screen, determines how calls
are reported if the caller hangs up. Calls are counted in the Customer Abandon field in the
WebView campaign query templates (camqry01 and camqry02) only if the customer hangs
up before the abandoned call wait time is reached.
Redirection on No Answer Calls with IP IVR
The Redirection on No Answer feature, configured in Agent Desk Settings in ICM/IPCC
configuration tool, ensures that when an agent does not answer a call, the call is re-assigned to
another agent or requeued after a specified number of seconds. Redirection on No Answer is
also used to change the agent state to Not Ready when a call is rerouted from the agent's phone.
When the Ring No Answer time expires, ICM/IPCC software makes the agent unavailable for
routing requests. When the call is actually rerouted, ICM/IPCC software makes the agent Not
Ready, with a reason code of 32767.
A count of the calls that experience Redirection on No Answer appears in agent and skill group
reports. A high number of redirection on ring no answer calls for an agent might indicate that
the agent is not responding quickly enough to incoming calls or, if multiple agents have a high
number of reroute on ring no answer calls, might indicate that the Ring No Answer time is too
low.
For agent reporting, you can see how many calls experienced Redirection on Ring No Answer
through the Redirect No Answer report field in agent and skill group reports.
Redirection on No Answer calls also affect call type reporting. The Calls RONA field is updated
for the Call Type when a call redirects on no answer. In call type reports, these calls are grouped
into the "Other" category. See Call Type Reporting (page 80) for more information.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
63
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Task Reporting
Redirection on No Answer calls update Peripheral tables (Peripheral_Real_Time and
Peripheral_Half_Hour) differently in IPCC Enterprise with IPCC System PG deployments and
System IPCC deployments than in other IPCC Enterprise environments.
Consider this example. An incoming ACD call is sent to an agent, but the agent does not answer
it. The call RONAs to an IVR (queued to a skill group), and is answered later by another agent.
In an IPCC Enterprise deployment that does not use the IPCC System PG (with or without CVP
support) , the CallsOffered fields (CallsOfferedHalf and CallsOfferedToday in
Peripheral_Real_Time and CallsOfferedToHalf in Peripheral_Half_Hour) are updated three
times in this scenario:
• When the call first arrives, the Peripheral CallsOffered metrics for the CallManager peripheral
are incremented.
• When the call is first sent to the IVR, the metrics for the IVR peripheral are incremented.
• When the call is sent to the IVR, the metrics for the IVR peripheral are incremented.
In IPCC Enterprise with the IPCC System PG and System IPCC deployments, this metric is
updated only when the call first arrives.
Redirection on No Answer Calls with CVP
The Redirection on No Answer feature, configured in Agent Desk Settings in ICM/IPCC
configuration tool and in CVP, ensures that when an agent does not answer a call, the call is
taken away from the agent after a specified number of seconds and re-assigned to another agent
or requeued. Redirection on No Answer is also used to change the agent state to Not Ready
when a call is rerouted from the agent's phone. When the Ring No Answer time in the Agent
Desk Settings expires, ICM/IPCC software makes the agent unavailable for routing requests.
When the CVP Ring No Answer timeout expires, the call is requeried for routing to a different
skill group or agent. ICM/IPCC software makes the agent Not Ready, with a reason code of
32767, when the call is redirected to the new skill group or agent.
Redirection on No Answer calls might also affect call type reporting. See Call Type Reporting
(page 80) for more information.
Configuration and Scripting Considerations for Task Reporting
Configuration and Scripting Considerations for Transfers and Conferences
See Configuration and Scripting Considerations for Transfer and Conference Reporting (page
71).
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
64
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Task Reporting
Configuration and Scripting Considerations for Redirection on No Answer with IP-IVR
For calls that redirect on no answer, follow these configuration guidelines to ensure that reporting
is accurate:
• Define a Ring No Answer time and Ring No Answer dialed number within the Agent Desktop
Settings in the ICM/IPCC configuration tool. Set the Call Forward on No Answer system
wide time value in Cisco CallManager greater than the Ring No Answer timer in the Agent
Desktop Setting. Remember if you have multiple agent desk setting records, that all must be
set to this value that is less than the Cisco CallManager timer.
• If you want to ensure that Redirection on No Answer calls do note adversely affect the Service
Level, you define the Service Level threshold to be less than the Ring No Answer timer at
the call type and service. Note that you do not create services in System IPCC or ARI
deployments.
Redirection on No Answer conditions be handled by two scripts: the initial routing script and
a script specifically set up for RONA conditions.
The Redirection on No Answer script include the following:
• The initial routing script might include call variables to collect the skill group to which the
call is queued as well as the initial call type. These variables are passed to the RONA script.
Optionally, you can configure the script to use these variables.
• In the RONA script, queue the call at the highest priority in the skill group(s) defined.
See the IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition or System
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition for instructions
on configuring Agent Desk Settings. See the ICM Scripting and Media Routing Guide for Cisco
ICM/IPCC Enterprise & Hosted Editions for instructions on scripting.
Configuration and Scripting Considerations for Redirection on No Answer with CVP
For calls that redirect on no answer, follow these configuration guidelines to ensure that reporting
is accurate:
• Define a Ring No Answer time within the Agent Desktop Settings in the ICM/IPCC
configuration tool. Do not configure the Ring No Answer dialed number. Set the Call Forward
on No Answer system wide time value in Cisco CallManager greater than the Ring No Answer
timer in the Agent Desktop Setting. Remember that if you have multiple agent desk setting
records, they all must be set to this value that is less than the Cisco CallManager timer.
• Configure the CVP Ring No Answer timeout. The Ring No Answer time in Agent Desk
Settings is used to make the agent Not Ready, but the actual requery of the call occurs when
the CVP Ring No Answer timeout occurs.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
65
Chapter 3: Managing Agents
Reporting on Agent Call Transfers and Conferences
The Redirection on No Answer script :
• Enable the Target Requery option in the node that is selecting and delivering the call to the
agent to instruct the CVP to requery the call to another skill group or agent.
• Queue the call at the highest priority in the skill group(s) defined within the call variables.
See the IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition for
instructions on configuring Agent Desk Settings. See the ICM Scripting and Media Routing
Guide for Cisco ICM/IPCC Enterprise & Hosted Editions for instructions on scripting.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
Reporting on Agent Call Transfers and Conferences
Voice calls can be transferred and conferenced. Non-voice tasks, such as e-mail, single-session
chat and multi-session chat, and blended collaboration tasks cannot be transferred and
conferenced.
Transfer can be either blind or consultative, and is supported only for agents within the same
Cisco CallManager cluster. A blind transfer is a transfer in which the agent transfers the call to
another agent without first ensuring that another agent is available. A consultative transfer is a
transfer in which an agent places the call on hold, calls the receiving agent to discuss the transfer
and then transfers the call to the agent. Consultative transfer is not supported when CVP is used
as the VRU.
Transfers and Conferences Using Dialed Numbers
When the agent activates the transfer or conference button and selects a number to which to
transfer or conference the call, the dialed number is sent to the ICM/IPCC Central Controller
from the agent's PG. This dialed number determines the call type, which in turn selects the
transfer routing script. The script include a Queue to Skill Group node that references the
appropriate skill group based on the dialed number to which the call be queued.
If an agent is available in the selected skill group, a message is sent from the ICM/IPCC Central
controller to the source agent's PG, containing a label or number to be dialed. The PG transfers
the call from the source agent’s phone to the target agent using the label returned from the
ICM/IPCC Central controller. For these types of transfers and conferences, TransferOut or
ConferenceOut is incremented for the source agent and TransferIn or ConferenceIn is incremented
for the target agent.
If no agents are available for a transfer in the selected skill group, the Router sends the source
agent's PG the label to use to forward the call to the VRU. For these types of transfers and
conferences, TransferOut or ConferenceOut is incremented for the source agent. However,
TransferIn or ConferenceIn is incremented for the target agent when the VRU eventually routes
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
66
Chapter 3: Managing Agents
Reporting on Agent Call Transfers and Conferences
the call to the target agent only in IPCC Enterprise with an IPCC System PG and System IPCC
deployments. This is also applicable when IPCC System PG with CVP is used in IPCC Enterprise
and System IPCC deployments.
How Database Fields Are Affected by Transfers and Conferences
Transfers and conferences affect fields in the Agent_Skill_Group_Half_Hour database table.
The TransferIn field is incremented for the target agent if all of the following conditions are
true:
• The call was transferred (blind or consultative) by an agent to a call type or script that checks
for agent availability
• For blind transfers only, an agent within the same peripheral was available at the time that
the transfer was initiated.
Note: For blind transfers in IPCC Enterprise with an IPCC System PG, this field is updated
when the call that was blind transferred to an IVR is subsequently transferred to another agent
and the agent answers the call. For this call scenario, this field is not updated in IPCC Enterprise
without an IPCC System PG which supports only IP-IVR. This field is updated when an IPCC
System PG which supports CVP is used in IPCC Enterprise.
The ConferenceIn field is incremented for the target agent receiving the conference call if all
of the following conditions are true:
• The call was conferenced by an agent to a calltype or script that checked for agent availability
• An agent within the same peripheral was available at the time that the conference was initiated
Note: For blind conferences in IPCC Enterprise with an IPCC System PG, this field is updated
when the call that was blind conferenced to an IVR is subsequently answered by another agent.
For this call scenario, this field is not updated in IPCC Enterprise without an IPCC System PG
which supports only IP-IVR. This field is updated when an IPCC System PG which supports
CVP is used in IPCC Enterprise.
The TransferOut field is incremented for the agent initiating either a blind or consultative transfer
when the initiating agent disconnects from the transfer.
The Conference Out field is incremented for the agent initiating a conference when the initiating
agent disconnects from the conference.
The ConsultativeCalls field is incremented for the initiating agent when the consultative call
disconnects and wrap up is complete. Note that consultative transfer is not supported for systems
using CVP as the VRU and therefore this field is never incremented if you are using CVP.
Note: If you are using CVP as the VRU, the transfer can be performed through a network transfer
or through the Cisco CallManager. If the network transfer is used, the TransferIn and TransferOut
fields do not display data for these transfers.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
67
Chapter 3: Managing Agents
Reporting on Agent Call Transfers and Conferences
How Types of Calls are Affected by Transfer and Conference
The following table describes the fields that are incremented in the
Agent_Skill_Group_Half_Hour database table when different types of calls are transferred and
conferenced.
Table 19: How Calls Are Affected by Transfer and Conference
Type of Call
How the call is affected
Outgoing internal
The InternalCall field is incremented for the source agent that initiates a transfer or
conference operation if the target agent is on the same CallManager cluster as the source
agent. This field is incremented after the call is disconnected.
Incoming direct/incoming
internal
The InternalCallsRcvd field is incremented for the target agent that completes a transfer
or conference if the agent dialed the target agent directly (that is, does not access an
ICM/IPCC routing script). This field is incremented after the call is disconnected.
Outgoing external
The AgentOutCalls field is incremented for the source agent who completes a transfer or
conference to an external destination. This field is incremented after the call is disconnected.
ICM Routed
The CallsHandled field is incremented for the target agent if the call is sent to the agent
using an ICM/IPCC routing script. This field is incremented against the skill group to
which the routing script queued the call. This field is incremented after the call disconnects
and wrap up is completed.
How Skill Groups are Affected by Transfer and Conference
The skill group for which transfer and conference data is reported depends on how the original
call was placed. In addition, there are some differences in how this data is reported between
IPCC Enterprise deployments that do not use the IPCC System PG (which supports both CVP
and IP-IVR) and IPCC Enterprise with the IPCC System PG/System IPCC deployments as
described in this section.
The transfer or conference is reported for the default skill group if the original call is a direct
call, placed to the agent's extension. For example, if an agent received a call directly to his
extension and then transferred the call, the transfer is reported for the default skill group of both
the agent who initiated the transfer and agent who received the transfer.
The transfer or conference is reported for the skill group to which the call was routed if the
original call was routed using an ICM/IPCC routing script to a specific skill group. For example,
if an agent in the Sales skill group received a Sales call and then transferred the call, the transfer
out is reported for the Sales skill group. The transfer in is reported for the skill group of the
agent who received the transfer.
Note: When an agent makes an outbound call as part of a consult call, the call is not attributed
to the Default Skill Group. It is attributed to the skill group for the consulting agent on the
original call.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
68
Chapter 3: Managing Agents
Reporting on Agent Call Transfers and Conferences
The following scenarios further explain how database fields are incremented for different types
of transfers and conferences.
Call Scenario 1: Blind Transfer of ICM-routed call - agent is not available
In this example, agent A is presented with an ICM-routed call for skill group Y. Agent A selects
skill group X using the dialed number (which accesses a script) and initiates and completes a
blind transfer. The InternalCalls and TransferOut fields are then incremented for Agent A against
skill group Y.
After wrap up is completed, the CallsHandled field is incremented for agent A against skill
group Y. Since there are no agents available in skill group X, the call goes to the VRU (VRU
stats not shown). When agent B in skill group X becomes available, the VRU routes the call to
agent B. Agent B answers the call and the call disconnects and wrap up is complete.
Table 20: Blind Transfer of ICM-routed Call: Agent A transfer to Agent B
Fields incremented for Agent A against skill group Fields incremented for Agent B against skill group X
Y
CallsHandled, InternalCall, TransferOut
CallsHandled, TransferIn (IPCC with IPCC System PG and System
IPCC deployments only)
For agent A, the call is reported in the TasksHandled, Internal Out, and TransferOut report
fields. For agent B, the call is reported in the Tasks Handled report fields; in IPCC Enterprise
with IPCC System PG (which supports only IP-IVR and not supports CVP) and System IPCC
deployments, the call is also reported in the TransferIn field.
Call Scenario 2: Consultative Transfer of an ICM-routed call-agent available
In this example, agent A is presented with an ICM-routed call for skill group Y. Agent A selects
skill group X using the dialed number and initiates a transfer. The ICM/IPCC script that uses
the LAA select node for skill group x realizes that Agent B is available and requests that agent
A’s PG initiate a transfer to agent B on behalf of Agent A’s phone. Agent B answers the
transferred call. After consulting with Agent B, Agent A completes the transfer. The InternalCall
and TransferOut fields are then incremented for Agent A against the skill group Y. After wrap
up is completed, the CallsHandled field is incremented for agent A against skill group Y.
Agent B now talks to the caller and when the call disconnects and wrap up is completed,
CallsHandled and TransferIn are incremented for Agent B against skill group X.
Table 21: Consultative Transfer of ICM-routed Call: Agent A transfer to Agent B
Fields incremented for Agent A against skill group Y
Fields incremented for Agent B against skill group
X
CallsHandled, InternalCall, TransferOut, Hold
CallsHandled, TransferIn
For agent A, the call is reported in Tasks Handled, Internal Out, Transfer Out, and Incoming
Hold and/or All Hold report fields. For agent B, the call is reported in Tasks Handled and
Transfer In report fields.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
69
Chapter 3: Managing Agents
Reporting on Agent Call Transfers and Conferences
Call Scenario 3: Consultative Conference of a Direct Call
In this example, a direct call comes into agent A's ACD extension.
Agent A selects skill group X using the dialed number and initiates a conference. The ICM/IPCC
script that uses the LAA select node for skill group X realizes that Agent B is available and
requests that agent A’s PG initiate a conference to agent B on behalf of Agent A’s phone. Agent
B answers the conferenced call. After consulting with Agent B, Agent A completes the
conference.
Agent A disconnects from the conference. The InternalCalls and ConferenceOut and
InternalCallsRvcd fields are then incremented for Agent A against the default skill group.
Agent B or the caller disconnects. InterCallsRcvd and Conference Out are incremented against
the default skill group for agent B.
Table 22: Consultative Conference of a Direct Call: Agent A conferences in Agent B
Fields incremented for Agent A against default skill group Fields incremented for Agent B against skill group
X
InternalCallRcvd, InternalCall, ConferenceOut, Hold
CallsHandled, ConferenceIn
For agent A, the call is reported in Tasks Handled, Internal Out, Conf Out, and All Hold (Internal
Hold) in report fields. For agent B, the call is reported in Tasks Handled and Conf In report
fields.
Call Scenario 4: Consultative Call
In this example, agent A is presented with an ICM-routed call for skill group Y.
Agent A selects skill group X using the dialed number and initiates a consult. The ICM/IPCC
script that uses the LAA select node for skill group X realizes that Agent B is available and
requests that agent A’s PG initiate a conference to agent B on behalf of Agent A’s phone. Agent
B answers the consult call. After consulting with Agent B, Agent A activates the Reconnect
button, which disconnects Agent B and Agent A resumes talking to the caller.
Agent A disconnects from the call. After wrap up is completed, CallsHandled and Consultative
Calls field are incremented for agent A against skill group Y.
Table 23: Consultative Transfer: Agent A consults with Agent B
Fields incremented for Agent A against skill group Y
Fields incremented for Agent B against skill group
X
CallsHandled, InternalCall, ConsultativeCall, Hold
CallsHandled
For agent A, the call is reported in Tasks Handled, Internal Out, Cons Out, and Incoming Hold
and/or All Hold report fields. For agent B, the call is reported in Tasks Handled report fields.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
70
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Transfer and Conference Reporting
Configuration and Scripting Considerations for Transfer and Conference Reporting
Configuration and scripting recommendations for transfers and conferences include transfers
and conferences to skill groups and transfers and conferences to agents.
Configuration and Scripting Considerations for Transfers and Conferences to Skill Groups
Follow these guidelines when configuring and scripting for transfers and conferences to skill
groups:
• Configure the dialed numbers in the ICM/IPCC configuration tool.
• Create a routing script for transferring to skill groups that includes a Queue to Skill Group
node. This script ensures that transferred and conferenced calls are queued to the correct skill
group.
• Associate the dialed number with the routing script.
See the IPCC Administration Guide for Cisco IPCC Enterprise Edition for instructions on
configuring Agent Desk Settings and Dialed Number Plan. See theICM Scripting and Media
Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions for instructions on scripting.
Configuration and Scripting Considerations for Transfers and Conferences to Agents
Follow these guidelines when configuring and scripting for transfers and conferences to agents:
• Configure the dialed number in the ICM/IPCC configuration tool.
The dialed number needs to be associated with an appropriate routing script.
• Create a routing script for transferring to agents that includes a Queue to Agent node.
This script ensures that transferred and conference calls are routed queued to the correct
agents.
See the IPCC Administration Guide for Cisco IPCC Enterprise Edition for instructions on
configuring Agent Desk Settings and Dialed Number Plan. See theICM Scripting and Media
Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions for instructions on scripting.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
71
Chapter 3: Managing Agents
Reporting on Supervisor Action
Reporting on Supervisor Action
Agent team supervisors can take advantage of supervisory features available on their desktops.
These features include Supervisor Assist, Emergency Assist, Barge-In and Intercept. There are
two kinds of Supervisor and Emergency Assist: existing call and no call.
If you are using CVP as the VRU, data is not captured for Barge in or Intercept calls.
Note: These supervisory features are not available to agents using MRDs other than Voice.
WebView reports display data for agent and supervisor use of these features. You might use
this data to identify training needs.
Supervisor and Emergency Assist for Existing Call
Agents can activate supervisor assist or emergency assist buttons on their desktop when they
need special assistance from the primary or secondary supervisor assigned to their team.
Note: Blind transfer is not supported for Supervisor Assist and Emergency Assist.
If consult is selected as an option on the agent desktop settings for supervisor or emergency
assist: if the agent is on a call when he or she activates either the Supervisor or Emergency
Assist feature on her/his desktop, the CTI software activates the conference key on behalf of
the agent’s phone and call the supervisor using the Supervisor or Emergency Assist script. (This
example assumes the emergency or supervisor assist script has an Agent-to-Agent node to find
a supervisor. See Configuration and Scripting Considerations for Reporting on Supervisor
Action.) The supervisor answers the call and consults privately with the agent. The following
fields are incremented within the Agent Skill Group and Skill group tables.
Table 24: Existing Call: Consultative
Fields incremented for Agent's skill group to which the call was Fields incremented for Supervisor's default
routed
skill group
CallsHandled, InternalCall, SupervisorAssistCalls/EmergencyAssist InternalCallsRcvd
For the agent, the call is reported in Tasks Handled and either Sup Assist or Emergency report
fields. For the supervisor, the call is reported in Tasks Handled report fields.
Note: During the consultation, the supervisor can decide to barge-in to the call using the
supervisor desktop Barge-In feature.
Supervisor and Emergency Assist for No Call
The agent can use the Supervisor Assist and Emergency Assist features at any time, even if not
currently on a call. If the agent is not on a call when he or she activates either the Supervisor
or Emergency Assist feature on the agent's desktop, the CTI software activates the make call
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
72
Chapter 3: Managing Agents
Reporting on Supervisor Action
functionality on behalf of the agent’s phone and calls the supervisor using the Supervisor or
Emergency Assist script. The following fields are incremented within the Agent Skill group
and Skill group tables against the default skill group.
Table 25: No Call
Fields incremented for Agent's default skill group
Fields incremented for Supervisor's default skill
group
InternalCall, SupervisorAssistCalls/EmergencyAssist
InternalCallsRcvd
For the agent, the call is reported in Tasks Handled and either Sup Assist or Emergency report
fields. For the supervisor, the call is reported in Tasks Handled report fields.
Barge-In
When the supervisor activates the Barge-in feature from his or her desktop, the agent’s desktop
completes a conference to the supervisor so that the supervisor can join into the conversation
with the call. The following fields are incremented for both the agent and the supervisor when
the barge-in feature is activated in the agent skill group and skill group tables.
Note: If you have deployed CVP as the VRU, data is not gathered for Barge-In.
Table 26: Supervisor Barge-In
Fields incremented for Agent's skill group to which the call Fields incremented for Supervisor's default skill
was routed
group
CallsHandled, InternalCalls, BargeInCalls
BargeInCalls, InternalCallsRcvd
For the agent, the call is reported in Tasks Handled and Barge In report fields. For the supervisor,
the call is reported in Tasks Handled and Barge In report fields.
Intercept
If the supervisor decides to intercept (take over) the call, the supervisor activates the Intercept
button on his or her desktop. This causes the agent to be dropped out of the conference, thereby
allowing the supervisor to take over the call. The following fields are incremented during the
intercept operation for both the agent skill group and skill group tables.
Note: If you have deployed CVP as the VRU, data is not gathered for Intercept.
Table 27: Supervisor Intercept
Fields incremented for Agent's skill group to which the
call was routed
Fields incremented for Supervisor's default skill
group
InterceptCalls
InterceptCalls
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
73
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Reporting on Supervisor Action
For the agent, the call is reported in the Intercept report field. For the supervisor, the call is
reported in the Intercept report field.
Configuration and Scripting Considerations for Reporting on Supervisor Action
To ensure that your reports contain accurate data for supervisor actions, configure and script
for the supervisor features as follows:
• Ensure contact center agents are organized in teams, and that each team has both a primary
and secondary supervisor. This provides each agent team with two levels of supervisory
support.
• Create skill groups specifically for supervisor and emergency assist situations and assign
these to your supervisors to ensure that only supervisor and assist calls will be routed to your
supervisors.
• Define a supervisor dialed number for each agent team in the ICM/IPCC configuration tool.
On the Attributes Tab of the Agent Team dialog box, specify the dialed number in the
Supervisor script dialed number field.
This dialed number identifies a specific routing script when supervisory features are activated.
When the agent activates the supervisor or emergency assist button on his or her phone, the
Supervisor Dialed Number for the agent’s team is sent to the ICM Central Controller.
• Create a routing script for supervisory features to ensures correct routing of calls being
handled using supervisory features. The routing script check the availability of a primary
supervisor and use the Agent-to-Agent node to route the call to the primary supervisor, if
available.
If the primary supervisor is not available, branch the script to another Agent-to-Agent node,
identifying a secondary supervisor.
The script can also use the LAA Select node rather than the Agent-to-Agent node. This allows
you to track specifically the times the supervisor is involved with emergency or supervisor
assist calls.
Note: Additionally, supervisors who leave their position put themselves into a Not Ready state,
to avoid a supervisor or Emergency assist call from being routed to them when they are not at
their desk.
See the IPCC Installation and Configuration Guide for Cisco IPCC Hosted Edition or System
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition for instructions
on configuring these features. See the ICM Scripting and Media Routing Guide for Cisco
ICM/IPCC Enterprise & Hosted Editions for scripting instructions.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Hosted Edition
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
74
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Reporting on Supervisor Action
ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
75
Chapter 3: Managing Agents
Configuration and Scripting Considerations for Reporting on Supervisor Action
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
76
Chapter 4
Measuring Customer Experience
Measuring customer experience involves monitoring how calls were treated in the IPCC
Enterprise system. This might include the number of calls received, the number of calls handled
and abandoned, queue time (answer time), average speed of answer, transfers and whether
Service Level objectives are being met. IPCC Enterprise WebView reports provide metrics that
enable you to monitor real-time customer experience and review historical trends in customer
experience.
This chapter explains which reporting metrics are useful for measuring customer experience in
an IPCC Enterprise system and which report templates contain these metrics. This chapter also
describes how the system gathers customer experience metrics and explains how to configure
and script your system so that your reports contain appropriate and accurate data.
This chapter contains the following topics:
•
•
•
•
•
•
Useful Customer Experience Statistics and Report Templates, page 77
Call Type Reporting, page 80
Configuration and Scripting Considerations for Call Type Reporting, page 85
Reporting on Average Speed of Answer, page 87
Service Level Reporting, page 88
Configuration and Scripting Recommendations for Service Level Reporting, page 95
Useful Customer Experience Statistics and Report Templates
WebView reports enable you to monitor real-time customer experience and review historical
customer experience trends.
These factors determine the reports that you use to measure customer experience:
• Whether you need to view current activity or past experience data
• What data you want to see
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
77
Chapter 4: Measuring Customer Experience
Useful Customer Experience Statistics and Report Templates
How Do You Want to Report on Customer Experience?
The reporting templates that you use to monitor customer experience depend on several factors,
including your role in the contact center and the type of data that you want to see.
First, determine whether you want to view real-time customer experience or past experience
trends. For real-time activity, such as current number of abandoned calls, current Service Levels
and current average speed of answer, use the real-time templates. Real-time templates are
designated by the words "Real Time" in their titles. For past customer experience trends, such
as the average time spent in queue, historical average speed of answer and historical Service
Level information, use the historical templates. Historical templates are designated by the words
"Half Hour", "Summary" or "Daily" in their titles.
Once you have determined whether you want to view real-time or historical templates, you
decide how you want to measure the customers' experience: from end-to-end, with a particular
skill group, or with a particular agent.
While skill group and agent reports provide some of the same metrics as call type reports,
including ASA, abandons, redirects, calls handled, and Service Level, the call type reports show
a more complete picture of the customer experience and are the best suited for measuring
customer experience. Skill group reports provide insight into operational performance and agent
reports provide insight into individual agent performance.
The following table describes the WebView options for measuring customer experience.
Table 28: Report Categories for Measuring Customer Experience
Reporting Needs
Report
Category
Who Use this Category
You want to measure a customer's Call Type
experience from the initial request
to the call completion.
This category is useful to Contact Center Administrators with global
responsibility for all customer contacts. Reporting on customer
experience using this category provides insight in the end-to-end
customer experience for different types of call treatment. This
category provides the most complete view of customer experience.
You want to measure a customer's Skill Group
experience when routed to a
particular skill group.
This category is useful to Contact Center Administrators or
Supervisors who are responsible for a certain groups of agents or
skill groups. Reporting on customer experience using this category
provides insight only into the operational performance of selected
skill groups.
You want to measure a customer's Agent
experience with a particular agent.
This category is useful for Contact Center Supervisors who manage
agents. Reporting on customer experience using this category
provides insight only into the performance of the selected agents
and might identify training needs or agent expertise, but does not
provide a global view of how customers are experiencing their
interactions with the contact center.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
78
Chapter 4: Measuring Customer Experience
Useful Customer Experience Statistics and Report Templates
What Data Do You Want to See?
The reports you use depend on whether you are monitoring real-time customer experience or
historical experience trends.
For both real-time and historical customer experience, you might be interested in these types
of statistics:
• Average Speed of Answer (ASA)
• Number of calls received
• Number of calls handled
• Number of calls abandoned
• How long callers waited in queue
• Number of calls queued for the agent
• Whether Service Level objectives are being met
• Whether the caller had to be transferred
• Number of callers that heard a busy signal
• Where calls are currently located - VRU (prompt or self service), queue, or agent
Real-time customer experience data helps you identify immediate issues, such as Service Levels
not being met, calls waiting in queue too long, or calls abandoning before reaching agents.
The following table describes suggested IPCC Enterprise report templates that provide customer
experience real-time statistics. For details of all IPCC Enterprise report templates, refer to the
WebView Template Reference Guide for Cisco IPCC Enterprise & Hosted Editions.
Table 29: Report Templates for Real-time Monitoring
Template
Statistics Provided
caltyp04: Task Type Service Level Real Time Reports on Service Level status for the day, rolling five minute interval,
Report
and current half hour.
caltyp20: Call Type Real Time Report
Reports on ASA, time spent in queue for the call that has been in longest
in queue, number of calls in queue, number of calls offered, handled and
abandoned, and the number of calls that have received return ring and
return busy treatment. This report also provides the number of calls that
are at the VRU (prompt or self service), in queue and with IPCC agents.
caltyp25: Call Type Queue Status Real Time Reports on the number of calls in queue that are within and outside of
Report
the Service Level threshold.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
79
Chapter 4: Measuring Customer Experience
Call Type Reporting
Template
Statistics Provided
caltyp26: Call Type Tasks Offered Over Half Reports on the number of tasks offered during the current half-hour
Hour Report
interval.
caltyp27: Call Type Queue Delay Status Real Reports on average time in queue, longest call in queue, and ASA for
Time Report
the rolling five minute interval.
caltyp28: Call Type Task Status now Real
Time Report
Reports on the number of calls that are at the VRU, in queue, and with
agents.
Historical agent data helps you identify whether customer experience is improving or degrading.
The following table describes suggested IPCC Enterprise report templates that provide customer
experience historical statistics. For details of all IPCC Enterprise report templates, refer to the
WebView Template Reference Guide for Cisco IPCC Enterprise & Hosted Editions.
Table 30: Report Templates for Historical Reporting
Template
Statistics Provided
caltyp05: Analysis of Calls Half Hour Report
Reports on wait time in queue, number of tasks queued and number of
abandons.
caltyp21: Call Type Half Hour Report
Reports on ASA, Service Level, tasks offered, handled and abandoned,
average abandon delay time, and the number of calls that received
return ring and return busy treatment.
caltyp31: Call Type Abandon/Answer
Distribution by Half Hour
Reports on ASA, average abandon delay, and the number of calls that
have abandoned and been answered in each call type bucket interval.
caltyp33: Call Type Abandon/Answer
Cumulative Distribution by Half Hour
Reports on percent of calls answered and the cumulative number of
calls that have abandoned and been answered in each call type bucket
interval.
caltyp37: Call Type Service Level Abandons
Daily Report
Reports on the number of tasks that abandon within service level
threshold.
Call Type Reporting
Call types define call treatment in an IPCC Enterprise system and group calls for reporting; a
call type is associated with a call at the initial route request and can be changed within a script
for routing and reporting purposes. Therefore, the call type is the highest level reporting entity.
Reporting on call type activity provides insight into end-to-end customer interactions with the
system and with agents by providing data such as Service Level adherence, transfers, average
speed of answer, calls handled, and calls abandoned.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
80
Chapter 4: Measuring Customer Experience
Call Type Reporting
General Call Type Report Data Balancing
Data within call type reports balance for the following:
• Calls answered by agents
• Calls abandoned at the VRU
• Calls that abandon while en-route to an agent or while being offered to an agent's phone
• Short calls
• Calls that are given busy, ring, default routed or network routed treatment
• Calls that go to another call type within a routing script using the Call Type or Requalify
node
• Calls that abandon en-route to the VRU
• Calls that have a bad label
• Calls that re-route on no answer from the agent’s phone
• Calls that terminate the script using the Label node to a non-monitored device, such as voice
mail
How Calls that Encounter Error Conditions Affect Call Type Reporting
Call Errors are counted in the data base as either Agent errors (AgentErrorCount) or Scripting
errors (ErrorCount). The way call errors increment the database depends on whether the call
abandons en-route to the VRU/ICM/IPCC scripts and or abandons en-route to agents:
• Calls that abandon en-route to the VRU/ICM/IPCC scripts are calls that abandon in the
network while they are being sent to the VRU. An example of this is if a call abandons while
it is being sent to the VRU from a CTI Route point in CallManager. These calls are counted
as part of the ErrorCount at the Call Type and included in the "Call Errors" column in the
call type report. This field is included in the call type all fields report. CallErrors also includes
default routed calls as well as the other call scenarios listed below.
Calls that abandon en-route to the VRU might be counted as short calls, instead of errors, if
the caller abandons within the Abandon Wait Time set for the call type. See the next section
for more information on abandoned short calls
If an on-premise VRU is used, then the probability of calls abandoning en-route to the VRU
is very low.
• Calls that abandon en-route to agents are calls that encounter an error when the call is at the
agent desktop. This call is counted as part of the AgentErrorCount at the Call Type, and is
included in the "Call Errors" column in the call type report.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
81
Chapter 4: Measuring Customer Experience
Call Type Reporting
How Calls that Abandon Affect Call Type Reporting
There are three types of abandon metrics: abandon at the VRU (prompt or self service), abandon
in queue, and abandon at the agent.
ICM/IPCC tracks the abandon counts for each of these abandons separately. The time spent by
these abandoned calls before abandoning is also tracked.
The value represented by the “Aban” column on the Call Type reports provides total abandon
count for the call type, that includes calls that abandoned while at the VRU (prompting or self
service), calls that abandon in queue and calls that abandoned while ringing at the agent's phone
or en route to the agent's phone. This is derived from the TotalCallsAbandToHalf database field.
Reports also provide average time spent by these abandoned calls in the “Avg Aban Delay
Time” field. This field represents the average delay time of all abandoned calls that ended in
this call type during the current half hour interval. This is derived from
Call_Type_Half_Hour.CallDelayAbandTimeToHalf /
Call_Type_Half_Hour.TotalCallsAbandToHalf.
To separate information gathering and queuing statistics, you can also determine the time spent
by a call only in the call type where the call abandoned. This is tracked in the
CTDelayTotalAbanTimeToHalf database field. This includes only the time spent in the call
type where the call abandoned and not all call types.
Consider this example:
• A call spends 30 seconds in the information gathering call type, "Info_Call_Type".
• The script then changes the call type to the queuing call type say Queue_Call_Type and the
call is queued.
• After 15 seconds waiting in queue the call is abandoned.
In this case the total time spent by the call before abandoning will be 45 seconds. However the
time spent by the call in the “Queue_Call_Type” where the call abandoned will be 15 seconds.
The Call Type statistics for the “Queue_Call_Type” will be updated as follows:
Queue_Call_Type
• CallDelayAbandTimeToHalf = 45 seconds
• CTDelayTotalAbanTimeToHalf = 15 seconds.
Note: You could write custom reports to able to report on the different abandons and the time
spent by these abandons. To determine the counts and the time associated with the abandoned
calls, for calls in the script, or at the VRU (prompt or Self service), subtract Agent Abandons
and Queue abandons from Total Abandons.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
82
Chapter 4: Measuring Customer Experience
Call Type Reporting
How Abandoned Short Calls Affect Call Type Reporting
A short call at the call type is a call that abandons within the call type's Abandon Wait Time
threshold. By defining what you believe to be a short call, you can filter out those calls that you
believe did not stay in the system long enough to be counted as a real call. You can define short
calls for call types and services. Note that short calls are configured globally for all call types.
The short call timer starts as soon as the route request is received for the call. The CallsOffered
field is updated when the route request is received. If the call abandons within the Abandon
Wait Time threshold, the ShortCalls field is updated, but the number of calls abandoned is not
updated. Since the call type is the highest level reporting entity, calls that abandon at the VRU
or at the agent's phone can also be considered short calls at the call type if they abandon within
the call type's Abandon Wait Time threshold.
If you do not want to count any abandoned calls as short calls regardless of how quickly they
abandon, you can disable abandoned short calls by leaving the Abandon Wait Time field for
the Call Type blank.
For more information about short calls and configuring short calls, see Reporting on Short Calls
(page 108).
How Calls that Have a Bad Label Affect Call Type Reporting
A bad label refers to an incorrectly confugured label or missing label. It is always good practice
to define a default label, so that calls that do encounter an incorrectly configured label can at
least go to the default label and get handled as well as get accounted for in the call type report.
Labels might be configured incorrectly in the following ways:
• The label specified in the script node might not exist on the routing client: In this case, label
specified in the script node might not exist on the routing client.
• The label points to the wrong agent: In this case, the pre-call message is sent to one agent,
but the actual call is sent to a different agent. This call is reported as an incomplete call.
If the node does not define a label, the call encounters error conditions and is reported as an
error.
How Calls that Experience Redirection on No Answer with IP IVR Affect Call Type Reporting
Redirection on No Answer calls are calls that redirect off the agent’s phone because the ring
time exceeds the Ring No Answer timer defined in the agent desktop settings. For Redirection
on No Answer situations, you configure a separate call type and routing script to be used if
agents do not answer ringing calls within the ring no answer time. In the Redirection on No
Answer script, you queue the call at a higher priority so that the call does not fall to the bottom
of the queue.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
83
Chapter 4: Measuring Customer Experience
Call Type Reporting
In an IPCC Enterprise environment, Redirection on No Answer situations increment call type
statistics as follows:
• For the initial call type, CallsOffered is incremented. When the call redirects, the CallsRONA
field is incremented.
• For the Redirection on No Answer call type, CallsOffered is incremented as well as fields
related to the completion of the call. For example, if the call is handled the CallsHandled
field is incremented.
Because CallsOffered is incremented twice for the call, use a different call type for Redirection
on No Answer calls to ensure that the call does not peg the same call type twice.
In call type reports, these calls are grouped into the "Other" column. You can also view a
count of Redirection on No Answer calls in agent and skill group reports.
How Calls that Experience Redirection on No Answer with CVP Affect Call Type Reporting
The Redirection on No Answer feature, configured in Agent Desk Settings in ICM/IPCC
configuration tool and in CVP, ensures that when an agent does not answer a call, the call is
taken away from the agent after a specified number of seconds and re-assigned to another agent
or requeued. Redirection on No Answer is also used to change the agent state to Not Ready
when a call is rerouted from the agent's phone. When the Ring No Answer time in the Agent
Desk Settings expires, ICM/IPCC software makes the agent unavailable for routing requests.
When the CVP Ring No Answer timeout expires, the call is requeried for routing to a different
skill group or agent. You configure the CVP Ring No Answer timer to be approximately 2
seconds longer than the Agent Desk Settings Ring no answer time so that the agent is made Not
Ready before the call is requeried. If the agent is not made unavailable first, the script might
reassign the call to the same agent.
Note: The CVP Ring No Answer timeout must be less than 30 seconds because the ICM/IPCC
Central Controller waits up to 30 seconds for a response from the CVP. If the response is not
received within 30 seconds, the call fails.
Because the Ring No Answer time and CVP Ring No Answer timeout are several seconds apart,
it is possible that the call will continue to ring on the agent's phone after the agent is made Not
Ready. If the agent answers the phone in this brief interval, the context of the call will not be
reported and reports will show that the agent went directly into Active state from Not Ready
state.
You can configure the routing script to handle Redirection on No Answer situations in two
ways: the script can change the call type when the calls is requeried, or the script can continue
to use the same call type.
The manner in which you script for Redirection on No Answer affects the report data that you
see, as follows:
• If you change the call type (recommended), CallsOffered, CallsRequeried, and OverflowOut
is updated for the initial call type. CallsOffered and fields related to the completion of the
call, such as CallsHandled, are incremented for the second call type.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
84
Chapter 4: Measuring Customer Experience
Configuration and Scripting Considerations for Call Type Reporting
Using two call types enables you to identify Redirection on No Answer occurrences in call
type reports. For example, if you create a specific call type for use in Redirection on No
Answer situations, then you can see whether calls are redirecting by monitoring the calls
offered to that call type. You can also see whether the Flow Out field is incremented for other
call types.
• If you do not change the call type, CallsOffered and fields related to the completion of the
call, such as CallsHandled, are incremented. FlowOut is not incremented. You will not be
able to tell without looking at agent or skill group reports whether calls are redirecting on no
answer. (You could write a custom report to see values for CallsRequeried.)
Note: Because the CVP application performs a requery to redirect the call to a different agent
or skill group instead of branching to another script, the CallsRONA field is not incremented
for the call type.
How Calls that Terminate Label Node and Route to Non-Monitored Devices Affect Reporting
The Label node is used to divert a call to voice mail or web attendant or some other device that
is not monitored by ICM/IPCC because of digits collected by the caller during a voice menu or
due to some other conditions. These calls are counted as RoutedNonAgent and appear in the
"Other" column of call type reports.
Note: Use an ICM/IPCC routing scripting script, not a VRU script, to route calls to
non-monitored devices. If you use the VRU script, calls are reported as abandoned at the call
type.
Configuration and Scripting Considerations for Call Type Reporting
When configuring and scripting for call type reporting, you must consider call type bucket
intervals, Redirection on No answer situations, calls that route to non-monitored devices, and
abandoned short calls.
Configuration and Scripting Considerations for Redirection on No Answer with IP IVR Reporting
Follow these guidelines when configuring and scripting for Redirection on No Answer
• Ensure that a CTI route point is defined to use for Redirection on Ring No Answer.
• Configure the Ring no answer settings in the Agent Desk Settings in the ICM/IPCC
configuration tool. Enter a Ring no answer time. If you use Service Level metrics within
your reports and you want Reroute on Ring No Answer calls to adversely affect the Service
Level, set the Service Level Threshold time below the Ring No Answer time. Enter a Ring
no answer dialed number to which to redirect calls that are not answered by agents within
the Ring No Answer time.
• Create a separate script for Redirection on No Answer. In the initial script, change the call
type to direct the call to the Redirection on No Answer script. This ensure that the call is not
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
85
Chapter 4: Measuring Customer Experience
Configuration and Scripting Considerations for Call Type Reporting
recorded twice for the same call type. In the Redirection on No Answer Script, queue the
calls at a higher priority.
See Configuration and Scripting Recommendations for Task Reporting (page 64) for additional
considerations for configuring and scripting for Reroute on Ring No Answer situations.
Configuration and Scripting Considerations for Redirection on No Answer with CVP Reporting
Follow these guidelines when configuring and scripting for Redirection on No Answer:
• Configure the Ring no answer time in the Agent Desk Settings in ICM/IPCC configuration
tool. This timer will be used to make an agent Not Ready if the agent does not answer a
ringing call within the Ring no answer time.
• Configure the CVP Ring No Answer timeout in the CVP Voice Browser Administration
application. This timer will be used to requery the call if the call is not answered within the
Ring No Answer time. This number be approximately 2 seconds higher than the Ring no
answer time configured in Agent Desk Settings and be less than 30 seconds. This ensure that
the agent is made Not Ready so that the same agent does not receive the call.
• Within the routing script, check the Target Requery option on the Set, Queue, or Select node,
as appropriate for the script and create a path for calls that requeried with the script. Queue
calls that are requeried at a higher priority.
See Configuration and Scripting Recommendations for Task Reporting (page 64) for additional
considerations for configuring and scripting for Reroute on Ring No Answer situations.
Configuration and Scripting Considerations for Reporting on Calls that Route to Non-Monitored Devices
Use an ICM/IPCC routing scripting script, not a VRU script, to route calls to non-monitored
devices. If you use the VRU script, calls are reported as abandoned at the call type.
Configuration and Scripting Recommendations for Reporting on Abandoned Short Calls for the Call Type
See Configuration and Scripting Recommendations for Reporting on Short Calls (page 110) for
considerations for configuring short calls for IPCC Enterprise.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
86
Chapter 4: Measuring Customer Experience
Reporting on Average Speed of Answer
Reporting on Average Speed of Answer
Average Speed of Answer (ASA) is the total wait time of a call before being answered divided
by the number of answered calls.
ASA is set at these levels:
• Call type
• Skill group
• Agent
For measuring overall customer experience, the ASA for the call type provides the most insight
into overall call treatment. At the skill group and agent level, the ASA metric is more useful
for monitoring agent and skill group performance than for obtaining insight into how callers
are experiencing the system.
ASA for the Call Type
The ASA is calculated for the call type at the ICM/IPCC Central Controller. ASA is
AnswerWaitTime divided by CallsAnswered. The ICM/IPCC Central Controller can determine
the complete AnswerWaitTime only when it receives the answer event from the Cisco
CallManager peripheral. When the answer event is received, the ICM/IPCC Central Controller
adds the Answer WaitTIme it calculates into the AnswerWaitTimetoHalf in the CallType Half
Hour table. The Answer wait time starts at the first Queue to Skill Group node that was executed
for the call and ends when the call was answered
You can find ASA information for the call type in real-time and historical Call Type WebView
reports.
ASA for the Skill Group
The ASA is calculated for the skill group at the PG level. ICM/IPCC sends the queue time to
the PG when the agent becomes available for the call. This queue time is the total queuing time
of the call, beginning when the first queue to skill group node is executed in the routing script
for the call. This time is sent to the PG by ICM/IPCC when the agent becomes available for the
call.
Consider this example:
• A call is queued at Skill Group X
• At Time T the call is then queued at Skill Group Y at time T+30 seconds
• An additional 10 seconds transpire before the call is answered by an agent at Skill Group Y
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
87
Chapter 4: Measuring Customer Experience
Service Level Reporting
In this case, the internal queuing time will be 40 seconds. This is the total length that the call
has been queued even though it was only queued at Skill Group Y for 10 seconds.
The agent’s PG adds the internal queue time, ring time, network time to create the total answer
wait time for the call and adds it to AnswerWaitTimetoHalf in the skill group table.
AnswerWaitTime is then divided by CallsAnswered within the skill group table to arrive at the
ASA for the skill group.
You can find ASA information for the skill group in real-time and historical Skill Group
WebView reports.
ASA for the Agent
The ASA is calculated for the agent at the PG level. The internal queuing time is sent to the PG
by ICM/IPCC when an agent becomes available for there call. The agent’s PG adds up the
internal queue time, ring time and network time and adds it into AnswerWaitTimetoHalf in the
agent skill group table. AnswerWaitTime is then divided by the CallsAnswered for the agent.
You can find ASA information for the agent in real-time and historical Agent WebView reports.
Service Level Reporting
Service Levels help you to set and measure goals for answering calls. Service Levels are
configurable; that is you can define them in different ways, depending on the kind of information
you want them to provide.
How Service Levels are Calculated
Two important configuration parameters contribute to the calculation of Service Level:
• Service Level type
• Service Level threshold
Service Level type determines how calls that abandon before Service Level threshold impact
the Service Level. Some contact centers want abandoned calls to positively impact the Service
Level. These contact centers consider a call abandoned within the Service Level threshold time
a treated call (abandoned calls positively impact the Service Level). Other contact centers
consider only those calls answered within the Service Level threshold time treated calls. These
contact centers might want the Service Level to be detrimentally affected by calls that abandon
within the Service Level time (abandoned calls negatively impact the Service Level. Others
might choose to exclude the abandoned calls from the Service Level calculation (Abandoned
Calls Ignored).
You can specify the Service Level type by choosing one any of the following options:
• Abandoned Calls Ignored
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
88
Chapter 4: Measuring Customer Experience
Service Level Reporting
• Abandoned Calls negatively impact Service Level
• Abandoned calls positively impact Service Level
A Service Level threshold is the number of seconds you set as a goal to treat a call. To calculate
the Service Level for a period of time, ICM/IPCC software determines the number of calls that
have had a Service Level event within that interval.
A Service Level event occurs when one of three things happen to the call:
• The call is answered by an agent before the Service Level threshold expires. In this case, the
ServiceLevelsCallsOffered and ServiceLevelCalls database fields are incremented.
• The call abandons before the Service Level threshold expires. In this case, the
ServiceLevelCallsOffered and ServiceLevelAband database fields are incremented.
• The call redirects on no answer before the Service Level threshold expires. In this case, the
ServiceLevelCallsOffered database field is incremented.
• The Service level threshold timer expires. The call reaches the Service Level threshold without
being answered by an agent or abandoned. In this case, the ServiceLevelCallsOffered database
field is incremented.
Note: Service Level is not affected for calls that are neither answered nor abandoned within the
Service Level time. For example, calls that encounter an error condition or are sent to
non-monitored devices (using the label node) within the Service Level threshold do not affect
the Service Level.
There are three different ways to calculate Service Level based on the Service Level type defined
for the Service Level configuration parameter, described in the following table.
Note that RouterCallsDequeued, used in the skill group Service Level calculation refers to the
number of tasks that are dequeued form a skill group. Calls may be dequeued using Cancel
Queue node or when they are dequeued from the skill group to be routed to a different skill
group. For example, if a call is queued to two skill groups, and was answered by one of the skill
groups, the call is considered dequeued in other skill group.
Table 31: Service Level Formulas
Service Level Type
Formula Used to Determine Service Level
Ignore Abandoned Calls
For call type and service: ServiceLevelCalls/(ServiceLevelCallsOffered ServiceLevelAband)
For skill group: ServiceLevelCalls/(ServiceLevelCallsOffered ServiceLevelAband -RouterCallsDequeued)
Negative impact of abandoned calls For call type and service: ServiceLevelCalls/ (ServiceLevelCallsOffered )
For skill group: ServiceLevelCalls/ (ServiceLevelCallsOffered RouterCallsDequeued )
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
89
Chapter 4: Measuring Customer Experience
Service Level Reporting
Service Level Type
Formula Used to Determine Service Level
Positive impact of abandoned calls
For call type and service (ServiceLevelCalls + ServiceLevelAband)
/(ServiceLevelCallsOffered - RouterCallsDequeued)
For an example of how call type Service Level and Service Level are calculated, consider the
following call counts:
• Answered within Service Level threshold (ServiceLevelCalls) = 70
• Abandoned within Service Level threshold (ServiceLevelAband) =10
• Exceeded Service Level threshold (ServiceLevelCallsOffered – (ServiceLevelCalls +
ServiceLevelAband)) = 20
• Total Service Level events (ServiceLevelCallsOffered) = 100
The following table shows the different Service Levels calculated, based on the effect of
abandoned calls on Service Level setting.
Table 32: Service Levels Based on Different Calculations
Effect of abandoned calls on Service Level setting Calculated Service Level
Abandoned Calls ignored
70/ (100-10)=77%
Abandoned Calls negatively impact
70/100=70%
Abandoned calls positively impact
(70 + 10)/100=80%
For an example of how skill group Service Level is calculated, consider the following call counts
where type is set to Ignore Abandoned Calls:
• Twenty calls queued to two skill groups using one Queue to Skill Group Node
• Ten calls answered by skill group 1. Answered within Service Level threshold
(ServiceLevelCalls) = 4
Ten calls are answered by skill group 2. Answered within Service Level threshold
(ServiceLevelCalls) = 3
• Total number of CallsDequeued for skill group 1 = 10
Total number of CallsDequeued for skill group 2 = 10
• Service Level events for each skill group (ServiceLevelCallsOffered) = 20
• Total Service Level events for each skill group (ServiceLevelCallsOffered) = 20
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
90
Chapter 4: Measuring Customer Experience
Service Level Reporting
• Service Level for skill group 1
(ServiceLevelCalls/(ServiceLevelCallsOffered-ServcieLevelCallsAband RouterCallsDequeued) = 40% (4/(20-0-10)
Service Level for skill group 2
(ServiceLevelCalls/(ServiceLevelCallsOffered-ServcieLevelCallsAband RouterCallsDequeued) = 30% (3/(20-0-10)
Service Levels per Reporting Entity
Service levels can be defined for:
• Call type
• Skill Group
• Peripheral VRU service
For measuring overall customer experience, the service level for the call type provides the most
insight into overall call treatment. At the skill group level, the service level metric is more useful
for monitoring agent and skill group performance than for obtaining insight into how callers
are experiencing the system.
For each of these entities, you can configure either global service levels or individual service
levels.
Service Level at the Call Type
The service level threshold timer at the call type starts as soon as the call enters the call type
that has a service level defined. When the service level timer expires, the service level is applied
to the current call type associated with the call.
If a call type is changed using the Requalify or Call type nodes, then the service threshold timer
is reset.
Only Call Types that are associated with scripts that use the Queue To and LAA Select nodes
in them define service levels.
There are four service level events that can occur for the call type:
• The call is answered by an agent before the Service Level threshold expires. In this case, the
ServiceLevelsCallsOffered and ServiceLevelCalls database fields are incremented.
• The call abandons while in the VRU (prompt or queue) or at the agent’s phone before the
Service Level threshold expires. In this case, the ServiceLevelCallsOffered and
ServiceLevelAband database fields are incremented.
• The call redirects on no answer before the Service Level threshold expires. In this case, the
ServiceLevelCallsOffered and ServiceLevelRONA database field is incremented.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
91
Chapter 4: Measuring Customer Experience
Service Level Reporting
• The Service level threshold timer expires. Example: the call reaches the Service Level
threshold without being answered by an agent or abandoned. In this case, the
ServiceLevelCallsOffered database field is incremented.
If calls encounter an error before the Service Level threshold expires, ServiceLevelError database
field is incremented but ServiceLevelOffered is not incremented. However if the call encounters
an error after the Service Level threshold expires, ServiceLevelOffered is incremented.
As seen above ICM/IPCC gathers metrics for calls that RONA (if you are using IP IVR as the
VRU) and for several types of errors at the call type. You could write a custom report to exclude
these from call type Service Level.
To exclude calls that RONA:
• If you would like to exclude only calls that redirect on no answer before the Service Level
threshold expires, adjust the ServiceLevelCallsOffered by excluding the ServiceLevelRONA
calls. In this example, abandoned calls have a negative impact.
ServiceLevel = ServiceLevelCalls / (ServiceLevelCallsoffered – ServiceLevelRONA)
• If you would like to exclude all calls that redirect on no answer irrespective of the Service
Level threshold then adjust the ServiceLevelCallsOffered by excluding all RONA calls. In
this example, abandoned calls have a negative impact.
ServiceLevel = ServiceLevelCalls / (ServiceLevelCallsoffered – CallsRONA)
To exclude errors from your Service Level calculation
• Adjust the ServiceLevelCallsOffered by excluding error calls. Adjusted SL Offered calls =
SL Offered calls – ( Total Error calls - ServiceLevelError)
For example, if abandoned calls have Negative Impact, ServiceLevel = ServiceLevelCalls /
(ServiceLevelCallsoffered – (AgentErrorCount + ErrorCount – ServiceLevelError))
Service Level at the Skill Group
The service level threshold timer at the skill group starts as soon as the call is queued to a skill
group.
There are five service level events that can occur for the call type:
• The call is answered by an agent before the Service Level threshold expires. In this case, the
ServiceLevelsCallsOffered and ServiceLevelCalls database fields are incremented are
incremented for the skill group that answered the call. If the call is queued to more than one
skill group, then ServiceLevelsCallsOffered and ServiceLevelCallsDequeued database fields
are incremented for the other skill groups
• The call is dequeued from a skill group before the Service Level threshold expires. In this
case ServiceLevelsCallsOffered and ServiceLevelCallsDequeued database fields are
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
92
Chapter 4: Measuring Customer Experience
Service Level Reporting
incremented. Calls may be dequeued using Cancel Queue node, when they are de-queued
from the skill group to be routed to a different skill group.
• The call abandons while in the VRU (queue) or at the agent’s phone before the Service Level
threshold expires. In this case, the ServiceLevelCallsOffered and ServiceLevelAband database
fields are incremented.
• The call redirects on no answer before the Service Level threshold expires. In this case, the
ServiceLevelCallsOffered and ServiceLevelRONA database field is incremented.
• The Service level threshold timer expires. Example: the call reaches the Service Level
threshold without being answered by an agent or abandoned. In this case, the
ServiceLevelCallsOffered database field is incremented.
In ICM/IPCC calls can queue to more than one skill group depending on your scripting, and
therefore Service Level metrics are updated for each skill group to which a single call queues.
Therefore, it is important to understand how Service Levels are impacted in such cases.
• If a call is queued to more than one skill group and then the call is answered before the Service
Level threshold expires ServiceLevelsCallsOffered and ServiceLevelCalls database fields
are incremented for the skill group that answered the call. For the other skill groups
ServiceLevelsCallsOffered and ServiceLevelCallsDequeued database fields are incremented.
• If a call is queued to more than one skill group and the call abandons in queue before the
Service Level threshold expires then ServiceLevelsCallsOffered and ServiceLevelCallsAband
database fields are incremented for all the skill groups. This will have a negative or positive
impact on Service Levels in all the skill groups depending on how you have decided to treat
abandon calls for Service Level calculations in your configuration for the individual skill
groups.
• If a call is queued to more than one skill group and the call abandons in queue after the
Service Level threshold expires then ServiceLevelsCallsOffered database field is incremented
for all the skill groups. This will adversely affect your Service Level.
• If a call is queued to more than one skill group and the call abandons after it was routed to
a skill group (example: Abandon while ringing at the agent) before the Service Level threshold
expires, ServiceLevelCallsOffered and ServiceLevelCallsAband database fields are
incremented for the skill group that had the abandon, while other skill groups have
ServiceLevelCallsOffered and ServiceLevelCallsDequeued database fields incremented.
As seen above ICM/IPCC gathers metrics for calls that RONA (if you are using IP IVR as the
VRU) and for several types of errors at the skill group. You could write a custom report to
exclude these from skill group Service Level.
To exclude calls that RONA:
• If you would like to exclude only calls that redirect on no answer before the Service Level
threshold expires, adjust the ServiceLevelCallsOffered by excluding the ServiceLevelRONA
calls. In this example, abandoned calls have a negative impact.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
93
Chapter 4: Measuring Customer Experience
Service Level Reporting
ServiceLevel = ServiceLevelCalls / (ServiceLevelCallsoffered – RouterCallsDequeued ServiceLevelRONA)
• If you would like to exclude all calls that redirect on no answer irrespective of the Service
Level threshold then adjust the ServiceLevelCallsOffered by excluding all RONA calls. In
this example, abandoned calls have a negative impact.
ServiceLevel = ServiceLevelCalls / (ServiceLevelCallsoffered – RouterCallsDequeued
CallsRONA)
If you want to remove errors from SLCallsOffered, you can use this formula in a custom report:
SLCallsOffered – (Errors –SLErrors).
Service Level at the Peripheral VRU Service - Not Applicable for System IPCC Deployments
The service level threshold timer at the VRU service starts as soon as the call arrives at the VRU
service.
There are three service level events that can occur for the peripheral VRU service:
• Call is routed to an agent before service level timer expires. In this case the
ServiceLevelCallsOffered and ServiceLevelCalls database fields are incremented.
• Call abandons while in the VRU before service level timer expires. In this case the
ServiceLevelAband and ServiceLevelCallsOffered database fields are incremented.
• Service level threshold timer expires. In this case the ServiceLevelCallsOffered database
field is incremented.
The VRU Service does not detect abandons that happen at the peripheral agent service, so these
will not be part of the service level for the VRU service. The VRU service does not detect when
the call is physically answered by the agent; it only knows when the call is routed to the agent.
Using Call Type Interval Reporting to Monitor Service Level
You can use call type interval reports to see data for abandoned and answered calls within
specific time increments, such as between 0 and 5 seconds, or within specific time boundaries,
such as under 10 seconds. You might want to configure the intervals in relation to your Service
Levels. For example, if your Service Level threshold is 60 seconds and you want to see when
callers are abandoning in relation to your Service Level you might set intervals of 20 seconds,
40 seconds, 60 seconds, 80 seconds, and 100 seconds. Using these intervals, you can see how
closely to the Service Level calls are abandoning. You configure call type intervals using the
Bucket Interval configuration tool and then assign these intervals to individual call types using
the Call Type configuration tool or to the system using the System Information tool. If you do
not configure intervals at the call type level, the system level intervals are used.
Reports show up to ten intervals. You can configure up to nine intervals; the tenth interval shows
all remaining data.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
94
Chapter 4: Measuring Customer Experience
Configuration and Scripting Recommendations for Service Level Reporting
Consider this example:
• Upper bound 1 is set to 20 seconds
• Upper bound 2 is set to 40 seconds
• Upper bound 3 is set to 60 seconds
• Upper bounds 4-9 are not set
In your reports, you see intervals of data for answered and abandoned calls from 0-20 seconds,
20-40 seconds, 40-60 seconds, and greater than 60 seconds. If you run a cumulative report, you
see data for less than 20 seconds, less than 40 seconds, less than 60 seconds, and the total number
of calls.
WebView provides two call type interval reports that measure answered and abandoned calls
for specific increments:
• caltyp31: Call Type Abandon/Answer Distribution by Half Hour
• caltyp32: Call Type Abandon/Answer Distribution.
These reports show calls that abandoned and were answered within the increments that you set:
for example, 0-20 seconds, 20-40 seconds, etc.
WebView also provides two call type interval reports that provide cumulative data based on
the intervals you configured:
• caltyp33: Call Type Abandon/Answer Cumulative Distribution by Half Hour
• caltyp34: Call Type Abandon/Answer Cumulative Distribution
These reports show cumulative data for calls that abandoned and were answered for the
increments that you set: for example, less than 20 seconds (<00:20), less than 40 seconds
(<00:40), less than 60 seconds (<00:60), etc.
Configuration and Scripting Recommendations for Service Level Reporting
Configuring and scripting for service level reporting involves configuring the service level type
and threshold for the call type, skill group and enterprise and creating routing scripts that gather
the correct statistics.
Follow these guidelines when configuring service level:
• You can configure the Service Level settings for all call types. You can override these settings
for individual call types using the ICM/IPCC configuration tools.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
95
Chapter 4: Measuring Customer Experience
Configuration and Scripting Recommendations for Service Level Reporting
Service level time begins as soon as the call enters a call type. Therefore set up call
types/scripts used specifically to collect queue and agent statistics such that service level
time begins once a call is queued to a skill group. Define service levels only for call types
that point to a script that includes a Queue to Skill Group Node.
• You can configure the Service Level settings for all skill groups in the Media Routing Domain
using the ICM/IPCC configuration tool. You can override these settings for individual skill
groups using the ICM/IPCC configuration tools.
• Configure the Service Level settings for all VRU services on a VRU peripheral. This is not
applicable for System IPCC or ARI deployments. You can override these settings for
individual services.
Note that the service level defined at the service (VRU) takes precedence over the service
level defined at the peripheral (VRU).
Follow these guidelines when scripting for service level:
• Set up a call type to collect statistics prior to the queue (that is, the initial call type designated
for the script using call type mapping.
• Set up other call types used specifically to collect queue and agent statistics.
• In your routing scripts, include the Requalify or Call Type nodes to submit the call to the
call type used to collect queuing information.
• If you want to use call type interval reporting, configure Bucket Intervals. You can create
more than one group of intervals. You can assign these intervals at either the call type level
or the system level.
• In ICM/IPCC calls can queue to more than skill group and service level metrics are updated
for each skill group to which a single call queues. Service Levels could be adversely affected
if calls abandon within or outside the service level threshold in such cases. Consider queuing
to a single skill group if you include abandons in your Service Level calculations and don’t
want abandons to affect Service Levels adversely.
If you follow these recommendations, the first call type (to which the call was initially mapped)
will gather statistics before the call is queued to the skill group. The script will then pass the
call to the call type set up specifically to collect information after the call is queued to the skill
group.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
96
Chapter 5
Monitoring Operations, Configuration, and Scripting
Monitoring operations, configuration, and scripting involves monitoring VRU applications,
Outbound Option calls, and script efficiency. This might include the number of short calls, how
many calls are pegging the default skill groups, how many outbound campaign calls are being
made, how you are utilizing the agents, and how customers are using self-service and information
gathering VRU applications. IPCC Enterprise WebView reports provide metrics that enable
you to monitor real-time operational activity and review historical trends in contact center
operations.
This section explains the reporting metrics useful for monitoring operations, configuration, and
scripting in an IPCC Enterprise system. It also lists the report templates that contain these
metrics. This section also describes how the system gathers operational information and explains
how to configure and script your system so that your reports contain appropriate and accurate
data.
This chapter contains the following topics:
•
•
•
•
•
•
•
•
•
•
•
•
Useful Operational, Configuration, and Scripting Statistics and Report Templates, page 98
The Role of the Default Skill Group in Reporting, page 105
Configuration and Scripting Recommendations for Default Skill Group Reporting, page 107
Reporting on Outbound Dialing Campaign Effectiveness, page 107
Configuration and Scripting Recommendations for Reporting on Outbound Dialing Campaigns,
page 108
Reporting on Short Calls, page 108
Configuration Recommendations for Reporting on Short Calls, page 110
Determining Full-Time Equivalents and Percent Utilization, page 110
Understanding VRU Application Reporting, page 111
Determining Self-Service Application and Information Gathering Application Effectiveness,
page 115
Configuration and Scripting Recommendations for Self-Service Applications, Information
Gathering Applications, and Queue Applications Reporting, page 118
Translation Route Reporting, page 119
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
97
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
Useful Operational, Configuration, and Scripting Statistics and Report Templates
WebView reports enable you to monitor real-time operational activity and review historical
operational performance trends. This information helps you identify how well your configuration
and scripts are performing and helps you determine when modifications are required to improve
operational performance.
These factors determine the reports that you use to monitor operations, configuration, and
scripting:
• Whether you need to view current activity or past performance data
• Whether you want to monitor agent utilization, default skill group, Outbound Option calls,
queue, VRU capacity, or VRU Self-Service application information
How Do You Want to Report on Operations, Configuration, and Scripting?
The reporting templates that you use to monitor operational performance depend on several
factors, including your role in the contact center and the type of data that you want to see.
First, determine whether you want to view real-time operational data or past performance trends.
For real-time activity, such as current Outbound Option campaign details and agent utilization
information, use the real-time templates. Real-time templates are designated by the words "Real
Time" or "Rolling 5 Minute" in their titles. "Real Time" indicates that the data is current within
the last 15 seconds. "Rolling 5 Minute" indicates that the data is for the past five minutes, up
to the time at which the report is run. This data is updated every three seconds.
For past performance trends, such as the number of tasks abandoned in queue, how many calls
were successfully handled by the VRU Self-Service application and how many Outbound
campaign calls were answered by customers, use the historical templates. Historical templates
are designated by the words "Half Hour", "Summary" or "Daily" in their titles.
Once you have determined whether you want to view real-time or historical templates, you
decide which area of operations you want to monitor: staffing requirements, default skill group
usage, Outbound Option campaigns, queue information, VRU capacity, or Self-Service
application effectiveness. The following table describes the WebView options for monitoring
these operations.
Table 33: Report Categories for Monitoring Operations, Configuration, and Scripting
Reporting Needs
Report Category
You want to view current Full-time Equivalents Skill Group >
(FTE) and percent utilization of agents to
Peripheral Skill
monitor real-time operations or measure trends Group
in FTE and percent utilization for planning
purposes.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
98
Who Use this Category
This category is useful to Contact Center
Administrators with global responsibility for
staffing and operational monitoring.
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
Reporting Needs
Report Category
Who Use this Category
You want to view the number of short calls to Agent > By
determine whether the short calls configuration Peripheral
is correct.
This category is useful to Contact Center
Administrators responsible for IPCC Enterprise
configuration.
Skill Group >
You want to view current activity for the
default skill group to monitor when the default Peripheral Skill
system behavior is used or monitor trends in Group
default skill group usage to modify scripts or
configuration.
This category is useful to Contact Center
Administrators who are responsible for the IPCC
Enterprise configuration and scripts.
You want to view current activity Outbound Outbound Option
Option dialing campaigns or review trends in
the performance of these campaigns.
This category is useful to Contact Center
Administrators or Supervisors who manage
outbound dialing campaigns. It is also useful for
Administrators responsible for the Outbound
Option Dialer, query rules, and record import
configuration.
You want to view current queue activity or
review trends in queue performance.
Service > Peripheral This category is useful to Contact Center
Service
Administrators or Supervisors who monitor
queuing success and abandons. This information
is useful to identify training or staffing needs and
necessary script or configuration modifications.
You want to view historical VRU peripheral
usage to identify whether the call volume is
below or exceeding VRU capacity.
Peripheral
This category is useful to Contact Center
Administrators responsible for VRU performance,
configuration, and scripting.
You want to view trends in VRU Self-Service Call Type and
These categories are useful to Contact Center
application usage to identify whether these
Service > Peripheral Administrators responsible for configuring and
applications are successfully meeting caller's Service
maintaining VRU Self-Service applications.
needs or require modification.
What Data Do You Want to See?
The reports you use depend on whether you are monitoring real-time operational status or
historical performance.
Real-time agent data helps you identify immediate issues with configuration and scripts.
If you are monitoring operations in real-time, you might be interested in these types of statistics:
• Current full-time equivalent information for agents, which is the number of full-time agents
required to handled the current volume of work. This information might help to identify
staffing needs.
• Percent utilization of agents. This information might help to identify staffing needs.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
99
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
• Number of short calls, which identifies whether short calls are configured and behaving
appropriately. For example, if you notice that a large number of calls are abandoning within
the short call timer, you might have the timer set too low.
• Current default skill group activity, which indicates that a call came in directly to an agent's
extension, an outgoing call was placed by an agent, or agents are calling each other directly.
Default skill group activity might indicate improper scripting to track these calls against the
right skill group.
• Current Outbound Option campaign activity, including the status of campaigns, the dialer,
and record import.
The following table describes suggested IPCC Enterprise report templates that provide real-time
operational statistics. For details of all IPCC Enterprise report templates, refer to the Cisco IP
Contact Center Enterprise Edition WebView Template Reference Guide.
Table 34: Report Templates for Real-time Monitoring
Template
Statistics Provided
agtskg06: Outbound Option Status
Reports on the Outbound Option call
status, the current state of the agents
(talking, active, work ready, work not
ready, hold, paused), the campaign
name, the telephone and account
number of the customer contacted.
perskg05: Peripheral Skill Group % Utilization of Ready Agents
Reports on current percent utilization
of agents who are logged into the
system and are able to handle requests.
perskg11: Outbound Option Statistics
Reports on the Outbound Option status
of the selected peripheral skill group,
the number of agents on
predictive/progressive tasks, preview
tasks, reserved tasks.
perskg14: IPCC Rolling 5-minute Peripheral Skill Group Status
Reports on current full-time equivalents
for agents logged on and in Not Ready,
Available, Active, Wrap Up, Reserved,
Hold, and Busy Other states.
camqry01: Status of Each Query Rule within a Campaign Real Time
Reports on current available phone
numbers, number of calls closed,
number of customers contacted, number
of customers who requested callback,
average talk time, and average wrap up
time for each query in an Outbound
Option campaign.
camqry02: Status of all Campaigns Real Time
Reports on current available phone
numbers, number of calls closed,
number of customers contacted, number
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
100
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
Template
Statistics Provided
of customers who requested callback,
average talk time, and average wrap up
time for all Outbound Option
campaigns.
dialer01: Dialer Real Time
Reports on current number of customers
dialed, contacted, not answered, and
abandoned for Outbound Option
campaigns. Also reports on the
detection of busy, voice, answering
machine, and SITTones.
dialpr01: Dialer Port Status Real Time
Reports on the status of each Outbound
Option dialer port and dialer activity on
a port by port basis.
imprul01: Import Status Real Time
Reports on the status of record
importing, including the start time of
the import, status of the import, number
of good and bad records imported, and
the total number of records imported/to
be imported for Outbound Option
campaigns.
Historical agent data helps you identify historical performance trends and whether script or
configuration modification is required to enhance operational effectiveness.
If you are measuring performance trends, you might be interested in these types of statistics:
• Historical full-time equivalent information for agents, which is the number of full-time agents
required to handled the current volume of work. This information might help to identify
staffing needs.
• Number of short calls, which identifies whether short calls are configured and behaving
appropriately. For example, if you notice that a large number of calls are abandoning within
the short call timer, you might have the timer set too low.
• Historical default skill group activity, which indicates that a call came in directly to an agent's
extension, an outgoing call was placed by an agent, agents are calling each other directly, or
calls are being transferred directly to other agents without using the dialed number. Default
skill group activity might indicate improper scripting to track these calls against the right
skill group.
• Historical performance of Outbound Option campaigns, including trends in number of calls
made and average talk time.
• Historical performance of Outbound Option dialer activity, including number of calls dialed,
answered, and abandoned, and whether voice, answering machine, or SITTones were detected
for the calls.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
101
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
• Historical performance of Outbound Option import activity, including the number of good
and bad record imports.
• Number of calls that are being successfully handled by VRU Self-Service applications and
the number that are transferred to agents.
• Whether the VRU activity is below or over capacity.
• Queue trends, such as number of calls that abandon while in queue and the average abandon
wait time.
The following table describes suggested IPCC Enterprise report templates that provide historical
operational statistics. For details of all IPCC Enterprise report templates, refer to the Cisco IP
Contact Center Enterprise Edition WebView Template Reference Guide.
Table 35: Report Templates for Historical Reporting
Template
Statistics Provided
perskg08: FTE for Peripheral Skill Group Half Hour
Reports on full-time equivalents for
agents logged on and in Not Ready,
Available, Active, Wrap Up, Reserved,
Hold, and Busy Other states for
half-hour intervals. Summaries on this
report provide FTE values based on an
8 hour shift calculation (Assume that
agents work an 8-hour shift).
perskg12: Outbound Option Call Detail Performance in Skill Groups Half Hour Reports on the percentage of time spent
for predictive and progressive calls by
the outbound option agents in the
signed on state, handle state, talk and
hold states, gathered in half hour
increments.
caltyp21: Call Type Half Hour
In addition to other call type data,
reports on the number of tasks offered,
number of abandoned short tasks,
number and percentage of abandoned
tasks, average abandon wait time and
service levels.
agtskg10: Outbound Option Predictive and Progressive Calls Detail Performance Reports on the Outbound Option call
detail performance on predictive and
progressive calls by skill group like
total handle time, total tasks, total talk
time, average talk time, average reserve
time.
agtskg11: Outbound Option Preview Call Detail Performance
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
102
Reports on the Outbound Option call
detail performance on preview calls by
skill group like total handle time, Total
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
Template
Statistics Provided
Tasks, total talk time, average talk time,
total reserve tasks, average reserve
time.
agtskg12: Outbound Option Reservation Call Detail Performance
Reports on the Outbound Option task
detail performance on reservation calls
by skill group like total handle time,
total number of completed agent
reservation calls, average reservation
time.
agtper27: Agent Peripheral Historical All Fields
In addition to other agent data, reports
on the number of short calls for
half-hour intervals.
camqry10: Status of Each Query Rule within a Campaign Half Hour
Reports on number of calls closed,
number of customers contacted, average
talk time, and average wrap up time for
each query in a campaign for half-hour
intervals for Outbound Option
campaigns.
camqry11: Status of All Campaigns Half Hour
Reports on number of calls closed,
number of customers contacted, average
talk time, and average wrap up time for
all Outbound campaigns for half-hour
intervals for Outbound Option
campaigns.
camqry12/13: Summary of Attempts per Campaign Half Hour/ Daily
Reports on the number of calls
attempted, closed, and rejected by the
agent, the number of calls answered and
unanswered by the customer, and the
number of calls abandoned to IVR in a
campaign for the selected time period
for Outbound Option campaigns.
camqry14/15: Breakdown of Attempts (%) per Campaign Half Hour/ Daily
Reports on the number calls not
answered, canceled, number of
customers contacted, number of calls
abandoned by the agent and abandoned
to IVR, the number of call backs
requested by the customer and the
number of contacts that encountered
network errors in a campaign for the
selected time period for Outbound
Option campaigns. This report also
provides the summary of attempts (in
percentage) for each type of result in a
campaign during the selected time
period.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
103
Chapter 5: Monitoring Operations, Configuration, and Scripting
Useful Operational, Configuration, and Scripting Statistics and Report Templates
Template
Statistics Provided
Camqry16/17: Summary of Attempts per Query Rule Within Campaign Half
Hour Report/ Daily
Reports on the number calls closed,
rejected by the agent, the number of
calls answered and not answered by the
customer, the number of calls
abandoned by the agent or abandoned
to IVR, and the total of calls attempted
for in a campaign for the selected time
period for Outbound Option campaigns.
Camqry18/19: Breakdown of Attempts (%) per Query Rule Within Campaign Reports on the number of calls canceled
Half Hour Report/ Daily
by the agent, number of calls
abandoned by the agent and abandoned
to IVR, the number of call backs
requested by the customer the number
of contacts that encountered network
errors in a campaign for the selected
time period for Outbound Option
campaigns.
camqry20/21: Campaign Consolidated Half Hour Report/ Daily
Table that shows the percentage wrap
up time, idle time, talk time, total
number of calls attempted, number of
calls closed, the average call handled
time, number of customers contacted,
the number of calls abandoned by the
agent and the number of calls
abandoned to IVR in a campaign for
the selected time period for Outbound
Option campaigns. This report
combines the campaign data with skill
group data to show how the calls are
treated for this campaign.
camqry22/23: Campaign Consolidated Detailed Half Hour Report/ Daily
Reports on the breakdown of completed
calls (outbound calls, inbound calls
and/or calls transferred to the
campaign's skill group) for the selected
campaigns and their skill groups for the
selected time period.
dialer10: Status of Each Dialer Half Hour
Reports on current number of customers
dialed, not answered, and abandoned
for half-hour intervals for Outbound
Option campaigns. Also reports on the
detection of busy, voice, answering
machine, and SITTones.
dialer11/12: Dialer Capacity Half Hour/ Daily
Reports on the number of free ports,
total number of reservation calls,
average reservation calls, average
attempt time, total time spent by the
dialer ports for reserving agents and
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
104
Chapter 5: Monitoring Operations, Configuration, and Scripting
The Role of the Default Skill Group in Reporting
Template
Statistics Provided
calling customers for the selected time
period for Outbound Option campaigns.
It also reports on the capacity and
utilization of the dialer peripherals.
imprul10: Import Rule
Reports on the number of Outbound
Option campaign imports that started,
ended, and were good and bad for the
half-hour interval.
persvc20: Peripheral Service Abandoned for IVR Queue Half Hour. There is
also a daily version of this report: persvc21.
Reports on the number of tasks offered,
number of abandoned short tasks,
number of abandoned tasks, average
abandon wait time, total abandon wait
time, service level, and number of tasks
routed to agents.
persvc22: Peripheral Service IVR Self-Service Half Hour. There is also a daily Reports on the number of tasks offered,
version of this report: persvc23.
handled, abandoned, and routed to
agents as well as the average handle
time, average abandon wait time, and
total abandon wait time for half hour
intervals.
caltyp35: VRU Call Type Analysis Half Hour. There is also a daily version of Reports on the total number of VRU
this report.
calls and, depending on whether you
have modified the VRUProgress
variables in your script, the number of
calls handled, not handled, opt out
unhandled, force transferred, script
transferred, and assisted within the
VRU Self-Service application for the
half-hour interval.
periph06: VRU Peripheral Capacity
Reports on the number of calls offered
and in progress, the maximum number
of calls in progress, and the active
routing client time for the VRU PG.
This report is not applicable in a System
IPCC or ARI environment.
The Role of the Default Skill Group in Reporting
The default skill group acts as a bucket to capture information about voice calls not routed by
IPCC routing scripts or if a skill group is not specified in a routing script. A default skill group
captures call statistics for calls that are not routed by an IPCC routing script. For example, if
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
105
Chapter 5: Monitoring Operations, Configuration, and Scripting
The Role of the Default Skill Group in Reporting
the Agent to Agent node is used in a routing script for agent to agent dialing, data is gathered
for the default skill group.
For non-voice tasks, the default skill group is also used when the Queue to Agent node is used
to queue a task to an agent if the agent is not logged into the skill group specified in the Queue
to Agent node.
Using a default skill group helps to:
• Ensure the agent/skill group reports balance with the service and call type reports, since
service and call type reports include only ICM-routed calls
• Isolate/identify non-ICM-routed calls within the agent and skill group report
You do not have to create a default skill group--it is automatically created when you establish
MRD/Peripheral Gateways pairs. The default skill group has a peripheral number of 0.
Statistics for the default skill group are affected by different types of calls, including new calls,
agent-to-agent-dialing, and transferred and conferenced calls.
If you deploy Multichannel options in an IPCC Enterprise system, default skill groups are created
for each Media Routing Domain that is configured. Refer to the Reporting in a MultiChannel
Environment (page 37) for more information bout Multichannel options.
How New Calls Increment Default Skill Group Statistics
Call statistics for all new outbound and incoming direct calls are incremented for the default
skill group as follows:
• AgentOutCalls for external outbound calls
Note: When an agent makes an outbound call as part of a consult call, the call is not attributed
to the Default Skill Group. It is attributed to the skill group for the consulting agent on the
original call.
• InternalCalls for the internal outbound calls
• InternalCallRcvd for the direct incoming calls
Note: CallsHandled is not incremented for the default skill group, since the default skill group
not be referenced in any script.
How Agent to Agent Dialing Increments the Default Skill Group Statistics
Agent-to-Agent dialing using the Agent-to-Agent node in the script also affects the default skill
group. OutgoingExternal or OutgoingInternal are incremented for the default skill group of the
agent initiating the agent-to-agent call. The default skill group InternalCallsReceived is
incremented for the default skill group of the agent receiving the agent-to-agent call.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
106
Chapter 5: Monitoring Operations, Configuration, and Scripting
Configuration and Scripting Recommendations for Default Skill Group Reporting
How Transferred and Conferenced Calls Increment the Default Skill Group
The default skill group is also affected by transferred and conferenced calls. If Agent A transfers
or conferences an ICM/IPCC routed call to another agent directly without using a script,
OutgoingExternal or OutgoingInternal for Agent A are incremented against the skill group of
the ICM-routed call. However, IncomingDirect calls for Agent B is incremented against the
default skill group.
However, if the agent (Agent A) transfers or conferences an ICM/IPCC routed call to a dialed
number that accesses a transfer or conference script that has an Agent-to-Agent node,
OutgoingExternal or OutgoingInternal for the Agent A is incremented for the skill group of the
ICM/IPCC routed call. Incoming Direct calls for agent B are incremented for the default skill
group.
The default skill group will also be incremented for emergency and supervisor assist calls when
there is no existing call.
Configuration and Scripting Recommendations for Default Skill Group Reporting
Do not reference the default skill group in ICM/IPCC routing scripts. This ensures that the
default skill group does not capture statistics for ICM-routed calls.
Reporting on Outbound Dialing Campaign Effectiveness
You can determine the effectiveness of Outbound dialing campaigns using the Outbound Option
reporting category. This category provides reports for the campaigns, the query rules used in
those campaigns, Outbound Option record imports, and Outbound Option Dialer activity.
The campaign query rule reports are the most useful reports for measuring campaign
effectiveness. These reports show you what is happening in each campaign, including the number
of calls closed, number of customers contacted, average talk time, and average wrap up time
for each query in the campaigns.
You can report on campaigns on a higher level using the dialer reports. Each campaign is
associated with a dialer. By reporting on a dialer, you view statistics that span all of the campaigns
associated with the dialer. These reports show you the number of customers dialed, the number
of calls that were not answered, the number of calls that were abandoned, and detection of busy,
voice, answering machine, and SITTones.
Outbound Option reports also enable you to view the success of record importation. Using the
import reports, you can monitor whether records being added successfully (good records) or
are failing (bad records). Also, you can monitor how long it takes to import the records so that
you can plan for future record importation.
If you want to view data for Outbound calls that are transferred to the VRU, use the peripheral
service IVR reports.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
107
Chapter 5: Monitoring Operations, Configuration, and Scripting
Configuration and Scripting Recommendations for Reporting on Outbound Dialing Campaigns
Use agent skill group reports (which are Outbound Option reports but not listed under Outbound
Option reporting category) to monitor agent talk time for Outbound Dialer calls.
Configuration and Scripting Recommendations for Reporting on Outbound Dialing Campaigns
When configuring Outbound Option, create a separate call type for Outbound Option calls.
Outbound Option uses a routing script in addition to a physical call to reserve agents, and
therefore WebView Call Type real-time and half hour reports contain data for the call type
associated with the routing script.
See Also
Outbound Option User Guide for Cisco ICM/IPCC/IPCC Enterprise & IPCC Hosted Editions
Reporting on Short Calls
A short call is a call that is either abandoned or answered and terminated very quickly. By
defining what you believe to be a short call, then you can filter out those calls that you believe
did not stay in the system long enough to be counted as a real call. Short calls can be configured
for call types, peripherals, and services. Note that for call types, you configure only abandoned
short calls; answered short calls are not reported for call types. Short calls are configured globally
for call types.
Short calls apply only to voice calls. You do not define short calls for non-voice tasks, such as
single-session chat tasks.
You can configure two types of short calls:
• Abandoned short calls
• Answered short calls (for the peripheral only). You cannot configure these for System IPCC
deployments.
If you do not want to count any abandoned calls as short calls regardless of how quickly they
abandon, you can disable abandoned short calls by leaving the Abandon Wait Time field blank
for the Call Type.
Abandoned Short Calls
A call is considered abandoned if it abandons after the value set for the Abandon Call Wait time
threshold. This is set globally. If the call abandons before the Abandon Call Wait Time threshold,
the call is reported as a short call. Abandoned short calls affect reporting because they update
the CallsOffered field, but not the CallsAbandon field. Reports contain a Short Calls column
to enable you to track calls that are offered but are neither handled nor abandoned.
Short calls can abandon at the following:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
108
Chapter 5: Monitoring Operations, Configuration, and Scripting
Reporting on Short Calls
• Call type
• VRU
• While ringing on an agent's phone
The following table describes how abandoned short calls affected reporting depending on where
they abandon.
Table 36: Abandoned Short Calls
Where Short Call Abandons
Effect on Reporting
Short call abandoned at call type The short call timer starts as soon as the route request is received for the call. The
CallsOffered field is updated when the route request is received.
If the call abandons within the Abandon Wait Time threshold, the ShortCalls field
is updated, but the number of calls abandoned is not updated. Since the call type is
the highest level reporting entity, calls that abandon at the VRU or at the agent's
phone can also be considered short calls at the call type if they abandon within the
call type's Abandon Wait Time threshold.
Short call abandoned at the VRU Calls that abandon at the VRU are calls that abandon while connected to the VRU.
The short call timer starts as soon as the call arrives at the VRU. If the call is
This does not apply for System considered a short call at the VRU service, then Callsoffered will be pegged, but not
IPCC Enterprise.
calls abandon. The short calls field will also be incremented for the VRU service.
Short calls abandoned at the
agent's phone
For calls that abandon while ringing on the agent’s phone, the short call timer starts
as soon as the call enters the queue in the ‘Queue-To-SkillGroup” node. If the call
abandons within the Abandon Wait Time threshold, the CallsOffered is incremented,
but not CallsAbandon.
Answered Short Calls - Not Applicable for System IPCC Deployments
For IPCC Enterprise, answered short calls apply to the skill group and the agent skill group.
This is the minimum amount of time that the call is connected to the agent. The short call timer
starts when the agent answers the call. CallsAnswered is updated for these calls. However, the
ShortCalls fields within the skill group and agent skill group tables are also incremented if the
Talk Time is less than the Answered short call threshold. The call is reported both as handled
and as a short call.
If auto-answer is enabled for the agent, and if there is a high number of short calls within a
certain interval, short calls could be used to determine which agents were not at their station
when a call was automatically answered. This assumes that the caller hangs up quickly when
there is no agent on the phone.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
109
Chapter 5: Monitoring Operations, Configuration, and Scripting
Configuration Recommendations for Reporting on Short Calls
Configuration Recommendations for Reporting on Short Calls
You consider both abandoned short calls and answered short calls when configuring short calls.
Configuring Abandoned Short Calls
Follow these guidelines when configuring abandoned short calls:
• Configure short calls for the call type using the ICM/IPCC configuration tools. You set this
value globally for all call types. Set the Abandon Call Wait Time to the number of seconds
that you want. If you do not want abandoned short calls to impact service level, set the value
to less than the service level threshold.
If you do not want to count any abandoned calls as short calls regardless of how quickly they
abandon, you can disable abandoned short calls by leaving the Abandon Wait Time field for
the Call Type blank.
• Configure short calls for each peripheral using the ICM/IPCC configuration tools. Set the
Abandon Call Wait Time to the number of seconds that you want. If you do not want
abandoned short calls to impact service level, set the value to less than the service level
threshold.
Configuring Answered Short Calls - Not Applicable for System IPCC Deployments
Configure answered short calls in the ICM/IPCC configuration tools when configuring the
peripheral. If you do not want answered short calls to impact Service Level, set the Answer
Short Call Threshold to a value less than your service level threshold but greater than zero.
If you do not want to count any answered calls as short calls, regardless of how quickly they
terminate, you can disable answered short calls by leaving the Answered Short Call Threshold
field blank.
Answered short calls can be configured for agent and skill groups, not for call types.
See Also
Cisco IPCC Enterprise Edition Installation and Configuration Guide
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
Determining Full-Time Equivalents and Percent Utilization
Because agents can work on multiple media and in multiple skill groups, they typically do not
spend all of their time handling tasks for a single skill group. Determining staffing needs based
on agents whose time is divided between skill groups and media can be difficult. WebView
provides two types of statistics that give you a better view of how agents are being utilized and
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
110
Chapter 5: Monitoring Operations, Configuration, and Scripting
Understanding VRU Application Reporting
how many full-time agents would be required to handle the amount of work performed during
an interval for a particular skill group.
These statistics are:
• % Utilization (percent utilization)
• FTE (full-time equivalent)
You can use these statistics when determining staffing requirements for the contact center and
individual skill groups.
Percent utilization (% Utilization in reports) is computed in WebView by dividing the total time
agents spend handling calls in a skill group by the total time agents were ready to handle tasks,
based on an 8 hour shift. To calculate the time that an agent was ready, WebView subtracts the
Not Ready time from the total time that agents were logged on. Percent utilization shows you
how well agents are being utilized within a skill group. For example, if the agent spent 20
minutes of the log on duration handling calls and was available to handle calls for 40 minutes,
the percent utilization is 50%.
The full-time equivalent (FTE in reports) is the number of full-time agents that would be required
to perform the work done during that interval for a skill group. To calculate the FTE, WebView
divides the total time that work was performed by the total time in the interval. For example, if
agents spent a total of 3 hours (180 minutes) handling tasks during a half-hour interval (30
minutes), the FTE for task handling during the interval is 180 minutes/30 minutes, which equals
6 full-time persons. This means that if all agents handled tasks full-time, the work could have
been done by 6 agents.
Reports also provide FTE values based on an 8 hour shift calculation. It is assumed that agents
work an 8 hour shift for the day. To calculate the FTE, Webview divides the total time that work
was performed by 8 hours. For example, if agents spent a total of 48 hours (2880 minutes)
handling tasks during an 8 hour work shift (480 minutes), the FTE for task handling during the
interval is 2880 minutes/480 minutes, which equals 6 full-time persons. This means that if all
agents handled tasks full-time, the work could have been done by 6 agents.
Note: If you select a report interval that is less than 8 hours, the value will be lower than expected.
Understanding VRU Application Reporting
You can use a VRU in IPCC Enterprise for a number of different purposes, including queuing,
customer self-service, and information gathering.
You can identify the VRU service by the Peripheral Number field in the Service database tables
as follows. VRU services are not applicable for System IPCC or ARI deployments. For System
IPCC and ARI, use skill group reports to view queuing metrics.
• If you are using IP-IVR as the VRU, the Peripheral Number of the service matches the
ICM/IPCC post routing ID set in the CRA Application Administration for IP-IVR.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
111
Chapter 5: Monitoring Operations, Configuration, and Scripting
Understanding VRU Application Reporting
• If you are using CVP as the VRU, the Peripheral Number of the service is 1 if the CVP is
the routing client (VRU type 5) or 2 if the CVP receives pre-routed calls (VRU type 2, 3, 7,
and 8).
• For both CVP and IP-IVR, if you are performing translation routes from the CTI route point
to the VRU, the VRU service is the service defined in the TranslationRtetoVRU script node.
Self-Service, Information Gathering, and Queuing VRU Applications
VRU applications include Self-Service, Information Gathering, and queuing.
A self-service application is designed for callers to obtain routine information using VRU menu
options. Only for exceptional cases would the call be routed to an agent.
You must be able to determine the following from an IVR service used for customer self-service:
• How many calls traversed the application
• How long each call remained in the self-service application
• How many calls did not require agent intervention
• How many calls were eventually routed to agents
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 to ICM/IPCC from the VRU to be used within the ICM/IPCC routing script, to
decide the optimal skill group to answer the call.
You must be able to determine the following from an IVR 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 using the Requalify or Call Type node. In the following script, the call type is changed
using the Call Type node once it has been queued to separate Information Gathering
(CollectDigits) and queuing.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
112
Chapter 5: Monitoring Operations, Configuration, and Scripting
Understanding VRU Application Reporting
Figure 7: Sample Routing Script for Information Gathering and Queuing
Although a service level can be defined for both call types, it is better 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 Queue reporting. 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, you will only be able to see in reports 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 is used to calculate ASA and to decide the service level—and not
50 seconds (30+20 seconds).
Figure 8: Call Type Data for Calls that Abandon after Call Type is Changed
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
113
Chapter 5: Monitoring Operations, Configuration, and Scripting
Understanding VRU Application Reporting
Note that 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 9: Call Type Data for Calls that Abandon before Call Type is Changed
The following table illustrates how some basic metrics are broken up at the CallType and the
IVR Service.
Table 37: Self-Service and Information Gathering Application Metrics
Report Metric
Call Type
VRU Service
Skill Group
Not applicable for System IPCC
deployments or ARI.
Abandon Wait Time Starts when a call first enters a call Starts when the call enters the
type and ends when it abandons. service.
Average Speed of
Answer (ASA)
Starts at the first Queue to Skill
Group node in the routing script.
Service Level
Starts as soon as the call enters the Starts when the call enters the
call type that has the service level service.
defined.
Not Applicable
Starts at the first Queue to Skill Starts at the first Queue
Group node in the routing script. to Skill Group node in
the routing script.
Not Applicable
Measuring VRU Utilization - Not Applicable for System IPCC or ARI Enterprise Deployments
You can monitor the number of calls that are being handled by VRU services using the periph06:
VRU Peripheral Capacity WebView report.
This report provide metrics including:
• Number of calls offered to the VRU.
• Average number of calls serviced by the VRU simultaneously.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
114
Chapter 5: Monitoring Operations, Configuration, and Scripting
Determining Self-Service Application and Information Gathering Application Effectiveness
• Maximum number of calls in progress simultaneously.
If you are using CVP as the VRU and have deployed CVP in the Comprehensive Model,
note that the number of calls in progress refers to the number of Routing Client ports and the
number of VRU ports in use on this peripheral. See the Cisco Internet Service Node (CVP)
Configuration and Administration Guide for more information about the Comprehensive
Model.
• Amount of time that the VRU peripheral has been sending data.
• Amount of time that the VRU peripheral has been active as a routing client.
You can use the data in this report to determine if the VRU is capable of handling the amount
of calls it is receiving or if the VRU is not being utilized effectively by your routing scripts.
Determining Self-Service Application and Information Gathering Application Effectiveness
You can monitor the effectiveness of Self-Service and Information Gathering applications to
determine whether the application needs to be modified to better meet customer needs and
decrease the amount of agent intervention.
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.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
115
Chapter 5: Monitoring Operations, Configuration, and Scripting
Determining Self-Service Application and Information Gathering Application Effectiveness
You can obtain information about application effectiveness a whole, effectiveness of individual
transactions within the application, and failure cases using the VRUProgress variable available
in the Set script node. The VRUProgress variable enables to you set the status of the VRU call
at any point in the application. For example, if you consider a call handled by the VRU when
the caller completes a certain node, such as an account balance lookup node, then you can set
the variable to 2, indicating that the call be reported as VRU Handled for the appropriate call
type.
These VRUProgress variables map to columns that appear in VRU Activity WebView reports,
enabling you to see how many calls were counted for each variable per call type. You can use
this data to modify applications if needed. For example, if you see that many callers are
experiencing error conditions that cause a forced transfer you could correct the function of that
node. If you see that many callers are opting to be transferred to an agent before being handled
by the application, you might want to add functionality to the application.
The following table describes the VRUProgress variables that you can use in your VRU script
applications and how they map to report columns.
Table 38: VRUProgress Script Variable
Variable
Setting in
Script
Show in Reports as
Description
0
Not a VRU call - does not Indicates that this call is not a VRU call. It is the default value.
appear in reports
1
VRU Unhandled
Indicates that the caller's needs have not been met at this point in the
application.
2
VRU Handled
Indicates that the caller's needs have been met by this point in the application.
For example, the caller successfully received an account balance.
3
VRU Assisted
Indicates that this call was transferred to an agent after the caller's needs were
met with the application. For example, the caller successfully received account
information and then requested to speak to an agent for a different reason or
for additional information not available through automatic means.
4
VRU Opt Out Unhandled Indicates that the call was transferred to an agent at the caller's request before
the caller's needs were met by the application. For example, the caller pressed
"0" to be transferred to an agent before performing automated transactions
or while in the process of completing a transaction.
5
VRU Scripted Transfer
Indicates that the call was transferred to an agent as part of the application
design. For example, after the caller checked an account balance the
application transferred the caller to agent to discuss new account options.
Another example is that after a caller entered digits to request a particular
type of service the call was transferred to an available agent to handle the
request.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
116
Chapter 5: Monitoring Operations, Configuration, and Scripting
Determining Self-Service Application and Information Gathering Application Effectiveness
Variable
Setting in
Script
Show in Reports as
Description
6
VRU Forced Transfer
Indicates that the caller was transferred to an agent because of a system error.
For example, a failure at a particular node in the application could lead to the
call being transferred to the agent.
7
VRU Other
Indicates that the call disposition does not match any of the other
VRUProgress variables.
You can use the VRUProgress variable to indicate the final VRU status at the end of the
application or to indicate changes in VRU status through the different transactions in the
application.
The VRUProgress variable is associated with a specific call type. If you want to report only the
final status of the call, then you can use a single call type in the application and set the
VRUProgress variable at any point in the application. Note that while you can change the
VRUProgress variable throughout the application, only the final status is reported for the call
type. The value of the VRUProgress variable is written to the database when the routing script
terminates. You can report on the VRU status of the application as a whole using the Call Type
VRU Activity WebView reports by monitoring statistics for the call type associated with the
script.
If you want to report on individual transactions within the application, change the VRUProgress
variable and then the call type at the end of each transaction. You have a different call type for
each transaction with a related VRUProgress variable. This ensures that the value of the
VRUProgress variable is captured for that particular transaction, not just at the end of the routing
script. The value is written to the database for the call type associated with that transaction when
the call types changes. You can report on individual transactions using the Call Type VRU
Progress WebView reports by monitoring statistics for the call types associated with those
transactions.
See IPCC Enterprise Voice Call Reporting Data (page 125) for a sample script and call flow for
Self-Service and Information Gathering applications that use the VRUProgress variable.
Capturing Script Application Data (CVP only)
If you have deployed CVP as the VRU in your IPCC Enterprise system, you can use two
advanced features to gather additional details about calls' progress through Self-Service and
Information Gathering applications: Capture microapplication and metadata ECC variable. The
details provided by these microapplications can be used only in custom reports; standard
WebView 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, router call keys, date and time, caller entered digits, and metadata ECC variables.
The metadata ECC variable captures high level details about a call's progress through a script,
including whether the caller is using voice or digit dialing, percent confidence for Automatic
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
117
Chapter 5: Monitoring Operations, Configuration, and Scripting
Configuration and Scripting Recommendations for Self-Service Applications, Information Gathering Applications, and Queue Applications
Reporting
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,
you must configure the ECC variables in the ICM/IPCC configuration tools.
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 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 he or she encountered difficulties.
Configuration and Scripting Recommendations for Self-Service Applications, Information
Gathering Applications, and Queue Applications Reporting
Follow these guidelines when configuring Self-Service applications, Information Gathering
applications, and queue applications:
• Enable Service Control and Queue Reporting at the VRU peripheral. This does not apply to
System IPCC or ARI Enterprise deployments.
• If you have Self-Service or Information Gathering IVR applications and want to separate
self-service/digit collection metrics from queuing metrics, change the call type in the routing
script before the call is queued. This 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.
• If you want to track a call's progress through a Self-service or Information Gathering IVR
Application, 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. Use the VRU Activity reports
to view how caller's are progressing through the VRU 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 enables you to report on each transaction separately using the call type VRU
Activity reports.
• Optionally, if you are using CVP as your VRU and want to perform advanced custom reporting
on VRU application details, configure the following:
– 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
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
118
Chapter 5: Monitoring Operations, Configuration, and Scripting
Translation Route Reporting
VRU script; execute the application using the RunExternalScript node. You must name
the script "CAP" or "CAP, xxx", where xxx is any string that makes the script name unique.
(For example CAP, bankingApplication).
– Metadata ECC variable microapplication, which collects high-level details about the script
application. Configure an ECC variable in ICM/IPCC Expanded Call Center Variables
configuration tool. The variable length normally be 62 bytes but can be as low as 21 bytes
to save space if needed.
– Use these microapplications in your scripts to trigger TCD creation at points in the script
for which you want to capture data, such as when a transaction completion. Using the
metadata ECC variable in conjunction with the Capture microapplication enables you to
capture additional details 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 (using
the LAA Select node) from the VRU. You must ensure the VRU PG is configured correctly
to ensure that such a call is considered answered at the VRU service rather than abandoned.
• 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.
See Also
IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
System IPCC Installation and Configuration Guide for Cisco IPCC Enterprise Edition
ICM Scripting and Media Routing Guide for Cisco ICM/IPCC Enterprise & Hosted Editions
Translation Route Reporting
Translation routes are used to transfer a call from one routing client to another and retain the
details about call tracking, call data and cradle to grave reporting. They form an intermediate
destination which is allocated when a script sends a call from a source routing client to a
destination. After the call reaches the destination, the translation route is available for reuse as
the route is not busy for the entire duration of the call.
Translation routes use a 'pool' of DNIS's . These DNIS serve as the intermediate targets of the
calls on each possible destination. For any given translation route, one pool is used. The size
of this pool is set by using a formula defined in the ICM documentation. If the pool is too large,
ACD or VRU resources are wasted (These numbers are PSTN exposed). If the pool is too small,
few calls are lost as these calls cannot be sent when the entire pool is in use.
The following table describes the new IPCC Translation Route report templates which are
used to track the route usage and/or the overflow conditions:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
119
Chapter 5: Monitoring Operations, Configuration, and Scripting
Translation Route Reporting
Table 39: Report Templates for Historical Reporting
Template
Statistics Provided
trroute11/trroute12: Translation Route Reports on the maximum number of routes used in a translation route, average
Counts Half Hour Report/ Daily Report and maximum time taken to complete a translation route, the average number
of routes in use, the number of PG time-outs, the number of configuration errors
encountered during the translation route and the number of translation routes
occurred during the selected time period.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
120
Chapter 6
Implications of Fail-over for Reporting
System fail-over affects data that appears in IPCC WebView reports.
This section describes the effects on reporting when the following system components fail-over
• Peripheral Gateway/CTI Manager Service
• Agent Desktop/CTI OS Server
• Cisco CallManager
• Application Instance/MR PG
• Application Instance/ Agent PG CTI Server/PIM
This chapter contains the following topics:
•
•
•
•
•
About Peripheral Gateway/CTI Manager Service Fail-over, page 121
About Agent Desktop/CTI OS Server Fail-over, page 122
About Cisco CallManager Fail-over, page 123
About Application Instance/MR PG Fail-over, page 123
About Application Instance/Agent PG CTI Server/ PIM Fail-over, page 124
About Peripheral Gateway/CTI Manager Service Fail-over
If the agent’s PG (PIM or JTAPI Gateway components on the Cisco CallManager PG) shuts
down or the CTI Manager service on CallManager shuts down, the agent is momentarily logged
out. The agent might be logged in again automatically once the backup PG or CTI Manager
comes into service. The agent Media Logout Status reports for the agent, agent skill group,
agent team, and agent peripheral show a logout reason code of 50002.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
121
Chapter 6: Implications of Fail-over for Reporting
About Agent Desktop/CTI OS Server Fail-over
Table 40: Agent State Before and After Peripheral Gateway/CTI Manager Service Fail-over
Agent State at Fail-Over
Agent State after Fail-over
Available
Available
Not Ready
Not Ready
Wrap-up
Available, if in Available state before the call. Otherwise, the agent
reverts to Not Ready.
About Agent Desktop/CTI OS Server Fail-over
If the agent desktop (CTI OS or Cisco Agent Desktop) shuts down or loses communication with
CTI OS Server, or if the CTI OS Server shuts down, the agent is logged out all Media Routing
Domains supported by the peripheral that has lost communication with ICM/IPCC software.
The agent is logged in again automatically when one of the following occurs:
• The agent desktop comes back up or resumes communication with CTI OS Server
• The agent is connected to the backup CTI OS server
The agent Media Logout Status reports for the agent, agent skill group, agent team, and agent
peripheral show a logout reason code of 50002.
The state to which the agent reverts after fail-over depends on the agent's state when the fail-over
occurred, as described in the following table.
Table 41: Agent State Before and After Agent Desktop/CTI OS Server Fail-over
Agent State at Fail-Over
Agent State after Fail-over
Available
Available
Not Ready
Not Ready
Reserved
Available
Wrap-up
Available, if in Available state before the call. Otherwise, the agent
reverts to Not Ready.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
122
Chapter 6: Implications of Fail-over for Reporting
About Cisco CallManager Fail-over
About Cisco CallManager Fail-over
If a Cisco CallManager that is not directly connected to the agent’s phone shuts down, the agent
is not affected. However, if the agent’s phone loses connectivity with its Cisco CallManager
(because either its Cisco CallManager went down or the agent’s phone restarted) or if there are
network problems between the agent’s phone and its Cisco CallManager, the agent is logged
out automatically. The agent must manually log in again once the phone has connected to the
back up Cisco CallManager.
When the agent is logged out, the agent is removed from the real-time status reports until the
agent logs back in again. The historical information restarts when the agent logs back in again.
The agent Media Logout Status reports for the agent, agent skill group, agent team, and agent
peripheral show a logout reason code of 50003. The previous state that the agent was in before
the fail-over or recovery condition is not maintained.
If the agent is on a call when this fail-over or recovery condition occurs, the agent does not
fail-over or revert to the back up or primary Cisco CallManager until the call is disconnected.
The agent might be able to stay on the call, but does not get credit for that call within the historical
reports because signaling to the PG stops until the agent fails-over or reverts to the back up or
primary Cisco CallManager. Once the agent has connected to its back up CallManager, the
agent must log in again. The previous state that the agent was in before the fail-over or recovery
condition is not maintained.
About Application Instance/MR PG Fail-over
If the connection between the Application Instance and MR PG shuts down or either component
shuts down, the ICM/IPCC Central Controller discards all pending NEW_TASK requests
received from the application. The Application Instance waits for the connection to be restored
and continues to send messages regarding existing tasks and new tasks assigned by the
Application Instance to the Agent PG CTI server. When the connection, MR PIM, or Application
Instance is restored, the Application Instance resends any pending NEW_TASK requests for
which it has not received a response from the ICM/IPCC Central Controller. The tasks that are
assigned to the agent by the Application Instance while the connection is down and completed
before the connection is restored do not appear in WebView reports.
Note: If the Application Instance shuts down, this also affects Agent PG CTI server connections.
If the connection between the MR PIM and the ICM/IPCC Central Controller shuts down or
the ICM/IPCC Central Controller shuts down, the MR PIM sends a ROUTING_DISABLED
message to the Application Instance that causes the Application Instance to stop sending routing
requests to the ICM/IPCC Central Controller. Any request that is sent while the connection is
down is rejected with a NEW_TASK_FAILURE message. The Application Instance continues
to send messages regarding existing tasks and new tasks assigned by the Application Instance
to the Agent PG CTI server. When the connection or ICM/IPCC Central Controller is restored,
the MR PIM sends the Application Instance a ROUTING_ENABLED message that causes the
Application Instance to start sending routing requests to the ICM/IPCC Central Controller again.
The tasks that are assigned to the agent by the Application Instance while the connection is
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
123
Chapter 6: Implications of Fail-over for Reporting
About Application Instance/Agent PG CTI Server/ PIM Fail-over
down and completed before the connection is restored do not appear in reports. If the connection
between the ICM/IPCC Central Controller and the MR PG fails, the ICM/IPCC router deletes
all pending new tasks. When the connection is restored, the application connected to MR PG
will resubmit all the tasks.
Note: If the ICM/IPCC Central Controller shuts down, this also affects the application instance/
Agent PG CTI server interface.
About Application Instance/Agent PG CTI Server/ PIM Fail-over
If the connection between the Application Instance and Agent PG CTI server shuts down or
either component shuts down, agents stay logged in. Tasks remain for a time, based on the task
life attribute of the MRD. If the task life expires while the connection is down, tasks are
terminated with the disposition code of 42 (DBCD_APPLICATION_PATH_WENT_DOWN).
Note: For the E-Mail MRD, agents are not logged out automatically when the Agent PG CTI
server or connection to CTI server shuts down. Instead the E-Mail Manager continues to record
agent state and assign tasks to agents. When the connection is restored, the E-Mail Manager
sends the updated agent state information on the peripherals serviced by the Agent PG CTI
server to the CTI server, which sends the information to ICM/IPCC software. ICM/IPCC software
attempts to recreate historical data and corrects current agent state. If the connection or Agent
PG CTI server is down for more than the time limit configured for the MRD, reporting on tasks
might be ended prematurely by ICM/IPCC software and restarted with the connection is
reestablished
The application instance can assign tasks to agents while the connection or CTI server is down
and, if the connection to the MR PG is up, can continue to send routing requests to the ICM/IPCC
central controller and receive routing instructions. However, no reporting data is stored for the
tasks while the connection is down. Also, any tasks that are assigned and completed while the
connection or CTI server is down do not appear in reports. If the connection between the Agent
PG CTI server and the router shuts down or if the router shuts down, the application instance
continues to send messages to the CTI server and agent activity is tracked. However, this
information is not sent to the router until the connection or the router is restored, at which time
the cached reporting information is sent to the ICM/IPCC central controller.
Note: If the ICM/IPCC central controller shuts down, this also affects the application instance/MR
PG interface.
If the Cisco CallManager PIM shuts down, voice media routing is unavailable for agents
associated with the PIM. However, the ICM/IPCC Central Controller can continue to assign
non-voice tasks to agents associated with the PIM, and the CTI server can continue to process
messages and requests about agents associated with the PIM for non-voice Media Routing
Domains. When the connection is restored, voice media routing is available again.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
124
Chapter 7
Sample Calls and Report Data
This section describes sample voice calls and the historical report fields for several templates
that are updated for these calls. For each call, the routing script is provided.
IPCC Enterprise Voice Call Reporting Data
This section provides sample call flows in the IPCC Enterprise system and the report data
generated for agent, skill group, and call type reports.
For these call flows, the following settings are configured for IPCC Enterprise:
• Service Level threshold for services is 90 seconds; abandoned calls impact Service Level
negatively.
• Service Level threshold for call types is 90 seconds; abandoned calls impact Service Level
negatively.
• Service Level threshold for skill groups is 90 seconds; abandoned calls impact Service Level
negatively.
• Ring No Answer time is set to 20 seconds in the Agent Desk Settings.
• Four call type intervals are set:
– Upper bound 1 is set to 60 seconds
– Upper bound 2 is set to 90 seconds
– Upper bound 3 is set to 120 seconds
– Upper bound 4 is set to 150 seconds
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
125
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
• The predefined Not Ready reason codes have been entered in the Reason Code List Tool and
associated with text. The text for Not Reason Code 32767 is "Ring No Answer".
Voice Call without Queuing
The following script is used for this example:
Figure 10: Routing Script for Voice Call without Queuing
Note: For IPCC Enterprise with System IPCC PG and System IPCC deployments, the Translation
Route to VRU node is not needed.
In this example, the script first tries to select an available agent using the LAA (Longest Available
Node) from the appropriate skill groups. If an agent is not available, the script then performs a
translation route to VRU and queues the call to the appropriate skill groups. During queuing,
the VRU plays music on hold. Labels are used for default routing in case the Translation Route
to VRU, Queue to Skill Group, or Run Ext. Script nodes fail.
The following events occur:
1. A customer calls the contact center at 9:05:01 a.m.
2. The script uses the LAA (longest available agent) node to select an available agent.
3. The agent's phone rings at 9:05:05 a.m.
4. The agent answers the phone at 9:05:10 a.m.
5. The caller hangs up at 9:16:03 a.m.
6. The agent enters wrap up and completes wrap up at 9:20:04 a.m
For this call flow, all events occur within the 09:00:00 to 09:29:59 reporting interval. Reports
run from 09:00:00 to 09:29:59 display all of the data for this call.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
126
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Table 42: Sample Agent Reports
Agent Report
Fields Affected by Call Flow
agent04: Agent Task Detail
Report
This call affects the following fields:
• Tasks Handled: Total Tasks. This field is incremented.
• Tasks Handled: Avg Time. The handle time for call is used in the calculation.
• % Wrap Up. The agent's wrap up time for this call is used in the calculation.
agent25: Agent Consolidated
Half Hour Report
This call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is
used in the calculation.
• Agent State Times: % Active Time. The agent's active time for call is used in the
calculation.
• Agent State Times: % Wrap Up. The agent's wrap up time for call is used in the
calculation.
Table 43: Sample Skill Group Reports
Skill Group Report
Fields Affected by Call Flow
perskg31: IPCC Peripheral Skill This call affects the following fields:
Group Task Summary Half Hour
• Completed Tasks: Handled. This field is incremented.
Report
• Completed Tasks: % Handled. This call is used in the calculation.
• Completed Tasks: Total. This field is incremented.
perskg35: IPC Peripheral Skill
Group Consolidated Half Hour
Report
This call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: AHT. The handle time for this call is used in the calculation.
• Completed Tasks: Avg Active Time. The agent's active time for this call is used
in the calculation.
• Agent State Times: Active Time. The active time is displayed (10 minutes and 53
seconds).
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
127
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Skill Group Report
Fields Affected by Call Flow
• Agent State Times: % Active Time. The agent's active time for this call is used in
the calculation.
• Agent State Times: % Reserved Time. The agent's reserved time for this call is
used in the calculation.
• Agent State Times: % Wrap Up Time. The agent's wrap up time for this call is
used in the calculation.
• ASA. This call is used in the Average Speed of Answer calculation.
Table 44: Sample Call Type Reports
Call Type Report
Fields Affected by Call Flow
caltyp05: Analysis of Calls Half Hour The Tasks Routed field is incremented for this call.
Report
caltyp21: Call Type Half Hour Report This call affects the following fields
• Service Level. This call is used in the Service Level calculation. Because the
call was answered within the service level threshold, it affects the Service
Level positively.
• ASA. This call is used in the Average Speed of Answer calculation.
• Tasks: Offered. This field is incremented.
• Tasks: Answered. This field is incremented.
• Tasks: Answer Wait Time. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
caltyp31: Call Type Abandon/Answer This call affects the following fields
Distribution by Half Hour Report
• ASA. This call is used in the Average Speed of Answer calculation.
• 00:00:00 - 00:01:00: Ans. This field is incremented.
Voice Call with Queuing
The following script is used for this example:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
128
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Figure 11: Routing Script for Voice Call with Queuing
Note: For IPCC Enterprise with System IPCC PG and System IPCC deployments, the Translation
Route to VRU node is not needed.
In this script, the script first tries to select an available agent using the LAA (Longest Available
Node) from the appropriate skill groups. If an agent is not available, the script then performs a
translation route to VRU and queues the call to the appropriate skill groups. During queuing,
the VRU plays music on hold. Labels are used for default routing in case the Translation Route
to VRU, Queue to Skill Group, or Run Ext. Script nodes fail.
The following events occur:
1. A customer calls the contact center at 9:05:07 a.m.
2. An agent is not available. The script uses the Transfer to IVR node and then the Queue to
Skill Group node to queue the call to the appropriate skill group.
3. An agent becomes available at 9:11:13 a.m.
4. The call is assigned to the agent.
The agent answers the phone at 9:11:17 a.m.
5. The caller hands up at 9:27:01 a.m.
6. The agent enters wrap up and completes wrap up at 9:29:25 a.m.
For this call flow, all events occur within the 09:00:00 to 09:29:59 reporting interval. Reports
run from 09:00:00 to 09:29:59 display all of the data for this call.
Table 45: Sample Agent Reports
Agent Report
Fields Affected by Call Flow
agent04: Agent Task Detail
Report
This call affects the following fields:
• Tasks Handled: Total Tasks. This field is incremented.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
129
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Agent Report
Fields Affected by Call Flow
• Tasks Handled: Avg Time. The handle time for call is used in the calculation.
• % Wrap Up. The agent's wrap up time for this call is used in the calculation.
agent25: Agent Consolidated
Half Hour Report
This call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is
used in the calculation.
• Agent State Times: % Active Time. The agent's active time for call is used in the
calculation.
• Agent State Times: % Wrap Up. The agent's wrap up time for call is used in the
calculation.
Table 46: Sample Skill Group Reports
Skill Group Report
Fields Affected by Call Flow
perskg31: IPCC Peripheral Skill This call affects the following fields:
Group Task Summary Half Hour
• Queued. This field is incremented.
Report
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Handled. This call is used in the calculation.
• Completed Tasks: Total. This field is incremented.
perskg35: IPCC Peripheral Skill This call affects the following fields
Group Consolidated Half Hour
• Queued. This field is incremented.
Report
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: AHT. The handle time for this call is used in the calculation.
• Completed Tasks: Avg Active Time. The agent's active time for this call is used in
the calculation.
• Agent State Times: Active Time. The active time is displayed (15 minutes 46
seconds).
• Agent State Times: % Active Time. The agent's active time for this call is used in
the calculation.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
130
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Skill Group Report
Fields Affected by Call Flow
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used
in the calculation.
• Agent State Times: % Wrap Up Time. The agent's wrap up time for this call is used
in the calculation.
• ASA. This call is used in the Average Speed of Answer calculation.
Table 47: Sample Call Type Reports
Call Type Report
Fields Affected by Call Flow
caltyp05: Analysis of Calls
Half Hour Report
This call affects the following fields
• Tasks Routed. This field is incremented.
• Assigned from Queue. This field is incremented.
• Avg Wait Time in Queue. This call is used in the calculation.
caltyp21: Call Type Half Hour This call affects the following fields
Report
• Service Level. This call is used in the Service Level calculation. Because the call was
not answered within the service level threshold, it affects the Service Level negatively.
• ASA. This call is used in the Average Speed of Answer calculation.
• Tasks: Offered. This field is incremented.
• Tasks: Answered. This field is incremented.
• Tasks: Answer Wait Time. This field is incremented.
• Tasks: Assigned from Queue. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
Table 48: Sample VRU Service Reports - Not Applicable for System IPCC or ARI
Service Report
Fields Affected by Call Flow
persvc20: Peripheral Service for IVR This call affects the following fields:
Queue Half Hour Report
• Tasks Offered. This field is incremented.
• Service Level. This call is used in the Service Level calculation. Because the
call was not answered within the service level threshold, it affects the Service
Level negatively.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
131
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Service Report
Fields Affected by Call Flow
• Tasks Routed. This field is incremented.
Voice Call with Agent Consultative Transfer
The following script is used for the consultative transfer in this example:
Figure 12: Routing Script for Voice Call without Queuing
Note: For IPCC Enterprise with System IPCC PG and System IPCC deployments, the Translation
Route to VRU node is not needed.
In this script, the script first tries to select an available agent for the consultative transfer using
the LAA (Longest Available Node) from the appropriate skill groups. If an agent is not available,
the script then performs a translation route to VRU and queues the agent's call to the appropriate
skill groups. During queuing, the VRU plays music on hold. Labels are used for default routing
in case the Translation Route to VRU, Queue to Skill Group, or Run Ext. Script nodes fail.
The following events occur:
1. A customer calls the contact center at 9:05:09 a.m.
2. The script uses the LAA (longest available agent) node to select an available agent.
3. The agent's phone rings.
4. The agent answers the phone at 9:05:11 a.m.
5. The agent decides that the caller needs to be transferred to a different agent.
6. The agent puts the caller on hold at 9:10:53 a.m.
7. The agent presses the consult button on the desktop and enters the dialed number for the
skill group.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
132
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
8. The dialed number is associated with a call type for transfer and conference. The call type
invokes a routing script that uses the LAA node to select an available agent in that skill
group.
9. The second agent answers the call at 9:11:02 a.m. and consult with the first agent.
10. The first agent transfers the call to the second agent at 9:22:46 a.m.
11. The second agent talks to the caller and ends the call at 9:32 a.m.
12. The second agent enters wrap up and completes wrap up at 9:40:14 a.m.
For this call flow, events occur within the 09:00:00 to 09:29:59 reporting interval and the
09:30:00 to 09:59:59 reporting interval. Reports run from 09:00:00 to 09:59:59 display all of
the data for this call.
Table 49: Sample Agent Reports
Agent Report
Fields Affected by Call Flow
agent04: Agent Task
Detail Report
For both Agent 1 and Agent 2, this call affects the following fields:
• Tasks Handled: Total Tasks. This field is incremented.
• Tasks Handled: Avg Time. The handle time for call is used in the calculation.
• % Wrap Up. The agent's wrap up time for this call is used in the calculation.
agent25: Agent
Consolidated Half Hour
Report
For Agent 1, this call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Transfer Out. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Active Time. The agent's active time for call is used in the
calculation.
• Agent State Times: % Wrap Up. The agent's wrap up time for call is used in the calculation.
For Agent 2, this call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Transfer In. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is used in
the calculation.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
133
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Agent Report
Fields Affected by Call Flow
• Agent State Times: % Active Time. The agent's active time for call is used in the
calculation.
• Agent State Times: % Wrap Up. The agent's wrap up time for call is used in the calculation.
Table 50: Sample Skill Group Reports
Skill Group Report
Fields Affected by Call Flow
perskg31: IPCC
Peripheral Skill Group
Task Summary Half
Hour Report
For Agent 1's skill group, this call affects the following fields:
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Handled. This call is used in the calculation.
• Completed Tasks: Total. This field is incremented.
• Transfer Out. This field is incremented.
For Agent 2's skill group 2, this call affects the following fields:
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Handled. This call is used in the calculation.
• Completed Tasks: Total. This field is incremented.
• Transfer In. This field is incremented.
perskg35: IPCC
For Agent 1's skill group 1, this call affects the following fields
Peripheral Skill Group
Consolidated Half Hour • Completed Tasks: Handled. This field is incremented.
Report
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: AHT. The handle time for this call is used in the calculation.
• Transfer Out. This field is incremented.
• Completed Tasks: Avg Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: Active Time. The active time for this call is included in this value.
• Agent State Times: % Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used in the
calculation.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
134
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Skill Group Report
Fields Affected by Call Flow
• Agent State Times: % Wrap Up Time. The agent's wrap up time for this call is used in the
calculation.
For Agent 2's skill group, this call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: AHT. The handle time for this call is used in the calculation.
• Transfer In. This field is incremented.
• Completed Tasks: Avg Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: Active Time. The active time for this call is included in this value.
• Agent State Times: % Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used in the
calculation.
• Agent State Times: % Wrap Up Time. The agent's wrap up time for this call is used in the
calculation.
• ASA. This call is used in the Average Speed of Answer calculation.
Table 51: Sample Call Type Reports
Call Type Report
Fields Affected by Call Flow
caltyp05: Analysis of Calls Half
Hour Report
For both the original call type and the transfer and conference call type, the Tasks
Routed field is incremented.
caltyp21: Call Type Half Hour
Report
For both the original call type and the transfer and conference call type, this call
affects the following fields
• Service Level. This call is used in the Service Level calculation. Because the call
was answered within the service level threshold, it affects the Service Level
positively.
• ASA. This call is used in the Average Speed of Answer calculation.
• Tasks: Offered. This field is incremented.
• Tasks: Answered. This field is incremented.
• Tasks: Answer Wait Time. This field is incremented.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
135
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Call Type Report
Fields Affected by Call Flow
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
caltyp31: Call Type
For both the original call type and the transfer and conference call type, this call
Abandon/Answer Distribution by affects the following fields
Half Hour Report
• ASA. This call is used in the Average Speed of Answer calculation.
• 00:00:00 - 00:01:00: Ans. This field is incremented.
Voice Call with Redirection on No Answer with IP-IVR
The following scripts are is used when the call Redirects on No Answer.
Initial script:
Figure 13: Routing Script for Redirection on No Answer with IP-IVR
Script used when call Redirects on No Answer:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
136
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Figure 14: Routing Script for Redirection on No Answer with IP-IVR
The second script is associated with the Redirection on No Answer Call Type and is run when
an agent does not answer a call within the ring no answer time specified in Agent Desk Settings.
The script performs a translation route to VRU and queues the agent's call to the appropriate
skill groups at a higher priority. During queuing, the VRU plays music on hold. Labels are used
for default routing in case the Translation Route to VRU, Queue to Skill Group, or Run Ext.
Script nodes fail.
The following events occur:
1. Call enters script at 4:03:01 p.m.
2. Call is transferred to the IVR and queued using the Queue to Skill Group node.
3. An agent becomes available at 4:04:04 p.m.
4. The call is assigned to the agent. The call rings on the agent desktop. The ring time exceeds
agent desk settings. The agent is made Not Ready with a reason code 32767 (Ring No
Answer).
5. The router runs the routing script associated with the call type for the ring no answer dialed
number. The script attempts to select the first available agent from a skill group.
6. No agents are ready, so the script performs a transfer to IVR and then uses Queue to Skill
Group node to queue to Skill Group 2. The call begins to queue at 4:04:05 p.m.
7. Agent 2 becomes Ready at 4:05:02 p.m.
8. The call is assigned to the agent and rings on the agent's desktop.
9. The agent answers call at 4:05:04 p.m.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
137
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
10. The caller ends the call at 4:10:37 p.m.
11. The agent performs Wrap up work until 4:12:59 p.m.
For this call flow, events occur within the 16:00:00 to 16:29:59 reporting interval. Reports run
from 16:00:00 to 16:29:59 display all of the data for this call.
Table 52: Sample Agent Reports
Agent Report
Fields Affected by Call Flow
agent04: Agent Task Detail For Agent 1, this call does not affect any fields.
Report
For Agent 2, this call affects the following fields:
• Tasks Handled: Total Tasks. This field is incremented.
• Tasks Handled: Avg Time. The handle time for call is used in the calculation.
• % Wrap Up. The agent's wrap up time for this call is used in the calculation.
agent25: Agent
Consolidated Half Hour
Report
For Agent 1, this call affects the following fields
• Completed Tasks: Redirect No Answer. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Not Ready. The agent's Not Ready time after this call is used in
the calculation.
For Agent 2, this call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Active Time. The agent's active time for call is used in the
calculation.
• Agent State Times: % Wrap Up. The agent's wrap up time for call is used in the
calculation.
agent 31: Agent Not Ready For Agent 1, this call affects the following fields
Detail Report
• Reason Code. This field displays "Ring No Answer [32767]".
• Duration. This field displays the amount of time that the agent remained in Not Ready
state.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
138
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Agent Report
Fields Affected by Call Flow
• % Logon Duration. This field displays the percent of the agent's logon duration in which
the agent was in Not Ready state with this reason code.
• % Not Ready. This field displays the percent of the agent's entire Not Ready duration in
which the agent was in Not Ready state with this reason code.
Table 53: Sample Skill Group Reports
Skill Group Report
Fields Affected by Call Flow
perskg31: IPCC Peripheral For Agent 1's skill group, this call affects the following fields:
Skill Group Task Summary
• Completed Tasks: Redirect No Answer. This field is incremented.
Half Hour Report
• Completed Tasks: Total. This field is incremented.
For Agent 2's skill group, this call affects the following fields:
• Total Queued. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Handled. This call is used in the calculation.
• Completed Tasks: Total. This field is incremented.
• Transfer In. This field is incremented.
perskg35: IPCC Peripheral For Agent 1's skill group, this call affects the following fields
Skill Group Consolidated
• Completed Tasks: Redirect No Answer. This field is incremented.
Half Hour Report
• Agent State Times: % Not Ready Time. The agent's Not Ready time after this call is
used in the calculation.
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used in
the calculation.
For Agent 2's skill group, this call affects the following fields
• Total Queued. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: AHT. The handle time for this call is used in the calculation.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
139
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Skill Group Report
Fields Affected by Call Flow
• Completed Tasks: Avg Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: Active Time. The active time for this call is included in this value.
• Agent State Times: % Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Wrap Up Time. The agent's wrap up time for this call is used in
the calculation.
• ASA. This call is used in the Average Speed of Answer calculation.
Table 54: Sample Call Type Reports
Call Type Report
Fields Affected by Call Flow
caltyp05: Analysis of Calls
Half Hour Report
For the original call type, the Tasks Routed field is incremented.
For the RONA call type, this call affects the following fields:
• Tasks Routed. This field is incremented.
• Assigned from Queue. This field is incremented.
• Avg Wait Time in Queue. This call is used in the calculation.
caltyp21: Call Type Half Hour For the original call type, this call affects the following fields
Report
• Tasks: Offered. This field is incremented.
• Tasks: Answer Wait Time. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Other. This field is incremented.
For the RONA call type, this call affects the following fields
• Service Level. This call is used in the Service Level calculation. Because the call
was answered within the service level threshold, it affects the Service Level positively.
• ASA. This call is used in the Average Speed of Answer calculation.
• Tasks: Offered. This field is incremented.
• Tasks: Answered. This field is incremented.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
140
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Call Type Report
Fields Affected by Call Flow
• Tasks: Answer Wait Time. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Queued. This call is included in the calculation.
caltyp31: Call Type
For the RONA call type, this call affects the following fields
Abandon/Answer Distribution
• ASA. This field is incremented.
by Half Hour Report
• 00:01:00 - 00:01:30: Ans. This field is incremented.
Table 55: Sample VRU Service Reports - Not Applicable for System IPCC or ARI
Service Report
Fields Affected by Call Flow
persvc20: Peripheral Service for IVR This call affects the following fields:
Queue Half Hour Report
• Tasks Offered. This field is incremented.
• Service Level. This call is used in the Service Level calculation. Because the
call was answered within the service level threshold, it affects the Service
Level positively.
• Tasks Routed. This field is incremented.
Voice Calls that Redirect on No Answer with CVP
The following script is used for this example:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
141
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Figure 15: Routing Script for Redirection on No Answer with ISN
The following events occur:
1. Agent 1 is available.
2. The call enters script at 4:03 p.m.
3. The call is assigned to Agent 1 using the Queue to Skill Group node at 4:03 p.m.
4. The call rings on the agent desktop The ring time exceeds agent desk settings. The agent
is made Not Ready, reason code 50010 at 4:03:30 p.m.
5. The ring time exceeds CVP timeout at 4:03:32 p.m. The call is requeried. The call then
goes through the failure path of the first Queue to Skill Group node.
6. The Call Type is changed in the script for tracking purposes.
7. The script then goes to the second Queue to Skill Group node. No agents are ready, so the
call is queued.
8. Agent 2 becomes Ready at 4:06:10 p.m. The call is assigned to agent.
9. The agent answers call at 4:06:39 p.m.
10. The caller ends call at 4:10 p.m.
11. The agent performs Wrap up work until 4:12 p.m.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
142
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
For this call flow, events occur within the 16:00:00 to 16:29:59 reporting interval. Reports run
from 16:00:00 to 16:29:59 display all of the data for this call.
Table 56: Sample Agent Reports
Agent Report
Fields Affected by Call Flow
agent04: Agent Task Detail For Agent 1, this call does not affect any fields.
Report
For Agent 2, this call affects the following fields:
• Tasks Handled: Total Tasks. This field is incremented.
• Tasks Handled: Avg Time. The handle time for call is used in the calculation.
• % Wrap Up. The agent's wrap up time for this call is used in the calculation.
agent25: Agent
Consolidated Half Hour
Report
For Agent 1, this call affects the following fields
• Completed Tasks: Redirect No Answer. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Not Ready. The agent's Not Ready time after this call is used in
the calculation.
For Agent 2, this call affects the following fields
• Completed Tasks: Handled. This field is incremented.
• Agent State Times: % Reserved Time. This agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Active Time. The agent's active time for call is used in the
calculation.
• Agent State Times: % Wrap Up. The agent's wrap up time for call is used in the
calculation.
agent31: Agent Not Ready For Agent 1, this call affects the following fields
Detail Report
• Reason Code. This field displays "Ring No Answer [32767]".
• Duration. This field displays the amount of time that the agent remained in Not Ready
state.
• % Logon Duration. This field displays the percent of the agent's logon duration in which
the agent was in Not Ready state with this reason code.
• % Not Ready. This field displays the percent of the agent's entire Not Ready duration in
which the agent was in Not Ready state with this reason code.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
143
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Table 57: Sample Skill Group Reports
Skill Group Report
Fields Affected by Call Flow
perskg31: IPCC Peripheral For Agent 1's skill group, this call affects the following fields:
Skill Group Task Summary
• Completed Tasks: Redirect No Answer. This field is incremented.
Half Hour Report
• Completed Tasks: Total. This field is incremented.
For Agent 2's skill group, this call affects the following fields:
• Total Queued. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Handled. This call is used in the calculation.
• Completed Tasks: Total. This field is incremented.
• Transfer In. This field is incremented.
perskg35: IPCC Peripheral For Agent 1's skill group, this call affects the following fields
Skill Group Consolidated
• Completed Tasks: Redirect No Answer. This field is incremented.
Half Hour Report
• Agent State Times: % Not Ready Time. The agent's Not Ready time after this call is
used in the calculation.
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used in
the calculation.
For Agent 2's skill group, this call affects the following fields
• Queued. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: AHT. The handle time for this call is used in the calculation.
• Completed Tasks: Avg Active Time. The agent's active time for this call is used in the
calculation.
• Agent State Times: Active Time. The active time for this call is included in this value.
• Agent State Times: % Active Time. The agent's active time for this call is used in the
calculation.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
144
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Skill Group Report
Fields Affected by Call Flow
• Agent State Times: % Reserved Time. The agent's reserved time for this call is used in
the calculation.
• Agent State Times: % Wrap Up Time. The agent's wrap up time for this call is used in
the calculation.
• ASA. This call is used in the Average Speed of Answer calculation.
Table 58: Sample Call Type Reports
Call Type Report
Fields Affected by Call Flow
caltyp05: Analysis of
Calls Half Hour Report
For the original call type, the Tasks Routed field is incremented.
For the RONA call type, this call affects the following fields:
• Tasks Routed. This field is incremented.
• Assigned from Queue. This field is incremented.
• Avg Wait Time in Queue. This call is used in the calculation.
caltyp21: Call Type Half For the original call type, this call affects the following fields
Hour Report
• Tasks: Offered. This field is incremented.
• Tasks: Answer Wait Time. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Overflow Out. This field is incremented.
For the RONA call type, this call affects the following fields
• Service Level. This call is used in the Service Level calculation. Because the call was
answered within the service level threshold, it affects the Service Level positively.
• ASA. This call is used in the Average Speed of Answer calculation.
• Tasks: Offered. This field is incremented.
• Tasks: Answered. This field is incremented.
• Tasks: Answer Wait Time. This field is incremented.
• Completed Tasks: Total. This field is incremented.
• Completed Tasks: Handled. This field is incremented.
• Completed Tasks: % Queued. This call is included in the calculation.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
145
Chapter 7: Sample Calls and Report Data
IPCC Enterprise Voice Call Reporting Data
Table 59: Sample VRU Service Reports - Not Applicable for System IPCC or ARI
Service Report
Fields Affected by Call Flow
persvc20: Peripheral Service for IVR This call affects the following fields:
Queue Half Hour Report
• Tasks Offered. This field is incremented.
• Service Level. This call is used in the Service Level calculation. Because the
call was answered within the service level threshold, it affects the Service
Level positively.
• Tasks Routed. This field is incremented.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
146
Chapter 8
Troubleshooting Report Data
This section provides troubleshooting information for IPCC Enterprise report data.
This chapter contains the following topics:
•
•
•
•
Troubleshooting Agent Reporting, page 147
Troubleshooting Call Type and Skill Group Reporting, page 150
Troubleshooting Queue Reporting, page 155
Troubleshooting VRU Application and Trunk Group Reporting (Not applicable to System
IPCC or ARI), page 156
• Troubleshooting Historical Data Server Data, page 157
• Troubleshooting Application Gateway Reporting, page 159
Troubleshooting Agent Reporting
Agent data does not appear in reports
Symptom:
Agent data does not appear in WebView agent reports.
Message:
None
Cause:
This might occur if the enable agent reporting option is disabled for the Cisco CallManager
peripheral.
Action:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
147
Chapter 8: Troubleshooting Report Data
Troubleshooting Agent Reporting
If you are using any deployment other than System IPCC, in the PG Explorer tool of the ICM
Configuration Manager, open the Cisco CallManager peripheral (either the CallManager PG or
IPCC PG depending on your configuration). Check the enable agent reporting option on the
Agent Distribution tab.
If you are using System IPCC, this is enabled by default.
Agent Not Ready reason code text does not appear in reports
Symptom:
The WebView Agent Not Ready reports (agent30: Agent Not Ready Summary and agent31:
Agent Not Ready Detail ) show only the numeric Not Ready reason code, not the textual code.
Message:
None
Cause:
This might occur if you either have not configured the Not Ready reason codes with associated
text in the ICM/IPCC configuration tool or the agent event detail option is disabled for the Cisco
CallManager peripheral. For System IPCC, agent event detail is enabled by default and cannot
be disabled.
Action:
If Not Ready reason codes are not configured in the ICM/IPCC configuration, configure the
Not Ready reason codes and their textual equivalents using the Reason Code List tool. These
reason codes match the Not Ready reason codes configured in the agent desktop software.
Note: The IPCC Enterprise system uses several predefined Not Ready reason codes (50002,
50010, and 32767) that do not have associated text. If you want a textual reason code to appear
in reports for these Not Ready reason codes, you must configure them in the Reason Code List
Tool.
If Not Ready reason codes are configured in ICM Configuration Manager, open the Cisco
CallManager peripheral (either the CallManager PG or IPCC PG depending on your
configuration). Check the agent event detail option on the Agent Distribution tab.
Agent state does not appear in Agent State Trace reports
Symptom:
Agent state information does not appear in WebView real-time agent state trace report.
Message:
None
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
148
Chapter 8: Troubleshooting Report Data
Troubleshooting Agent Reporting
Cause:
This might occur if the agent state trace option is disabled for the agent.
Action:
In the ICM/IPCC configuration tool, open the agent's record. Check the agent state trace option.
Note: Enabling agent state trace for many agents might impact system performance as the option
causes more records to be written to the database. If you notice a performance problem, you
might want to disable agent state trace, or only enable agent state trace for those agents on whom
you are reporting.
Agent Desktop Statistics for LoggedOnTimeSession do not appear to report accurately
Symptom:
For agents who log in at a CTI OS desktop, the LoggedOnTimeSession is sometimes smaller
than the summary of AvailTimeSession and HandledCallsTalkTimeSession in WebView reports.
The Handled Calls and AvailTime summary might differ from the logged on time by as much
as 18 seconds over a half hour period (about 1%).
Message:
N/A
Cause:
This is a rounding issue and is to be expected. Although the Handled Calls and AvailTime
summary might differ by about 1% over a half-hour period, the HandledCallsTalkTimeSession
will correlate with a summary of Termination Call Detail data at the end of the day.
Action:
N/A
Agent-initiated Outbound calls appear as Inbound/Internal
Symptom:
When an agent makes an outbound call, the call appears as an internal outbound call in reports
and statistics. Call counts appear in the 'Internal Out' column in WebView reports, and do not
appear in the 'External Out Task' field as expected.
Message:
N/A
Cause:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
149
Chapter 8: Troubleshooting Report Data
Troubleshooting Call Type and Skill Group Reporting
In the configuration for Call Manager, under Route Pattern Configuration, the check box for
'Allow Overlap Sending' is not selected.
Action:
To resolve this, make sure that in the configuration for Call Manager, under Route Pattern
Configuration, the check box for 'Allow Overlap Sending' is selected.
Troubleshooting Call Type and Skill Group Reporting
Call Type ErrorCount incremented if Caller disconnects when call is translation routed
Symptom:
During a transfer, the caller hangs up while the call is being transferred. The call is reported as
an error.
Message:
None
Cause:
IP IVR cannot notify ICM that the call abandoned because it does not yet have the call object
information. For reporting, the call is reported as an error, and a Route_Call_Detail record is
cut for the call.
Action:
The call flow was that the call was translation routed to the IVR, but it did not get there. The
Router encountered a translation route time out.
Call Type reports and Overflow Out Column
Symptom:
Call Types reports, both real time and Historical, might seem to not peg correctly, based on the
call counts in the "overflow out" column.
The reports affected are caltyp20, caltyp21, caltyp22, caltyp23, caltyp24, caltyp35, and caltyp36.
Message:
None
Cause:
Overflow Out is incremented when one of the following occurs:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
150
Chapter 8: Troubleshooting Report Data
Troubleshooting Call Type and Skill Group Reporting
1. The Call Type associated with the current call is changed through use of a Call Type or
Requalify node.
2. The call is redirected.
When a call is redirected, the PIM no longer can receive events for the call and has no
way of referencing or tracking the call. For example, the call might have been redirected
to a non-ICM monitored device and then returned to the switch with a different call ID.
The ICM generates the termination call detail record with only the data originally tracked
for the call. Calls marked as Redirected are counted as OverflowOut calls in the ICM
service and route tables.
3. The call is sent to a label using a label node. The call was not default-routed, and the label
was not a ring, busy, or announcement label.
4. The call hits a release node.
Action:
Consider these conditions by which Overflow Out is incremented when you analyze the Overflow
Out columns in Call Type reports.
Calls Offered for call type does not seem correct over a half-hour interval
Symptom:
Calls Offered for the Call Type WebView reports is calculated as Calls Handled + Calls
Abandoned + Return Busy + Return Ring + Default Treatment + Network Routed + Overflow
Out + Call Errors + Announcement Calls + Short Calls. However, in a half-hour interval, this
equation might not provide the report value for Calls Offered.
Message:
None
Cause:
Calls might change state in different half-hour intervals. For example, if a call is offered at 10:59
AM but is not handled until 11:01 AM, the Call Type data for the 10:30:00 to 10:59:59 interval
is incremented for calls offered, but not calls handled. Calls handled is incremented in the next
half-hour interval.
Action:
None required
Total number of calls queued to each skill group is greater than the number of calls offered for the day
Symptom:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
151
Chapter 8: Troubleshooting Report Data
Troubleshooting Call Type and Skill Group Reporting
The total number of calls queued to each skill group is greater than the number of calls offered
to the skill groups over a day. For example, 800 calls are queued to skillgroup1 and 700 calls
queued to skillgroup2, but the total number of calls queued is 900, not 1500.
Message:
None
Cause:
When a call is queued to more than one skill group, the call is counted as queued in each skill.
Therefore, it appears that the call is being counted more than once. At the Call Type level, these
calls are correctly counted as only one call. Similarly, if the call abandons while queued, it is
counted as an abandon in each skill group to which it is queued but is counted correctly as one
call at the Call Type level.
Action:
None required
Calls counted as errors in call type reports
Symptom:
Call type reports show calls being counted as errors.
Message:
None
Cause:
This is expected behavior. The error count for the call type is incremented for three events.
These events include:
• An error occurs in the ICM script and a default route is not configured.
Examples of script errors include:
– The calls enters a loop in the script and is executed in more script nodes than the
configuration allows and a default label does not exist.
– A call is queued for longer than the maximum queue time configured and a default label
does not exist.
– A terminating node does not lead to a label and a default label does not exist.
• A TCD record is written with a CallTypeID that has a Call Disposition that is unexpected or
not counted elsewhere (The CallDispositionFlag will be 4). For Router errors, this includes
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
152
Chapter 8: Troubleshooting Report Data
Troubleshooting Call Type and Skill Group Reporting
calls with RouterErrorCode in RCD which is greater than 0 but not 448. For Agent errors,
this includes Call Dispositions 1, 4, 8-12, 16-18, 20-27, 31-33, 39, 42, 44-51.
• An error occurs at the VRU or CallManager that causes the call to fail before the router has
completed the call routing.
Action:
To avoid script errors from being reported as errors of the call type, configure default labels
and default routes for scripts.
See Also
Cisco ICM Enterprise Edition Database Schema Handbook
Calls counted as incomplete in call type reports
Symptom:
Call type reports show calls being counted as incomplete.
Message:
None
Cause:
An incomplete call is a call that was routed to an agent, but failed to arrive. Incomplete calls
have a Call Disposition of 1 in the Terminiation_Call_Detail record.
Calls are counted as incomplete under these conditions:
• The agent presses the head set button to enable the headset while in the Available state as
the ICM Router is attempting to send the agent a call.
• The agent attempts to make a call from the hard phone as the ICM Router is attempting to
send the agent a call.
• An agent in the Available state is direct dialed as the ICM router is attempting to send the
agent a call.
• Network problems occur, such as traffic congestion.
• The call disconnects en route to the agent.
• An incorrect label is configured for the device target. Therefore, the call is sent to the wrong
number and the agent never receives the call.
Action:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
153
Chapter 8: Troubleshooting Report Data
Troubleshooting Call Type and Skill Group Reporting
None required
Calls offered to the call type is greater than total calls offered to skill group
Symptom:
Two call types, Call Type 1 and Call Type 2, are configured. All of the calls for these call types
are offered to the same skill group. The total number of calls offered to Call Type 1 and Call
Type 2 is greater than the total calls offered to the skill group.
Message:
None
Cause:
Skill group Calls Offered and call type Calls Offered are not equivalent, even if all calls for the
call types are sent to the same skill group. If a call disconnects for any reason before it reaches
the Queue to Skill Group script node, Calls Offered is incremented for the call type, but is not
incremented for the skill group.
Action:
None required
Number of calls that abandon while ringing for the skill group does not equal the number of calls that abandon for
the call type
Symptom:
A call type report displays a larger number of calls that abandon than the number of calls that
are shown as abandon ring in a skill group report.
Message:
None
Cause:
There is no correlation between calls that abandon and calls that abandon while ringing. Abandon
Ring calls are calls that are routed by ICM software to a skill group and were abandoned while
ringing at an agent's phone. Abandon Ring is incremented only when this specific event occurs.
The call type Calls Abandoned is incremented every time a call abandons, including while the
call is in queue and at any point in the ICM routing script before the call rings at an agent.
Action:
None required
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
154
Chapter 8: Troubleshooting Report Data
Troubleshooting Queue Reporting
Abandon delay time when caller abandons in queue is different than average abandon delay time when call abandons
while ringing for the call type
Symptom:
abandon delay time when caller abandons in queue is different than average abandon delay time
when call abandons while ringing for the call type.
Message:
None
Cause:
The average abandon delay time is calculated for calls that abandoned in the half-hour interval
(CallsAbandonQToHalf). The CallsAbandonQToHalf database field is incremented for calls
that were abandoned while in queue, while ringing, or while in a script node.
For calls that abandon in the routing script, the average abandon delay time is the average time
that calls spend in the ICM script before being abandoned. This time includes any time that the
call spent in the script before being queued.
For calls that abandon while ringing, the average abandon delay time is the average of Queue
Time + Ring Time + Delay Time. The average abandon delay time does not include the time
that the call spent in the ICM script before being queued.
Action:
None required
Troubleshooting Queue Reporting
Queue information does not appear in reports (Not applicable to System IPCC or ARI)
Symptom:
Data relating to queued calls does not appear in reports; fields related to queued tasks are 0.
Message:
None
Cause:
This can occur if you have not enabled Queue reporting for the VRU peripheral.
Action:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
155
Chapter 8: Troubleshooting Report Data
Troubleshooting VRU Application and Trunk Group Reporting (Not applicable to System IPCC or ARI)
In the ICM Configuration Manager, open the VRU peripheral. Select the Queue reporting
option.
Missing call in queue information in the WebView Service real-time and historical templates (Not applicable to
System IPCC or ARI)
Symptom:
In the WebView Service templates, the value of "Calls Q Now" and "Calls Q Now Time" are
0.
Message:
None
Cause:
This can occur when the route links to the skill group because it causes a lack of visibility for
the "Longest Call Queued" values.
Action:
For IPCC Enterprise, use the Call Type or Skill Group templates to report on the "Calls Q Now"
and "Calls Q Now Time" fields, as these fields are updated correctly for the skill group for every
call in the Queue.
Troubleshooting VRU Application and Trunk Group Reporting (Not applicable to System IPCC
or ARI)
VRU Application information does not appear in Call Type or Service reports
Symptom:
Data relating to VRU applications, such as the number of VRU Handled tasks or data for VRU
services, does not appear in reports; fields related to VRU applications are 0.
Message:
None
Cause:
This can occur if you have not enabled Service Control reporting for the VRU peripheral.
Action:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
156
Chapter 8: Troubleshooting Report Data
Troubleshooting Historical Data Server Data
In the ICM Configuration Manager, open the VRU peripheral. Select the Service Control
option.
Information for Trunk Groups associated with VRU ports does not appear in trunk group reports (Not applicable to
System IPCC or ARI)
Symptom:
Data relating to VRU ports does not appear in trunk group reports.
Message:
None
Cause:
This can occur if you have not enabled Service Control reporting and queue reporting for the
VRU peripheral.
Action:
In the ICM Configuration Manager, open the VRU peripheral. Select the Service Control option
and the Queue reporting option.
Troubleshooting Historical Data Server Data
Historical Data Server is losing the oldest data
Symptom:
Historical Data Server (HDS) data that is within the data retention time set for the HDS is being
purged from the database.
Message:
None
Cause:
This could occur because the database has reached 80% capacity and is therefore performing
purge adjustment each night to reduce the size to 80%. Unlike scheduled purges, in which data
is purged nightly to remove all records older than the data retention time you specified, purge
adjustment removes the last record from each table in the database until 80% capacity is reached.
Purge adjustment continues to reduce the size of the database to 80% until the database size is
increased.
Action:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
157
Chapter 8: Troubleshooting Report Data
Troubleshooting Historical Data Server Data
To correct this, increase the size of the database.
Historical report is missing data for a recent interval
Symptom:
A historical report is missing data for a recent interval.
Message:
None
Cause:
This could occur because you are running the report at the end of the last interval (for example
it is 12:31 and you are running a report from the 12:00:00 to 12:29:59 interval). Data replication
from the Logger to the Historical Data Server can be delayed by 1 to 5 minutes. The data for
the last interval might not be in the HDS yet.
This could also be because the Logger connected to the HDS has gone offline or because the
Logger went offline and is now in the process of recovering. When the Logger fails, the HDS
does not switch to the back up Logger. Instead, it waits for its Logger to recover. When the
Logger recovers, it begins receiving current data and recovers data from the back up Logger
for the time it was down. Once data recovery is complete, the Logger begins to send the recovery
data to the HDS. Report data for the selected interval is available once the Logger has completed
recovery and the data is replicated to the HDS.
This problem could also occur if the HDS has gone offline or because the HDS went offline
and is now in the process of recovering. If it is recovering, data for the selected interval will be
available when recovery for that interval is complete. If the HDS has failed, the data for that
interval will be available when the HDS comes back up and completes recovery for that interval.
In either case the data is still on the logger and is not lost.
Action:
No action is necessary; the data will appear in reports when the recovery and replication processes
are complete. Try running the report again in several minutes.
Data is missing from the Historical Data Server after it has recovered from a failure
Symptom:
Historical data is missing from the HDS.
Message:
None
Cause:
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
158
Chapter 8: Troubleshooting Report Data
Troubleshooting Application Gateway Reporting
This could be because your logger data retention and Historical Data Server backup schedule
are not in sync. You plan these two schedules together so that you retain data on the logger for
the period in which the HDS is not backed up. For example, if you are retaining data on the
logger for 2 weeks, you back up the HDS, at the minimum, once every two weeks. This way,
if the HDS fails, it can recover past data up to the last two weeks from a previous HDS back up
and data for the last two weeks from the logger. If you are backing up the HDS every two weeks
but storing data on the logger for only a week, you will be missing a week of historical data if
the HDS fails or the database has become corrupted.
Action:
Change the data retention on the logger or backup schedule for the HDS to avoid this issue
Troubleshooting Application Gateway Reporting
The number of Application Gateway requests in reports is larger than the number of Router Call Detail records
Symptom:
The number of Application Gateway requests shown in the WebView Application Gateway
Half Hour Status report is larger than the number of Router Call Detail (RCD) records in the
database.
Message:
None
Cause:
This might occur if the router has sent an Application Gateway request and has not yet received
a response. An RCD record is written when a call completes routing according to the router.
The Application Gateway request is incremented when the router sends an Application Gateway
request. For these calls, the number of Application Gateway requests has been incremented, but
the RCD has not been written.
Action:
If you run the report at the end of the day, the two numbers be very close, if the contact center
does not receive calls 24 hours a day.
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
159
Chapter 8: Troubleshooting Report Data
Troubleshooting Application Gateway Reporting
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
160
Index
agent tasks, Outbound Option ....62
Index
agent teams, about....9
agent teams, planning for reporting....16
abandoned short calls....12, 21, 83, 108
answered short calls....21, 108, 109
abandoned short calls, configuration....86, 110
answered short calls, configuration....110
abandoned short calls, scripting....86
Application Gateway reporting, troubleshooting....159
ACD architecture....28
application instance fail-over ....123, 124
Active/Talking....50
ARI Deployment....1
Admin Workstation....26
ARS PG....1
agent availability ....38
ASA, agent....88
agent desktop fail-over ....122
ASA, call type....87
agent event detail option....13
ASA, skill group....87
agent historical reporting....46
ASA reporting....87
agent management ....45
Average Speed of Answer....87
Agent Not Ready Reason Code reports....54
Barge-in ....73
agent PG fail-over....124
base skill groups....14
agent PIM fail-over....124
blind transfer....66
agent real-time reporting ....46
Busy Other....51
agent report data ....47
callrouter....26
agent reporting, configuration....57
call type, abandon....82
agent reporting, troubleshooting....147
call type, abandoned short calls....83
agent reporting categories....46
call type, abandons en-route to VRU....81
agent reporting option....13
call type, calls with bad label....83
agent report templates....45
call type, non-monitored devices....85
agent routability....38
call type, reporting intervals....94
agents, planning for reporting ....12
call type, RONA....83, 84
agent states, about ....50
call type and skill group data, comparing records ....36
agent states, active skillgroup ....52
call type reporting....80
agent states, hierarchy ....52
agent states, monitoring ....50
call type reporting, troubleshooting caller
disconnects....150
agent states, Outbound Option....62
call type reporting, troubleshooting Overflow Out.150
agent states, relationship with task states ....53
call type reporting, configuration....85
agent state trace option....13
call type reporting, scripting....85
agent statistics ....45
call type reporting, troubleshooting....150
agent task handling, reporting on ....58
call types, about....6, 80
call types, planning for reporting ....11
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
Index 161
Index
Capture microapplication....20, 117
customer experience reporting ....77
Cisco Agent/Supervisor Desktop (CAD)....27
customer experience reporting categories....78
Cisco CallManager ....26
customer experience statistics....77
Cisco CallManager fail-over ....123
customer experience templates....77
Cisco Collaboration Server ....27
custom reports, planning ....24
Cisco CTI Object Server (CTI OS)....27
data, comparing ....35
Cisco Customer Voice Portal (CVP)....26
default skill group, configuration....107
Cisco Dynamic Content Adapter....27
default skill group, scripting....107
Cisco E-Mail Manager....27
default skill group data, agent to agent dialing....106
Cisco IP-IVR....26
default skill group data, conferences....107
Cisco Media Blender....27
default skill group data, new calls....106
Cisco Unified Intelligence Suite....1, 6
default skill group data, transfers....107
Conference in calls....61
default skill group reporting....105
Conference out calls....61
Dialed Number Plan ....66
conferences....66
Dialed Number Plan, transfers and conferences....66
conferences, configuration ....64, 71
Distributor AW....26
conferences, effect on calls....68
Emergency Assist....72
conferences, effect on database fields....67
emergency assist, planning for reporting....17
conferences, effect on skil groups ....68
enterprise skill groups, about....8
conferences, planning for reporting....16
enterprise skill groups, planning for reporting....16
conferences, scripting....64, 71
external tasks....58
conferences to agent, configuration ....71
fail-over, effect on reporting ....121
conferences to agent, scripting....71
full-time equivalents reporting....110
conferences to skill group, configuration ....71
half-hours boundaries, impact on reporting ....37
conferences to skill group, scripting....71
HDS....26
configuration, monitoring....97
HDS, about....32
Consultative calls....61
HDS, backup schedule....32
consultative transfer....66
HDS, failure and recovery....32
CTI Manager Service fail-over....121
HDS, planning for reporting....22
CTI OS Server....26
historical data....33
CTI OS Server fail-over....122
historical data ....35
CTI Server....26
Historical Data Server....26
customer experience historical reporting....78
Historical Data Server, about....32
customer experience real-time reporting ....78
Historical Data Server, backup schedule....32
customer experience report data....79
Historical Data Server, failure and recovery....32
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
Index 162
Index
Historical Data Server, planning for reporting ....22
Not Ready....52
Historical Data Server data, troubleshooting....157
Not Ready reason code reporting, configuration ....57
ICM components in IPCC....26
Not Ready Reason codes....13
ICM Enterprise with ACD architecture....28
Not Ready reason codes ....54
ICM-routed calls....60
operational statistics ....98
ICM software....26
operational templates ....98
Incoming direct calls....59
operations, monitoring....97
incoming tasks....58
operations data....99
Intercept ....73
operations historical reporting....98
internal tasks....58
operations real-time reporting....98
IPCC Enterprise, about....25
operations templates....98
IPCC Enterprise architecture....29
Outbound Dialer....26
IPCC Enterprise architecture with multichannel applications
....30
Outbound Option, configuration....108
IPCC Enterprise components, about ....26
IPCC Enterprise reporting architecture, about ....25
IPCC Enterprise reporting statistics....29
ISN Ring No Answer timeout....64
ISN Ring No Answer timeout....65
logger....26
Logger, data retention....32
Logger, failure and recovery....32
logout reason codes ....56
Logout reason codes, configuring ....58
Media Classes, about....9
Media Classes, about ....38
Media Routing Domains, about....9
Media Routing Domains, about ....37
Media Routing Peripheral Gateways....27
MR PG....26
MR PG fail-over....123
multichannel report applications ....42
multichannel report data ....37
multichannel report data ....41
naming conventions, about....10
Outbound Option, scripting....108
Outbound Option reporting....107
Outbound Option tasks....62
Outgoing external calls....59
Outgoing internal calls....59
outgoing tasks....58
Paused/Hold....50
percent utilization reporting....110
Peripheral Gateways ....27
perpherals, about....7
PG fail-over ....121
planning for reporting ....5
predefined Logout Reason codes....56
predefined Not Ready reason codes....55
queue data, troubleshooting....155
queue to agent node....57
real-time and historical data, comparing records ....35
real-time data....33
real-time data ....33
real-time database tables....33
Redirection No Answer with IP-IVR, configuration ....65
Redirection No Answer with IP-IVR, scripting ....65
Not Active....51
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
Index 163
Index
Redirection No Answer with ISN, configuration ....65
skill groups, about....8
Redirection No Answer with ISN, scripting ....65
skill groups, planning for reporting ....14
Redirection on No Answer, about....9
sub-skill groups....14
Redirection on No Answer tasks, IP-IVR ....63
sub-skill groups, issues for reporting....14
Redirection on No Answer tasks, ISN ....64
supervisor action ....72
Redirection on No Answer with IP-IVR, planning for
reporting ....17
supervisor action, configuration ....74
Redirection on No Answer with ISN, planning for reporting
....18
reporting entities ....42
reporting intervals ....33
Reserved....51
Ring No Answer dialed number....65
Ring No Answer time....63, 64, 65
RONA, configuration....85, 86
RONA, scripting....85, 86
RouterCallsDequeued....89
sample voice call with consultative transfer ....132
sample voice call without queuing ....126
sample voice call with queuing ....128
sample voice call with RONA....136, 141
scripting, monitoring....97
Service Level....11, 15, 19, 88
Service Level, call type....91
Service Level, skill group....92
Service Level, VRU service....94
Service Level calculation....88
Service Level reporting....88
Service Level reporting, configuration....95
Service Level reporting, scripting....95
Service Level threshold....88
Service Level type ....88
short calls, configuration....110
short calls, planning for reporting ....21
short calls reporting....108
skill group reporting, troubleshooting....150
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
Index 164
supervisor action, scripting ....74
Supervisor Assist....72
supervisor assist, planning for reporting ....17
supervisors, planning for reporting....16
system pg....26
task states....53
task times....61
task types ....58
Transferred in calls....60
Transferred out calls....61
transfers ....66
transfers, configuration ....64, 71
transfers, effect on calls ....68
transfers, effect on database fields ....67
transfers, effect on skil groups ....68
transfers, planning for reporting ....16
transfers, scripting....64, 71
transfers to agent, configuration ....71
transfers to agent, scripting....71
transfers to skill group, configuration ....71
transfers to skill group, scripting....71
Translation Route Reports....119
troubleshooting
call type reporting, troubleshooting....150
trunk group data, troubleshooting....156
unexpected conditions, planning for reporting ....20
Unified Intelligence Center....6
Voice Response Unit....26
VRU application data, troubleshooting....156
Index
VRU application monitoring, information gathering....115
VRU application monitoring, self-service....115
VRU application reporting....111
VRU applications, about....9
VRU applications, configuration....118
VRU applications, information gathering....115
VRU applications, information gathering ....112
VRU applications, planning for reporting ....18
VRU applications, queuing....112
VRU applications, scripting....118
VRU applications, self-service....112, 115
VRUProgress variable....19
VRUProgress variables....116
VRU utilization reporting....114
WebView
installation location....26
Work Not Ready....51
Work Ready....50
Reporting Guide for Cisco Unified Contact Center Enterprise & Hosted 7.5(1)
Index 165
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement