Contents

• Reporting
• Reporting Data
• Real Time Data Collection
• Historical and Interval Data Collection
• Configuration Data
• Call Detail Data
• Event Data
• Database Tables that Hold Reporting Data
• Why Report Data Can Differ
• Real Time and Historical Reports
• Interval Boundaries
• Reporting entities and concepts
• Agent States
• How Agent States Are Calculated in Reports
• Agent States, Skill Groups, and Precision Queues
• Agent State and Task State Relationship
• Reports that Show Agent States
• Agent Logout Reason Codes
• Reports that Show Agent Logout Reason Codes
• Agent Not Ready Reason Codes
• Reports that Show Agent Not Ready Reason Codes
• Agent Task Handling
• Types of Tasks
• Task Times
• Reports that Show Agent Task Handling
• Agent Utilization: Full-Time Equivalents and Percent Utilization
• Reports that Show Percent Utilization and FTE Metrics
• Reports that Show Agent States
• Reports that Show Agent Logout Reason Codes
• Reporting on Agents
• Skill Groups
• Default Skill Group
• Role of Default Skill Group in Reporting
• How New Calls Increment Default Skill Group Statistics
• How Agent-to-Agent Dialing Increments Default Skill Group Statistics
• How Transferred and Conferenced Calls Increment Default Skill Group Statistics
• Reports on Skill Group Operations
• How Calls Offered is Calculated for Skill Group
• Reports that Show Skill Group Operations
• Agent Teams and Supervisors
• Agent Teams and Supervisors
• Agent Team Reports
• Supervisor Action Reports
• Supervisor Assist and Emergency Assist for Existing Call
• Barge-In
• Intercept
• Reports that Show Information on Agent Teams
• Reporting on Supervisors
• Reports that Show Information on Agent Teams
• Average Speed of Answer
• How ASA is Calculated
• ASA for Agent and Skill group
• Reports That Show ASA for Agents
• ASA for Call Type
• Reports That Show ASA for Call Type
• Requery
• Call Types
• Call Type Reports
• Call Types
• Best Practices for Call Types
• Changing Call Types
• Call Type Reporting
• How Calls Offered is Calculated for Call Type
• How Call Errors Affect Call Type Reporting
• How Calls with a Bad Label Affect Call Type Reporting
• How Calls that Experience CVP Ring No Answer Affect Call Type Reporting
• How Calls that Terminate Label Node and Route to Non-Monitored Devices Affect Reporting
• Call Type Reports
• Reporting on Calls
• Bucket Intervals
• Bucket Interval Reports
• Service Levels
• About Service Levels
• Service Level Threshold
• Service Level Type
• Service Level at Call Type
• Service Level at Skill Group
• Best Practices for Service Levels
• Service Level Relationships: MRD, Skill Groups, and Precision Queues
• Short Calls, Abandoned Calls, and Overflow Calls
• Short Calls
• Abandoned Short Calls
• Answered Short Calls
• Short Call Reports
• Abandoned Calls
• How Abandoned Calls Affect Reporting
• How Abandoned Short Calls Affect Reporting
• Abandoned Call Reports
• Transfers and Conferencing
• About Transfers and Conferences
• Configuration and Scripting for Transfers and Conferences
• Operational Reporting
• Trunks and Trunk Groups
• IVR/VRU Self-Service
• About CVP
• CVP Application Reporting
• Impact of CVP type on report data
• Self-Service, Information Gathering, and Queuing CVP Applications
• Monitoring Self-Service and Information Gathering Application Progress
• VRUProgress Variable
• Reports that Show VRU Metrics
• Data Loss and Component Failover
• Data flow for Reporting
• Recovery and Replication
• Possible Points of Delay or Inconsistency
• Methods to Prevent Data Loss from Logger and HDS Failure
• Data Loss from PIM Failure and Reporting
• Other Possible Points of Failover
• Peripheral Gateway / CTI Manager Service Failover
• Agent Desktop / CTI OS Server Failover
• Call type and Skill Group Metrics
• Call Type Real Time Table Metrics
• Network VRU and Skill Group Metrics
• Reporting on Skill Groups
• Reporting on Precision Queues

Reporting

---

This chapter describes how reporting data is collected, the system entities that appear in reports, lists of reports for each entity, and configuration settings that affect data collection and report content.

• Reporting Data
• Reporting entities and concepts
• Data Loss and Component Failover
• Call type and Skill Group Metrics
• Reporting on Skill Groups
• Reporting on Precision Queues

Reporting Data

Packaged CCE manages high volumes of call data, which are processed on the Packaged CCE Data Server . This section explains how reporting data are replicated in the system and presented in reports.

• Real Time Data Collection
• Historical and Interval Data Collection
• Configuration Data
• Call Detail Data
• Event Data
• Database Tables that Hold Reporting Data
• Why Report Data Can Differ

Real Time Data Collection

Both the Unified CCE Peripheral Gateway and the Call Router produce real time data that is forwarded and stored in both the Data Server and the optional External AW/HDS/DDS server. Old real time data is constantly overwritten by new real time data. No history is kept. Real time data is stored in data fields that reflect four time increments, as described in the following table:

Table 1 Real time data time increments

Real time data time increments	Description
Half	"Half" values contain a value for the current half-hour. Real time half-hour values are not affected by Interval configuration. That is, if you set the historical reporting interval to 15 minutes, the Half values in real time tables represent the current half-hour 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 09:18:33, the CallsOfferedHalf column in the Call_Type_Real_Time table 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 (09:00:00 or 09:30:00), the database element is reset to zero.
Now	"Now" contains a snapshot of the activity at a particular instant (the last check). For example, Packaged CCE 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 for reports that query for that value.
To5	The "To5" values track data on a rolling five-minute basis. The rolling five-minute data employs a "sliding" five-minute window.
Today	Contains the counts since midnight for each value

Historical and Interval Data Collection

Packaged CCE stores some historical data in Half_Hour tables and other historical data in Interval tables. Interval tables contain half-hour summaries. Interval data is kept for 13 months. If you need additional detail reporting detention, add the optional database server (AW/HDS/DDS).

Table 2 Historical and interval data

Historical data	Description
Interval (30-minute)	Note    Two Interval tables—Dialer_Interval and Campaign_Query_Rule Interval—always contain 30-minute data. Interval tables are : Agent_Interval (30) Agent_Skill_Group_Interval (30) Skill_Group_Interval (30) Call_Type_Interval (30) Call_Type_Skill_Group_Interval (30) Campaign_Query_Rule_Interval(30) Dialer_Interval (30) Router_Queue_Interval(30)
Half Hour	The Half_Hour tables are populated for completed half-hour intervals, and the data fields are stored in the database with the extension "ToHalf" (for example, Application_Gateway_Half_Hour.ErrorsToHalf). These elements contain a value for a completed half-hour interval. The completed interval is the time period falling between xx:00:00 and xx:29:59, or xx:30:00 and xx:59:59. For example, it is now 15:50:00. An error occurred at 15:47:00. The half-hour interval reported on right now is for the 15:00:00 to 15:29:59 interval. The error that occurred at 15:47:00 will be written to the database at 16:00:00, when the 15:30:00 to 15:59:59 half-hour interval is complete. Examples of Half_Hour tables are: Application_Gateway_Half_Hour Campaign_Half_Hour Trunk_Group_Half_Hour Route_Half_Hour

Configuration Data

Configuration tables define the entities and entity names that are defined in Configuration Manager and Web Config. They contain EnterpriseName fields that associate the key values in the historical tables with the text labels that are used in reports.

Examples of configuration tables are the Agent, Agent Team, Skill Group, and Call Type tables. For example, adding a new Agent Team inWeb Config adds an EnterpriseName for that team in the Agent Team database table.

Configuration Data and Routing Scripts are created and edited on the Administration & Data Server, stored on the data server, stored on the data server database and replicated to optional external AW/HDS/DDS servers.

Note	The name field in Web Config maps to enterprise names in the database.

Call Detail Data

Packaged CCE retains five weeks of records in each of these two detail tables on the data server. If additional detail reporting retention is desired, the optional database server (AW/HDS/DDS) must be added to the configuration. Two database tables store call detail, as described below:

• Route Call Details For every call routing request it handles, the Router records detailed data about the call and how it was routed to a peripheral by Unified ICM. This route call detail data (RCD record) is stored in the Route_Call_Detail table. RCD data is written to the database when the script ends. Non-routed calls, such as direct dials, transfers, and conferences, have no RCD records. You can use the data in the Route_Call_Detail table to see the starting point of the call. For example, you can see the Automatic Number Identification (ANI) and the type of request made. A typical Route_Call_Detail record might describe a call that originated with a CVP request, and an ANI of 9785551000. In addition, route call detail tells you how long the call was held in a queue.
• Termination Call Detail Detailed termination call detail data (a TCD record) is written for each call that arrives at a peripheral. The TCD record is written after the call segment terminates and the after-call work is complete. For example, typical Termination_Call_Detail data might show that the call was an Inbound ACD Call, that it was handled by a particular Skill Group; and that a particular agent handled the call. The Termination_Call_Detail record also describes the final disposition of the call (for example, how the call terminated; abandoned in network, disconnect/drop, and abandoned delay). In Packaged CCE most inbound calls have at least two TCDs: one for the segment of the call that was at CVP and one for the segment of the call handled by the agent. The Termination_Call_Detail table includes records that indicate which TCDs were used to create the Call Type, Call Type Precision Queue, and the Call Type Skill Group reports.

Although Call Detail records are stored in the Route_Call_Detail and Termination_Call_Detail tables, none of the standard (stock) reports retrieve data from these two tables for performance reasons.

To use Call Detail data in reports, you must create custom reports that populate from your custom database. These two detail tables are constrained to five weeks. If additional detail record reporting is required, an external database (AW/HDS/DDS) must be added to the configuration.

Event Data

Two database tables store system and application event data that is generated by the various components of Unified CCE software:

• Event The Event table stores all system events that are generated by the various Unified CCE components.
• Application_Event The Application_Event table stores all application events that are generated by the various components. This is a subset of the events reported in the Event table.

Note	By default, the Event and Application_Event data is not replicated to the HDS database.

Database Tables that Hold Reporting Data

All report data is pulled from tables and rows in the Packaged CCE database. Many fields are direct database values, as reflected in their displayed column names in the reports.

For example:

• The direction of the active task on which the agent is currently working is derived from Agent_Real_Time.Direction.

Other report data fields are less obvious—because they represent calculated values, because the same data-entity name is used in multiple contexts, or because they are calling database values whose names are not clearly indicative.

Calculated Fields. Many report values are the result of calculated fields. For example, in reports that present Skill Group Real Time activity, the Average Active Time (AAT) is calculated as follows: Skill_Group_ Real_Time.HandledCallsTalkTimeTo5 /Skill_Group_ Real_Time.CallsHandledTo5. Refer to the Unified Intelligence Center Report Template Guide for details on the calculated fields.

Fields Used in Many Tables and Context. Examples are the fields Deleted, Description, and EnterpriseName, which appear in many tables.

Why Report Data Can Differ

This chapter explains how and why data can differ in reports.

• Real Time and Historical Reports
• Interval Boundaries

Real Time and Historical Reports

Counts in real time data (for example CallsHandledTo5) do not match up with counts in the historical interval records (for example, CallsHandled) 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 increases by one (+1).
• Between 8:55 and 9:00, the real time data shows the answered call.
• The answered call does not populate the half-hour data until 9:00, when the 8:00 to 8:59:59 interval ends.

Interval Boundaries

Counts that would typically match up for a day, such as CallsOffered and CallsHandled, might not always match up over specific intervals. This discrepancy occurs because the counts for some data elements might be increased across boundaries.

Consider this example: at 8:55, a call comes in to 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 counted as handled in the 9:00:00 to 9:29:59 interval.
• If you run a report for the 9:00:00 to 9:29:59 interval, it appears 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 an 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 interval.

In general, interval boundary issues are reduced if you run daily reports. However, if your contact center runs 24 hours a day, you might still notice discrepancies for intervals such as the 11:30:00 to 11:59:59 and 12:00:00 to 12:29:59 intervals.

Reporting entities and concepts

This section describes the Unified CCE entities for which reports are available. Each entity is defined and the information available about that entity is described.

• Agent States
• Agent Logout Reason Codes
• Agent Not Ready Reason Codes
• Agent Task Handling
• Agent Utilization: Full-Time Equivalents and Percent Utilization
• Reports that Show Agent States
• Reports that Show Agent Logout Reason Codes
• Reporting on Agents
• Skill Groups
• Agent Teams and Supervisors
• Average Speed of Answer
• Requery
• Call Types
• Bucket Intervals
• Service Levels
• Short Calls, Abandoned Calls, and Overflow Calls
• Transfers and Conferencing
• Operational Reporting
• IVR/VRU Self-Service

Agent States

Agent states are determined from an agent's activity within a skill group. Agent state is recorded in numerous database tables and is presented in reports as both a number (Not Ready) and as a percentage (% Not Ready).

You can monitor agent states in real time to view current agent activity. You can also review past performance data to identify trends in agent states. For example, historical reports can show how much time an agent spends in Not Ready state, which indicates whether the agent is adhering to the schedule.

Information for some states is different for the chat Media Routing Domain (MRD). This table highlights these differences.

Table 3  Agent states that appear in reports

State in Skill Group	Description for all MRDs except chat	Description for chat MRD
Active/Talking	The agent is working on a task or a call in this skill group. 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.	The agent is working on one or more chat requests associated with this skill group. For these agents, the state is reported as Active.
Work Ready	The agent is performing wrap-up work for a call or task in this skill group. If the agent is handling a voice call, the agent enters Not Active state when wrap 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.	The agent is performing wrap-up work for a task associated with this skill group. The agent is not in the Active state with respect to a task associated with this skill group.
Work Not Ready	The agent is performing wrap-up work for a call in this skill group. The agent enters Not Ready state when wrap up is complete.	The agent is performing wrap-up work for a call in this skill group. The agent enters Not Ready state when wrap up is complete.
Paused/Hold	For agents who handle non-voice tasks, the state is reported as Paused. 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.	The agent is Paused with respect to a chat task associated with this skill group.
Reserved	The agent has been offered a call or task associated with the skill group. For voice calls, agents are Reserved when their phones are ringing. Agents handling Outbound Option calls are never placed in Reserved state; the Outbound Option Dialer puts the agent on hold when reserving the agent for a call.	The agent is not in Active, Work Ready, or Paused state in this skill group. The agent has been offered one or more tasks associated with this skill group.
Busy Other Busy Other is a state in which the agent handling calls is assigned to other skill groups during the interval. For example, an agent might be talking on an inbound call in one skill group while simultaneously logged on to, and ready to accept calls from, other skill groups. The agent can be active (talking on or handling calls) in only one skill group at a time. Therefore, while active in one skill group, for the other skill group the agent is considered to be in the Busy Other state.	The agent is Active, Work Ready, Reserved, or on Hold/Paused in another skill group in the same MRD.	The agent is not in Active, Work Ready, Reserved, or Paused state with respect to a task associated with 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.	The agent is not working on any task or call associated with this skill group.
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 MRD.	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 MRD.

• How Agent States Are Calculated in Reports
• Agent States, Skill Groups, and Precision Queues
• Agent State and Task State Relationship
• Reports that Show Agent States

How Agent States Are Calculated in Reports

Agent States are presented in many reports as percentages.

Table 4 Calculations for agent state percentages

Table.Field	Calculation
%Active	Agent_Skill_Group_ Interval.TalkInTime + Agent_Skill_Group_ Interval.TalkOutTime + Agent_Skill_Group_ Interval.TalkOtherTime + Agent_Skill_Group_ Interval.TalkAutoOutTime + Agent_Skill_Group_ Interval.TalkPreviewTime + Agent_Skill_Group_ Interval.TalkReserveTime / Agent_Skill_Group__ Interval.LoggedOnTime
%BusyOther	Agent_Skill_Group _Interval.BusyOtherTime / Agent_Skill_Group_ Interval.LoggedOnTime
%Hold	Agent_Skill_Group_ Interval. HoldTime / Agent_Interval.LoggedOnTime
%NotActive	Historical: Agent_Skill_Group_ Interval.AvailTime / Agent_Interval.LoggedOnTime Real Time: Skill_Group_Real_Time.Avail / Skill_Group_Real_Time.LoggedOn
%Reserved	Agent_Skill_Group _ Interval.ReservedStateTime / Agent_Skill_Group _Interval.LoggedOnTime
%WrapUp	(Agent_Skill_Group _Interval.WorkReadyTime + Agent_Skill_Group_ Interval.WorkNotReadyTime ) / Agent_Skill_Group_Interval.LoggedOnTime)
%Not Ready	Agent_Skill_Group _Interval.NotReadyTime / Agent_Skill_Group_Interval.LoggedOnTime

Agent States, Skill Groups, and Precision Queues

Agents can belong to multiple skill groups or Precision Queues in an MRD. When an agent is handling a task that was routed to a skill group, the agent is Active in that skill group.

• For direct incoming calls or transferred 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 the first skill group defined for the agent.

If you are reporting on agents who handle chat tasks (and who can work on more than one task at a time), gather agent state information from both the Available in MRD and Agent State columns.

The agents' state in the active skill group or precision queue dictates their state in other skill groups or precision queues in the MRD to which they belong, as follows:

• If the agent is Active, Work Ready, Reserved, or Hold/Paused in one skill group or Precision Queue in the MRD, the agent state is Busy Other for all other skill groups or Precision Queues in the MRD.
• If the agent is Not Ready in one skill group or Precision Queue in the MRD, the agent is Not Ready in all skill groups or Precision Queues in the MRD.

Related Information

Reporting in a Multichannel Environment

Agent State and Task State Relationship

Agent state times are reported on interval boundaries regardless of whether or not the call or task is finished. 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 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 1. Agent state and task state relationship

If the interval 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 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.

Reports that Show Agent States

These are some reports that show information on Agent State:

• Unified IC Agent Team State Counts Real Time
• Unified IC Agent Real Time All Fields
• Unified IC Agent Historical All Fields

Agent Logout Reason Codes

Agent Logout Reason codes are defined in the agent desktop software and appear in historical reports as their numeric equivalent, with no text code. For example, if reason code 1 equals "end of shift" and the agent selects that reason for logging out, the report displays "1".

In addition to the codes configured at the desktop, some codes are generated automatically when the agent is logged out by the software. The following table describes these predefined Logout Reason codes.

Table 5 Agent 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.
50004	The agent was logged out due to agent inactivity as configured in agent desk settings.
50020	The agent was logged out when the agent's skill group assignment dynamically changed.
50030	The agent was logged out when the agent's skill group assignment dynamically changed on the Administration & DataServer.
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.

• Reports that Show Agent Logout Reason Codes

Reports that Show Agent Logout Reason Codes

These are some reports that contain information on Agent Logout reason codes:

• Unified IC Agent Real Time All Fields
• Unified IC Agent Not Ready Detail

Agent Not Ready Reason Codes

There are reports that show the codes agents select when entering Not Ready state, that calculate the percentage of time spent in the Not Ready state, and that show specific Not Ready reasons based on the time range you specify.

These reports help you identify whether agents are taking the appropriate number of breaks and whether their breaks are the appropriate length.

Some reports display both the text of the reason code (if configured) and the corresponding number. For example, if an agent enters Not Ready state and selects "Break" as the reason code, and if you have configured text for this code in Configuration Manager, reports display "Break [1]". Other reports display the numeric Not Ready reason code only.

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.

For Unified CC, in addition to Not Ready reason codes that you define, there are 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 6 Predefined Not Ready reason codes for Unified CC

Predefined Not Ready Reason Code	Description
50001	The CTI OS client disconnected, logging the agent out. Note    This reason code is converted to a 50002, so 50001 does not display in the agent log out records.
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	Agent was logged out because Unified CM reported the device out of service.
50004	Agent was logged out due to agent inactivity as configured in agent desk settings.
50005	For a Packaged CCE deployment where the Multi-line Agent Control is enabled in the peripheral, and the Multi-line Agent Behavior is configured to impact agent state, the Agent will be set to Not Ready with this code while talking on a call on the Non-ACD line.
50010	The agent did not receive multiple consecutive routed calls. 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.
50020	Agent was logged out when the agent's skill group dynamically changed on the Administration & Data Server.
50030	If an agent is logged in to a dynamic device target that is using the same dialed number (DN) as the PG static device target, the agent is logged out.
50040	Mobile agent was logged out because the call failed.
50041	Mobile agent state changed to Not Ready because the call failed when the mobile agent's phone line rang busy.
50042	Mobile agent was logged out because the phone line disconnected while using nailed connection mode.
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.
-1	Agent reinitialized (used if peripheral restarts).
-2	PG reset the agent, normally due to a PG failure.
-3	An administrator modified the agent's extension while the agent was logged in.

By default, predefined Not Ready reason codes do not have associated textual reason codes. They 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 gadget with the related text. For example, you might want to label the 32767 Not Ready reason code "Redirection on No Answer".

• Reports that Show Agent Not Ready Reason Codes

Reports that Show Agent Not Ready Reason Codes

These are some of the reports that contain information on Not Ready codes and the time spent as Not Ready:

• Unified IC (Intelligence Center) Agent Skill Group Real Time All Fields
• Unified IC Agent Skill Group Historical All Fields

Agent Task Handling

Agents can receive and place many different types of tasks. There are reports that show you what kind of tasks agents are handling and how well they are handling them. For example, there are reports that display statistics for calls placed, received, transferred, and conferenced, and there are reports that indicate how many calls were rerouted when the agent failed to answer the call.

• Types of Tasks
• Task Times
• Reports that Show Agent Task Handling

Types of Tasks

Tasks can be internal or external, incoming or outgoing.

• Internal tasks are calls made to an agent from another person or from another agent on Packaged CCE.
• External tasks are calls that are placed off the Packaged CCE, tasks that come in via CVP, , or tasks that are routed to an agent from a person outside Packaged CCE . For example, calls from the call center to customers are considered external.
• Incoming tasks are tasks that an agent receives. Multichannel tasks are always incoming.
• Outgoing tasks are calls 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.

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 those tasks are reported.

Table 7 Types of tasks

Type of task	Description	Reported As
Incoming direct/internal	Incoming Direct Tasks are tasks that come directly to the agent's extension. 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_Interval historical database table.	Internal In
Outgoing external	These are calls initiated by agents from their extension that are placed outside the contact center . Outgoing External Tasks are always voice tasks. Consultative, conference out, and transfer out calls are counted as outgoing external calls if they are placed outside the contact center or to remote agent extensions at another site. Agent-to-Agent dialing is outgoing external for the agent initiating the call if the call has to be placed outside the contact center to get to the destination agent. Data for these calls are stored in the AgentOutCalls fields of the Agent_Skill_Group_Interval historical database table.	External Out Tasks
Outgoing internal	These are calls initiated by agents from their extension to another extension within the contact center. Outgoing Internal Tasks are always voice tasks. Consultative, conference out, and transfer out calls are counted as outgoing internal calls if they are placed to another CVP. Agent-to-Agent calls are outgoing internal for the agent initiating the call. Data for these calls are stored in the InternalCalls fields of the Agent_Skill_Group_Interval historical database table.	Internal Out Tasks
Packaged CCE–routed calls	All calls that are routed to the agent. Outbound Option calls are considered Packaged CCE–routed/incoming calls. Data for these calls are stored in the CallsHandled fields of the Agent_Skill_Group_Interval historical database table.	Tasks Handled Tasks Handled includes all calls, including calls that are transferred and conferenced, and consultative calls. Tasks Handled provides a high level view of routed tasks. Other report columns such as Transfer In and Conf Out provide more details about how the task was handled.
Transferred in	Calls transferred to an agent from another agent. Calls that are blind transferred by one agent to CVP for re-routing are counted in this column for the agent who receives the rerouted call. Note    Data for these calls are stored in the TransferredIn fields of the Agent_Skill_Group_Interval historical database table.	Transfer In
Transferred out	Calls that are transferred from an agent. An agent can transfer both incoming and outgoing calls. Data for these calls are stored in the TransferredOut fields of the Agent_Skill_Group_Interval historical database table.	Transfer Out
Consultative	Calls in which an agent consulted with another agent or supervisor while having another call on hold. Data for these calls are stored in the ConsultativeCalls fields of the Agent_Skill_Group_Interval historical database table.	Cons Out
Conference in	Incoming calls that are conferenced. Data for these calls are stored in the ConferencedInCalls fields of the Agent_Skill_Group_Interval historical database table.	Conf In
Conference out	Outgoing calls that are conferenced. Data for these calls are stored in the ConferencedOutCalls fields of the Agent_Skill_Group_Interval historical database table.	Conf Out

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_Interval database table, as follows:

• Packaged CCE–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 HandledCallsTime 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 InternalCallsRcvdTime 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 AgentOutCallsTime field.
• Internal 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 InternalCallsTime field.
• 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 TransferredInCallsTime field.
• 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 TransferredOutCallsTime 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 ConsultativeCallsTime 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 ConferenceInCallsTime field.
• 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 ConferenceOutCallsTime 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 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 difference means that if an agent transfers an outgoing task to another agent, it is still considered an outgoing task.

Reports that Show Agent Task Handling

The Unified IC Agent Historical All Fields report contains information on Not Ready codes and the time spent as Not Ready.

Agent Utilization: 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 among skill groups and media can be difficult.

Report templates provide two types of statistics that give you a better view of how agents are being utilized and 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)

Percent utilization (% Utilization in reports) is computed in reports by dividing the total time agents spend handling calls in a skill group by the total time agents were ready to handle tasks. To calculate the time that an agent was ready, the system 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, the system 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 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, the system 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 resulting value will be lower than expected.

• Reports that Show Percent Utilization and FTE Metrics

Reports that Show Percent Utilization and FTE Metrics

These are some of the reports that contain operational information on Percent Utilization and FTE:

• Enterprise Skill Group Historical All Fields
• Peripheral Skill Group Historical All Fields Report
• Peripheral Skill Group Real Time All Fields Report
• Precision Queue Real Time All Fields
• Precision Queue Historical All Fields

Reports that Show Agent States

These are some reports that show information on Agent State:

• Unified IC Agent Team State Counts Real Time
• Unified IC Agent Real Time All Fields
• Unified IC Agent Historical All Fields

Reports that Show Agent Logout Reason Codes

These are some reports that contain information on Agent Logout reason codes:

• Unified IC Agent Real Time All Fields
• Unified IC Agent Not Ready Detail

Reporting on Agents

These are some Cisco Unified Intelligence Center reports relevant to agents.

Related References

Agent Team Reports

Reports that Show Agent States

Supervisor Action Reports

Reports that Show Percent Utilization and FTE Metrics

Skill Groups

A skill group is a collection of agents who share a common set of competencies that equip them to handle the same types of requests. Some examples of skill groups are a collection of agents who speak a specific language or who can assist callers with billing questions.

Each skill group belongs to a Media Routing Domain.

An agent can be a member of zero, one, or more skill groups.

To monitor agent performance, you can report on agents individually or you can report on all of the agents in one or more skill groups.

You can generate reports for skill groups that show agent activity (for example, the number of agents talking, available, or in wrap-up for a particular skill group).

In addition to generating Agent Skill Group reports, you can also use Skill Group reports to monitor operational performance. For example, you might want to see how a skill group is performing compared to other skill groups or to see if calls are being distributed evenly by your routing scripts and configuration.

• Default Skill Group
• Reports on Skill Group Operations

Default Skill Group

The default skill group acts as a bucket to capture information about voice calls and non-voice tasks.

• Role of Default Skill Group in Reporting
• How New Calls Increment Default Skill Group Statistics
• How Agent-to-Agent Dialing Increments Default Skill Group Statistics
• How Transferred and Conferenced Calls Increment Default Skill Group Statistics

Role of Default Skill Group in Reporting

The default skill group acts as a bucket to capture information in these situations:

• For calls that are not routed by Packaged CCE routing script
• If a skill group is not specified in a routing script
• If the Agent to Agent node is used in a routing script for agent-to-agent dialing
• When the Queue to Agent node queues a task to an agent and 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 Packaged CCE-routed calls, and
• Isolate/identify non- Packaged CCE-routed calls within the agent and skill group report.

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 a Packaged CCE system, default skill groups are created for each Media Routing Domain that is configured.

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 consultative 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 can not be referenced in any script.

How Agent-to-Agent Dialing Increments 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.

How Transferred and Conferenced Calls Increment Default Skill Group Statistics

The default skill group is also affected by transferred and conferenced calls. If agent A transfers or conferences a Packaged CCE/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 Packaged CCE-routed call. However, IncomingDirect calls for agent B are incremented against the default skill group.

However, if the agent (agent A) transfers or conferences a Packaged CCE/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 Packaged CCE/IPCC routed call. IncomingDirect 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.

Reports on Skill Group Operations

Use the skill group templates to gain insight into operations, to see how one skill group is performing compared to other skill groups, and to track whether calls are being distributed evenly by your routing scripts and configuration.

• You can report on all skill groups in Packaged CCE.
• You can report on call statistics by agent skill group assignments

Note	For agents in more than one skill group, you can also use the agent by skill group templates as a tool for monitoring agent performance.

• How Calls Offered is Calculated for Skill Group
• Reports that Show Skill Group Operations

How Calls Offered is Calculated for Skill Group

The completed state for RouterCallsOffered at the skill group is calculated using these fields from the Skill_Group_Interval table:

• RouterCallsAbandToAgent
• CallsHandled
• RouterCallsDequeued
• RedirectNoAnsCalls
• RouterError
• ReserveCalls
• RouterCallsAbandQ
• RouterCallsAbandDequeued

Reports that Show Skill Group Operations

These are some of the reports that contain operational information on Skill Groups:

• Peripheral Skill Group Historical All Fields
• Peripheral Skill Group Real Time All Fields

Agent Teams and Supervisors

This section provides information about agent teams and supervisors.

• Agent Teams and Supervisors
• Agent Team Reports
• Supervisor Action Reports
• Reporting on Supervisors
• Reports that Show Information on Agent Teams

Agent Teams and Supervisors

This section provides information about agent teams and supervisors.

Agent Team Reports

Supervisors can report on the agents in teams that they supervise to monitor the performance of a particular team.

You can select 0 or 1 primary supervisor for an agent team, and you can select multiple secondary supervisors for each team. Each supervisor can be a supervisor for multiple teams.

Supervisor Action Reports

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.

Note	These supervisory features are not available to agents using MRDs other than Voice.

• Supervisor Assist and Emergency Assist for Existing Call
• Barge-In
• Intercept
• Reports that Show Information on Agent Teams

Supervisor Assist and Emergency Assist for Existing Call

For Unified Intelligence Center, you can enable Supervisor Assist and Emergency Assist.

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.

Follow these guidelines to ensure that you can 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.
• 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.

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 the agent activates either the Supervisor or Emergency Assist desktop feature, the CTI software activates the conference key on behalf of the agent's phone and calls 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 8 Existing call: Consultative

Fields incremented for Agent's skill group to which the call was routed	Fields incremented for Supervisor's default 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.

Barge-In

When the supervisor activates the Barge-In desktop feature, 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.

Table 9 Supervisor Barge-In

Fields incremented for Agent's skill group to which the call was routed	Fields incremented for Supervisor's default skill 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 desktop button. 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.

Table 10 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

For the agent, the call is reported in the Intercept report field. For the supervisor, the call is reported in the Intercept report field.

Reports that Show Information on Agent Teams

These are some of the reports that contain information on Agent Teams

• Unified IC Agent Team Real Time All Fields
• Unified IC Agent Team Historical All Fields
• Agent Team State Counts Real Time

Reporting on Supervisors

These are some Cisco Unified Intelligence Center reports relevant to supervisors.

Related References

Agent Team Reports

Supervisor Action Reports

Reports that Show Percent Utilization and FTE Metrics

Reports that Show Agent Not Ready Reason Codes

Reports that Show Agent Logout Reason Codes

Reports on agent activity in skill groups

Reports that Show Information on Agent Teams

These are some of the reports that contain information on Agent Teams

• Unified IC Agent Team Real Time All Fields
• Unified IC Agent Team Historical All Fields
• Agent Team State Counts Real Time

Average Speed of Answer

Average Speed of Answer (ASA) is the average of the sum of the time that all incoming tasks to the service waited before being answered. This includes delay time, queue time, and ring time.

ASA starts when the call enters the queue and is set at these levels:

• Agent
• Skill Group
• Call Type
• Precision Queue

At the agent and skill group levels, the ASA metric is useful for monitoring agent and skill group performance.

At the Call Type level, the ASA metric provides insight into how callers experience the system and how quickly calls are being answered.

For Agents: The agent's average speed of answer in HH:MM:SS (hours, minutes, seconds) calculated by dividing the total time that callers spent in queue and while the call was ringing at the agent's desktop before the task is answered by the number of calls that the agent answered.

For Skill Groups: The skill groups's average speed of answer in HH:MM:SS (hour, minutes, seconds) calculated from the time spent by callers when placed in queue and ringing at the agent's desktop before the task is answered divided by the number of tasks answered.

For Call Types: The average answer wait time from when first queue to skill group or longest available agent (LAA) select node was executed for this call to when this call was answered. This is an important measure of service quality because the time can vary, even over the course of one day, due to call volumes and staff levels.

For Precision Queues: The Precision Queue's average speed of answer in HH:MM:SS (hour, minutes, seconds) calculated from the time spent by callers when placed in queue and ringing at the agent's desktop before the task is answered divided by the number of tasks answered.

• How ASA is Calculated
• ASA for Agent and Skill group
• ASA for Call Type

How ASA is Calculated

Calculations for ASA differ based on the type of system associated with the reporting object.

Table 11 Calculating ASA

Table.Field	Calculation
Skill_Group_Interval	Skill_Group_ Interval.AnswerWaitTime / Skill_Group_ Interval.CallsAnswered
CallType _Interval	Call_Type_ Interval.AnswerWaitTime / Call_Type_ Interval.CallsHandled
Call_Type_Skill_Group_Interval	Call_Type_Skill_Group_Interval. AnswerWaitTime / Call_Type_Skill_Group_Interval.CallsAnswered
Precision_Queue_Interval	Skill_Group.AnswerWaitTime / Skill_Group_Interval.CallsAnswered

ASA for Agent and Skill group

Agent. The ASA is calculated for the agent at the PG level.

The internal queuing time is sent to the PG by Packaged CCE when an agent becomes available for the call. The PG adds up the internal queue time, ring time, and network time and adds that into AnswerWaitTime in the agent skill group table. AnswerWaitTime is then divided by the CallsAnswered for the agent.

skill group. The ASA is calculated for the skill group at the PG level.

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.

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, and network time to create the total AnswerWaitTime for the call and adds it to AnswerWaitTime 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.

Precision Queue. The ASA is calculated for the Precision Queue by summing Skill Groups across PGs which are associated with the Precision Queue.

• Reports That Show ASA for Agents

Reports That Show ASA for Agents

These are some reports that show ASA statistics for Agents and Skill Groups:

• Unified IC Peripheral Skill Group Real Time All Fields
• Unified IC Peripheral Skill Group Historical All Fields

ASA for Call Type

The Call Type ASA is calculated as AnswerWaitTime divided by CallsAnswered.

Call Type ASA is applicable only when calls are translation routed and includes time spent in the Enterprise Queue as well as time spent in the ACD queue.

• Reports That Show ASA for Call Type

Reports That Show ASA for Call Type

The following report contains ASA statistics:

• Unified IC Call Type Historical All Fields

Requery

When a call is delivered to an agent that does not answer the call, Packaged CCE manages the call using a method called requery.

With requery, supervision of the call occurs from the start. There are timers for the call, including the time it went to an agent, came back, and got routed to another agent.

To use the Requery feature, enable the Target Requery setting in the Queue node. Requery is configured using a time set in CVP and CUCM. The CallType does not change and the call remains in the same script. CVP keeps control of the call during the requery process.

The following steps show a typical requery process.

1. A script connects a call to an agent by sending a connect message to CVP with requery enabled, and the requery timer begins.
2. The agent phone rings.
3. After the requery timeout expires on CVP, the call is pulled back from the agent and a message is sent to the router, indicating that the call is being requeried. The PG marks the agent as unavailable; the router then picks another target according to the routing script and directs CVP to connect the call to the new destination. The destination could be another agent or an IVR to requeue the call.

Best Practices for Requery

We advise you to use requery as the preferred method. Follow these guidelines to obtain accurate and useful data from requery.

• Within the routing script, enable the Target Requery option in the routing script. Target Requery is available from the Queue, Queue to Agent, Precision Queue, Label, Select, and RouteSelect nodes.
• Decide how long a call is to ring before being redirected to a new agent or skill group. Consider how requeried calls can affect the service level. In other words, make sure the service level threshold time is properly aligned with the CVP requery timeout.
• Plan to create a separate call type for requery situations. Using a separate call type enables you to report on activity for the requeried call type. Viewing data for this call type helps you determine the number of calls requeried and see how the calls are finally handled.
• If requery occurs from a queue node, the script execution takes the error path of the node that corresponds to the selected agent. In the script's error path of the queue node, change the call type.

Call Types

This section provides information about call types.

• Call Type Reports
• Call Types
• Call Type Reporting
• Reporting on Calls

Call Type Reports

Key statistics provided by service and call type reports include:

• Average Speed of Answer (ASA)
• Number of calls received, handled, and abandoned
• How long callers waited in queue
• Number of calls queued for an available agent
• Whether Service Level objectives are being met
• Whether the caller had to be transferred
• Number of callers who heard a busy signal
• Number of calls who encountered an error

Although skill group and agent reports provide many of these same metrics—such as ASA, Avg. Handle Time, abandons, redirects, and calls handled—the call type reports show these metrics in a format that gives a more complete picture of the customer experience and helps you review statistics organized by application.

Call Types

A call type is a category of incoming call. Based on the call type, the CallRouter selects the routing script that ultimately sends the call to an appropriate agent. Each call type has a schedule that determines which routing script or scripts are active for that call type at any time.

Call types are also the highest level reporting entity and are peripheral-independent.

There are two classes of call types: voice (phone calls) and non-voice (for example, email and text chat).

• Voice call types are categorized initially by the dialed number (DN) and, optionally, by the the calling line ID (CLID).
• Non-voice call types are categorized initially by the Script Type Selector and, optionally, Application String 1 and Application String 2.

Creating call types that correlate to the type of service the caller wants and changing call types during the script result in reporting statistics that reflect the customer's experience.

Note	Configuring a separate call type for each type of call treatment that you offer can eliminate the need for most custom reporting.

Note

The software allows routing that can offer calls simultaneously to multiple skill groups. The Call_Type_Skill_Group_Interval table records details for call types associated with specific skill groups. Reports generated from this table show how scripts routed the calls, as well as the calls associated with a skill group that encountered errors, that abandoned, that were redirected on no answer, and so forth.

• Best Practices for Call Types
• Changing Call Types

Best Practices for Call Types

Consider the call types you need to create to meet your reporting needs and configure a separate call type for each type of call treatment that you want to offer.

Based on the deployment model, scripting, queuing, and on whether or not calls are translation-routed, you can define call types to:

• Provide enterprise-wide routing statistics for the call center, such as the number of calls to be routed to different peripherals or the number of calls that encounter routing errors.
• Group calls to report on certain types of activity that occur within the contact center. For example, you might create separate call types for calls that redirect on no answer or calls that are transferred to another agent.
• Report on statistics for a self-service CVP application.

Do you want to configure a separate call type associated with call transfers and conferences?

Doing so enables you to direct the transfer to a different routing script.

Do you plan to report on individual transactions within Network CVP Self-Service or Information Gathering applications?

If so, you might configure a separate call type for each transaction.

Do you want to separate Information Gathering CVP metrics from queue metrics?

If so, you might configure a separate call type for queuing.

Do you want to configure a separate call type associated with 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.

Do you want to 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.

Do you want to determine the Service Level for call types?

Service Level indicates how well you are meeting your goal for answering calls.

You can configure the Service Level setting individually for each call type or set a global Service Level for all call types.

Do you want to configure abandoned short calls to filter out calls that abandon very quickly?

If you want to use abandoned short calls, configure the call type Abandon Wait Time in Configuration Manager. 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.

Do you want to define "bucket intervals" for reporting on answered and abandoned calls for the call type?

These "bucket intervals" appear in call type reports that display the number of calls answered and abandoned for each interval and are useful for monitoring when calls are abandoning or being answered.

Changing Call Types

Call type can be changed throughout the life of a call to direct the call to a new routing script or to gather report metrics for different legs or transactions.

Reasons for changing the call type within a routing script include the following:

• In a self-service CVP 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 an 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 CVP script 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.

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.

Service levels are defined only for call types associated with scripts that use the Queue To and LAA Select nodes.

Note	The call type changes depending on the following factors:

• TCD record for each leg of the call is associated with the last call type.
• When you use the Capture (CAP) micro-application, different TCD rows with multiple call types are populated.
• When a call is abandoned in a queue, the call type is not changed.

Call Type Reporting

The use of Call Type reports is based on the business need for your enterprise and is determined by how you plan to use the functionality provided by Packaged CCEsoftware.

Call Type reporting provides full customer experience in Unified CC, similar to Service reporting in Packaged CCE.

Call Type reports can be used for the following purposes:

• Calls answered by agents
• Calls abandoned at the CVP
• Calls that abandon while en-route to an agent or while being offered to an agent's phone
• Short calls
• Calls that are given the 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
• Cradle-to-grave reporting for call-handling statistics when calls are translation routed
• Reporting on calls grouped for the purposes of global call treatment
• Providing enterprise-wide routing statistics for your call center, such as the number of calls routed to different peripherals and the number of calls that encountered routing errors
• Reporting on statistics for a self-service CVP application
• Reporting on certain activities such as calls that are transferred, provided Call Types are configured for those activities

• How Calls Offered is Calculated for Call Type
• How Call Errors Affect Call Type Reporting
• How Calls with a Bad Label Affect Call Type Reporting
• How Calls that Experience CVP Ring No Answer Affect Call Type Reporting
• How Calls that Terminate Label Node and Route to Non-Monitored Devices Affect Reporting
• Call Type Reports

How Calls Offered is Calculated for Call Type

The completed state for CallsOffered at the Call Type is calculated using these fields from the Call_Type_Interval table:

• CallsHandled
• ErrorCount
• ICRDefaultRouted
• NetworkDefaultRouted
• ReturnBusy
• ReturnRing
• NetworkAnnouncement
• OverflowOut
• IncompleteCalls
• ShortCalls
• CallsRoutedNonAgent
• CallsRONA
• ReturnRelease
• AgentErrorCount
• TotalCallsAband

How Call Errors Affect Call Type Reporting

The way call errors increment the database depends on the following conditions:

• Calls that abandon en-route to the CCE/CVP 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 Communications Manager. These calls increment the ErrorCount column in the Call_Type tables. If the caller abandons within the Abandon Wait Time set for the call type, calls that abandon en-route to CVP might be counted as short calls, instead of as errors. See the next section for more information on abandoned short calls
• 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 in the Call_Type tables.

The Calls Error field in call type reports is a calculated field that combines both error columns. For example, the Calls Error field in the Call Type Historical All Fields report is derived from Call_Type_Interval.IncompleteCalls + Call_Type_Interval.AgentErrorCount.

How Calls with a Bad Label Affect Call Type Reporting

A bad label refers to an incorrectly configured 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 CVP Ring No Answer Affect Call Type Reporting

You can view a count of CVP Ring No Answer calls in agent and skill group reports.

The CVP Ring No Answer feature 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. Ring No Answer is also used to change the agent state to Not Ready when a call is rerouted from the agent's phone. The CVP Ring No Answer featuremakes the agent unavailable for routing requests. When the Packaged CCE CVP Ring No Answer timeout expires, the call is re-queried for routing to a different skill group or agent.

Note	The CVP Ring No Answer timeout must be less than 30 seconds because the 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.

You can configure the routing script to handle Ring 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 Ring No Answer affects the report data that you see, as follows:

• If you change the call type, 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. Using two call types enables you to identify Ring No Answer occurrences in call type reports. For example, if you create a specific call type for use in Ring 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 Unified 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 Unified ICM/CC 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.

Call Type Reports

The following reports display call type data:

• Unified IC Call Type Abandon/Answer Distribution Historical
• Unified IC Call Type Historical All Fields
• Unified IC Call Type Real Time All Fields

Reporting on Calls

Bucket Intervals

Bucket Intervals allow you to track data for calls abandoned or answered within specific time increments (for example, between 0 and 8 seconds, or under 60 seconds).

Bucket Intervals are associated with the following:

• Call Types
• Skill Groups
• Precision Queues

They can be set for the system as a whole and for individual call types. Local settings override those set at the system level.

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. Bucket 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, 90 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.

To avoid reporting inconsistencies, modify Bucket Interval settings only at specific time boundaries (that is, end of day, week, or month). Ensure that no one is running reports for the intervals that you are changing when you modify the boundaries.

Packaged CCE ships with a single System default Bucket Interval whose boundaries (increments) are: 8, 30, 60, 90, 120, 180, 300, 600, and 1200 (in seconds).

• Bucket Interval Reports

Bucket Interval Reports

The following reports display Bucket Interval data:

• Unified Intelligence Center: Call Type Abandon/Answer Distribution Historical
• Unified Intelligence Center: Call Type Historical All Fields Report
• Skill Group Abandon/Answer Distribution
• Precision Queue Abandon/Answer Distribution

Service Levels

Service levels help you set and measure goals for answering calls. Service levels are configurable; you can define them in different ways, depending on the kind of information you want them to provide.

• About Service Levels
• Service Level Relationships: MRD, Skill Groups, and Precision Queues

About Service Levels

All calls that have a service level event within a specified period are considered to be service level calls offered for that period. This designation differs from a call's offered value, which counts each call at the time it is first offered to the service.

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.

Two important configuration parameters contribute to the calculation of service level:

• Service level threshold - the number of seconds you set as a goal to treat a call. To calculate the service level for a period of time, Packaged CCE software determines the number of calls that have had a service level event within that interval.
• Service level type - the manner in which calls that abandon affect the service level.

• Service Level Threshold
• Service Level Type
• Service Level at Call Type
• Service Level at Skill Group
• Best Practices for Service Levels

Service Level Threshold

The service level threshold is the number of seconds you set as a goal for connecting a call with an agent.

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.

A service level threshold of 0 seconds means that no service level event will be set for the call; it will not be treated as a service level call.

Service Level Type

Service level type determines how calls that abandon before the service level threshold impact the service level calculation.

Service level type is presented as three options in the Configuration Manager: positively, negatively, or not at all.

• Abandoned calls positively impact 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 are considered to positively impact the service level.
• Abandoned calls negatively impact Other contact centers might consider only those calls answered within the service level threshold time as treated calls. For these contact centers, the service level is detrimentally affected by calls that abandon within the service level time. Abandoned calls negatively impact the service level.
• Ignore abandoned calls Others might choose to exclude the abandoned calls from the service level calculation (abandoned calls ignored).

The calculations for service level are based on the service level type defined for the service level configuration. They are described in the following table.

Table 12 Formulas for service level type

Service level type	Formula used to determine service level
Ignore abandoned calls	For Call Type and service: ServiceLevelCalls / (ServiceLevelCallsOffered – ServiceLevelAband)
Negative impact of abandoned calls	For Call Type and service: ServiceLevelCalls / (ServiceLevelCallsOffered)
Positive impact of abandoned calls	For Call Type and service (ServiceLevelCalls + ServiceLevelAband) / (ServiceLevelCallsOffered

For an example of how service level type is calculated, consider the following call counts:

• Answered within service level threshold (ServiceLevelCalls) = 70 calls
• Abandoned within service level threshold (ServiceLevelAband) = 10 calls
• Exceeded service level threshold (ServiceLevelCallsOffered – (ServiceLevelCalls + ServiceLevelAband)) = 20 calls
• Total service level events (ServiceLevelCallsOffered) = 100 calls

For these call counts, the service level is calculated for each type as follows:

Table 13 Calculations for service level

For this service level type:	The service level calculation is:
Abandoned calls ignored	70 / (100-10) = 77%
Abandoned calls negatively impact	70 /100 = 70%
Abandoned calls positively impact	(70 + 10) / 100 = 80%

Leave the Abandon Wait Time field blank if you prefer to not track abandoned calls.

Service Level at Call Type

For measuring overall customer experience, the call type provides the most insight into overall call treatment and how callers are experiencing the system.

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.

Only call types that are associated with scripts that use the Queue To nodes define service levels. If a call type is changed using the Requalify or Call Type nodes, then the service threshold timer is reset.

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 CVP 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 ServiceLevelCallsOffereddatabase 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.

If calls encounter an error before the Service level threshold expires, the ServiceLevelError database field is incremented, but ServiceLevelOffered is not incremented. If the call encounters an error after the service level threshold expires, ServiceLevelOffered is incremented.

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) In this example, abandoned calls have a negative impact. ServiceLevel = ServiceLevelCalls / (ServiceLevelCallsoffered – (AgentErrorCount + ErrorCount – ServiceLevelError))

Service Level at Skill Group

At the skill group level, the service level metric is useful for monitoring agent and skill group performance. The service level threshold timer at the skill group starts as soon as the call is queued to a skill group.

You can use Precision Queues to enhance or replace skill groups. For more information about Precision Queues, see Create Precision Queue.

Note	By default, the service level threshold for a skill group is set to the default value of the agent peripheral.

There are five service level events that can occur for the skill group:

• The call is answered by an agent before the service level threshold expires. In this case, the ServiceLevelsCallsOffered and ServiceLevelCalls database fields are incremented for the skill group that answered the call. If the call is queued to more than one skill group, then the 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 incremented. Calls may be dequeued using the 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 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.

Calls can queue to more than one skill group depending on your scripting, and service level metrics are updated for each skill group to which a single call queues.

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, ServiceLevelsCallsOffered and ServiceLevelCallsAband database fields are incremented for all the skill groups. This result will have a negative or positive impact on service levels in all the skill groups depending on how you have decided to treat abandoned 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, ServiceLevelsCallsOffered database field is incremented for all the skill groups. This result 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.

If you want to remove errors from ServiceLevelCallsOffered, you can use this formula in a custom report: ServiceLevelCallsOffered – (Errors – SLErrors).

Best Practices for Service Levels

Consider these guidelines when configuring and scripting service level:

• Service level time begins as soon as the call enters a Call Type. Set up Call Type scripts 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.
• Set up one Call Type to collect statistics before the queue (that is, the initial Call Type designated for the script via 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.
• Skill group/precision queue and service level metrics are updated for each skill group/precision queue 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/precision queue if you include abandons in your Service Level calculations and do not want abandons to affect Service Levels adversely.

If you follow these guidelines, 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/precision queue.

Service Level Relationships: MRD, Skill Groups, and Precision Queues

Service level setting for MRDs,skill groups, and Precision Queues are hierarchical and are interpreted as follows:

The MRD is the highest level. The default settings for the MRD are Service level threshold = 30 seconds and Service level type = Ignore Abandoned Calls. Ignore Abandoned Calls is the only value, and it is protected. Skill groups and Precision Queues inherit their values from the MRD, unless they are explicitly set. The default settings for both skill groups and Precision Queues are taken from the MRD, but you can override them.

Short Calls, Abandoned Calls, and Overflow Calls

This section provides information about short calls, abandoned calls, and overflow calls.

• Short Calls
• Abandoned Calls

Short Calls

A short call is a call that is either abandoned very quickly or answered and terminated very quickly. By defining what you believe to be a short call, you can filter out from reporting metrics those calls that did not stay in the system long enough to be considered and counted as events.

The Abandoned Call Wait timer defines the threshold under which the abandoned call will not be counted. If the abandoned threshold is lower than the service level threshold, the call will not affect the service level. If call wait time is higher than this threshold, the call is counted as Offered.

The Answered Short Call threshold defines the time under which the call will not be counted as answered and will not impact agent performance.

If you plan to use short calls to filter out false abandons or to detect when calls are answered and terminated too quickly to be considered handled, consider the following:

• You can configure abandoned short calls for the peripheral. These calls are tracked for the services that are configured for that peripheral.
• You can choose not to count any abandoned calls as short calls regardless of how quickly they abandon.
• You can choose how abandoned calls affect the service level—negatively, positively, or not at all.
• You cannot configure answered short calls for call type.
• You can choose not to count any answered calls as short calls regardless of how quickly they terminate.

Note	The concept of short calls applies to the Voice media class only.

To access these short call capabilities, refer to the following section.

Using Short Calls as Filters and Detection Devices

Perform these general steps:

1. Access the AW (DataServer).
2. Go into the Configuration Manager > Tools > Explorer Tools > PG Explorer.
3. Click Retrieve.
4. Expand Generic PG.
5. Click CUCM_PG#.

On the right side of the screen there is a group of tabs.

• Peripheral
• Advanced
• Agent Distribution
• Peripheral Monitor
• Default route
• Routing client
• Skill Group Mask

• Abandoned Short Calls
• Answered Short Calls
• Short Call Reports

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.

Answered Short Calls

Answered short calls reflect when a caller hangs up quickly if no agent answers the phone.

Answered short calls are reported for skill groups and agent skill groups.

The short call timer starts when the agent answers the call, and the CallsAnswered metric is updated for these calls.

The ShortCalls fields within the Skill_Group_Interval and Agent_Skill_Group_Interval tables are incremented if the Talk Time is less than the Answered short call threshold configured for the peripheral. The call is reported both as handled and as a short call.

If auto-answer is enabled for the agent, and if there are a high number of short calls within a certain interval, reporting on short calls can be used to determine which agents were not at their stations when a call was automatically answered. This conclusion assumes that the caller hangs up quickly when there is no agent on the phone.

Short Call Reports

A number of All Fields Reports contain a Short Tasks column to enable you to track calls that are offered but are neither handled nor abandoned.

The following reports display operational information on short calls:

• Unified Intelligence Center Agent Historical All Fields Report
• Unified Intelligence Center Call Type Historical All Fields Report
• Unified Intelligence Center Agent Skill Group Historical All Fields
• Precision Queue Historical All fields

Abandoned Calls

A call is considered abandoned if the caller hangs up before being connected to an agent. This includes situations where the caller hangs up while queued and waiting at the CVP. A high number of abandoned calls might be an indication that callers are waiting in the queue for too long.

Service reports provide cumulative statistics for all abandoned calls. Call Type reports provide additional visibility on where calls are abandoning.

Note	If a call abandons before the Abandon Call Wait Time threshold, it is considered a short call. For example, if you configure the abandoned call wait time for 10 seconds, and a caller disconnects at nine seconds, that call is a short call—it is not considered offered or abandoned.

To configure the Abandon Call Wait Time, access the Peripheral tab on the xyz screen. For more information about this procedure, go to Short Calls.

• How Abandoned Calls Affect Reporting
• How Abandoned Short Calls Affect Reporting
• Abandoned Call Reports

How Abandoned Calls Affect Reporting

There are three types of abandon metrics: abandon at the VRU (prompt or self service), abandon in queue, and abandon at the agent.

Packaged CCE/CC tracks the abandon counts for each of these abandon types 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, which 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 value is derived from the TotalCallsAband 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 interval. This value is derived from Call_Type_Interval.CallDelayAbandTime / Call_Type_Interval.TotalCallsAband.

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 value is tracked in the CTDelayTotalAbanTime database field. It 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

• CallDelayAbandTime = 45 seconds
• CTDelayTotalAbanTime = 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.

How Abandoned Short Calls Affect 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	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.

Abandoned Call Reports

The following reports display Abandon statistics for call types and services:

• CallType Abandon/Answer Distribution Historical
• CallType Historical All Fields
• CallType Real Time
• CallType SkillGroup Historical All Fields

Transfers and Conferencing

Voice calls can be transferred or conferenced. Non-voice tasks, such as email, chat, and Blended Collaboration tasks cannot be transferred and conferenced.

Transfers are blind. In a blind transfer, an agent transfers a call to another agent without first ensuring that another agent is available.

• About Transfers and Conferences
• Configuration and Scripting for Transfers and Conferences

About Transfers and Conferences

Packaged CCE supports transfers and conferences directly to agents and also to skill groups.

Follow these guidelines to obtain accurate and useful data from transfers and conferences:

• 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 such that when the call is transferred , it is directed 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.
• The agent can manually transfer the call to another agent or can conference in another agent by dialing that agent's extension directly on the ACD.
• The agent can use the ACD number to access a routing script on the ACD or can optionally post-route the call toPackaged CCE . The latter method is preferable, since Packaged CCE will be able to track the transferred calls and how they are handled across the enterprise. This also provides the ability to transfer the call to another ACD site. It is best to discourage direct agent-to-agent transfers, as one has to rely on the ACD for skill group and service assignment for the purposes of reporting. In situations where you are handling transfers and conferences on the ACD itself, use the ACD number to control how transfers are reported.

  Note	Packaged CCE will be unaware of a direct transfer if the agent extension is not configured.

If you are planning to provide for transfers and conference calls using post-routing, follow these guidelines to obtain accurate and useful data:

• Consider creating separate scripts for transfer and conference scenarios if you are post-routing all transfers and conferences.
• Plan to create a separate script for transfers on Packaged CCE that uses the dialed numbers you configured. Having a separate script on the ACD or onPackaged CCE allows you to track data across all known skill groups.

  Note	If you do not do this, the skill group affected by reporting statistics is unknown, and results are unpredictable.

Configuration and Scripting for Transfers and Conferences

Follow these guidelines when configuring and scripting for transfers and conferences to skill groups:

• Configure dialed numbers.

• Create new call types or identify existing call types and associate the call types with the Dialed Numbers.

• 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 call type with the routing script.

Operational Reporting

Operational reporting includes reports on translation routes, trunks, and trunk groups.

• Trunks and Trunk Groups

Trunks and Trunk Groups

Every peripheral has one or more associated trunk groups, with each trunk group containing one or more physical trunks.

You can report on data such as the number of trunks in service, number of trunks idle, and the time during which all trunks in a trunk group were simultaneously busy (All Trunks Busy).

The following report contains operational information on trunk groups:

• Unified Intelligence Center IVR Ports Performance Historical Report

IVR/VRU Self-Service

This section provides information about self service using Customer Voice Portal (CVP) for Interactive Voice Response ( IVR).

• About CVP
• CVP Application Reporting

About CVP

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

In Packaged CCE terms, CVPis a device that corresponds to a peripheral and is integrated by means of a PG.

Uses for CVP

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

• In Self-Service applications, the customer can obtain information through a series of CVP prompts, and the entire transaction occurs within the CVP . For example, if the customer calls a bank, the Self-Service application might prompt the user for an account number and password and then provide abilities to check account balance, review recent payments, modify PIN numbers, and so forth.
• In Information Gathering applications, the CVP prompts the caller for certain information, such as which department the caller wants to reach, and then uses the information in the routing decision and might pass the information to the agent desktop.
• CVP is also used to enterprise-queue calls while a customer waits for an available agent. During queuing, the CVP might be configured to play music on hold or perform a CVP application.

CVP Application Reporting

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

• Impact of CVP type on report data
• Self-Service, Information Gathering, and Queuing CVP Applications
• Monitoring Self-Service and Information Gathering Application Progress
• VRUProgress Variable
• Reports that Show VRU Metrics

Impact of CVP type on report data

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

For example:

• If your CVP performs queuing only, you might want to see how long callers waited in queue and the number of callers who abandoned while queued.
• If your CVP 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.

Self-Service, Information Gathering, and Queuing CVP Applications

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

You must be able to determine the following from 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

If there is IVR treatment before the call is queued, best practice is to change the call type just before queue node. Changing the call type will reset the service level timer and not include the IVR time. If you don’t change call types prior to the Queue to Skill Group node, the IVR treatment time will be included in the calculation of service level, having a negative impact on your service Level.See the following figure.

Figure 2. Changing a call type prior to the Queue to Skill Group node

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

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

Figure 3. Call Type data for calls that abandon after Call Type is changed

Note

If the call abandons before being requalified to the Call Type that handles queuing, the Call Abandon Wait time is not reset. Therefore, the Abandon Wait time for the information gathering Call Type starts when the call enters the first Call Type, and ends when the call abandons, as illustrated below:

Figure 4. Call Type for calls that abandon before Call Type is changed

The following table illustrates how some basic metrics are defined at the Call Type and the IVR Service.

Table 14 Self-service and information gathering application metrics

Report metric	Call type	VRU service	Skill group
Abandon Wait Time	Starts when a call first enters a Call Type and ends when it abandons.	Starts when the call enters the service.	Not Applicable
Average Speed of Answer (ASA)	Starts at the first Queue to Skill Group node in the routing script.	Starts at the first Queue to Skill Group node in the routing script.	Starts at the first Queue to Skill Group node in the routing script.
Service Level	Starts as soon as the call enters the Call Type that has the service level defined.	Starts when the call enters the service.	Not Applicable

Monitoring Self-Service and Information Gathering Application Progress

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

• Monitoring the effectiveness of the application as a whole. For example, you might only want to monitor whether a customer's need was satisfied through the CVP 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 CVP 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.

VRUProgress Variable

CVP applications are unique among call center applications in that the reports need to describe events that are application-specific, using application-specific terminology. Such reports vary widely from one customer to another and from one VRU application to another. Some customers only need to know how many CVP calls were satisfactorily handled by their CVP applications; others would like to track the usage and success rates of specific transactions within their CVP applications. Still others are interested in the actual series of activities performed by a specific caller and even the content of data collected or delivered.

The definition of a successfully handled call varies as well. In some cases a single transaction constitutes success. In others, each individual transaction has its own success criteria, and there might be several gradations of success. For example, some customers want to differentiate between calls in which no transactions were completed before transferring to an agent and calls in which one or more transactions were completed before transferring to an agent.

The system provides tools that customers can use as needed to meet these requirements

• The VRUProgress variable in the CallRouter call object
• Seven VRUProgress rollup buckets in the Call_Type_Interval table
• Reporting templates for reporting on Call_Type_Interval VRUProgress statistics
• A VRUProgress field in the Route_Call_Detail table

The following table describes the VRUProgress variables that you can use in your CVP script applications and how they map to report columns.

These VRUProgress variables map to columns that appear in CVP Activity 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.

Table 15 VRUProgress variable

Variable Setting in Script	Show in Reports as	Description
0	Not a VRU call—does not appear in reports	Indicates that this call is not a VRU call. It is the default value.
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.
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 transaction or to indicate changes in VRU status through the different transactions in the application.

Note

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 reports by monitoring statistics for the Call Type associated with the script.

Note

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 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 should have a different Call Type for each transaction with a related VRUProgress variable. This action 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 reports by monitoring statistics for the Call Types associated with those transactions.

Reports that Show VRU Metrics

This report shows metrics for VRU applications:

• Unified Intelligence Center IVR Ports Performance Historical Report

Data Loss and Component Failover

Packaged CCE uses sophisticated techniques in gathering and storing data. Due to the complexity of the system, the amount of data being gathered, the diversity of devices and peripherals, and the complex processes involved, it is possible that historical reports might present inconsistent data.

Although these reporting inconsistencies are confusing, most can be traced to temporary effects caused by time lags between the processes involved and nature of the data itself.

This section identifies and explains common conditions that lead to temporary and permanent inconsistencies in historical data. It discusses the potential effect of system failover on data that appears in reports and offers guidance on how to guard against data loss.

• Data flow for Reporting
• Methods to Prevent Data Loss from Logger and HDS Failure
• Data Loss from PIM Failure and Reporting
• Other Possible Points of Failover

Data flow for Reporting

Data is sent from the Call Router to the Logger. By default, reporting occurs directly from the Logger.

A Historical Data Server (HDS) is optional. If the HDS is configured, the Logger forwards historical data to the Historical Database Server in summary intervals.

• Recovery and Replication
• Possible Points of Delay or Inconsistency

Recovery and Replication

Recovery Keys

The recovery key is the base key for all historical data tables. This key is always incremented by 1 before a new record is inserted into any historical table.

In a duplex configuration, the Logger that finishes initializing first is designated the primary Logger (although both the Loggers are always active and working in parallel). The recovery key is always initialized by the primary Logger. The recovery key is based on the current GMT date and time and always has a value greater than any previous value generated. This helps the recovery process to keep the Loggers in sync.

The replication process may have a latency of about one to five minutes because the Logger replicates data table-by-table on the HDS.

Replication

The Replication process is responsible for replicating data that has been committed to the Logger Central database to the HDS database.

Note	The external HDS is an optional component. By default, reporting is done from the Logger.

The Replication mechanism consists of two processes: the Replication Server Process that runs on the Logger and the Replication Client Process that runs on the Distributor on which HDS has also been installed.

The Replication Client sends a request to the Replication Server requesting historical data that have associated Recovery Keys higher than those currently on corresponding historical tables. The Replication server sends the requested data back as a set of 2000 records each time.

The Replication server reads the historical data from the actual tables on the Logger and sends it to the Replication Client, which writes the historical data to the actual corresponding tables in the HDS database. Temporary tables are not used to replicate the data from the Logger to the HDS.

Possible Points of Delay or Inconsistency

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 and Logger B fails, the HDS does not connect to Logger A. 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 situation is temporary, and you will see the data once the replication process for the tables used by the reports is complete. If you are using a fault-tolerant system with two HDS Administration & Data Servers, you can run reports using the backup HDS while the primary HDS is not receiving data.

If the HDS goes offline and you are using a fault-tolerant system with two HDS Administration & Data Servers, you can run reports using the backup HDS. When the HDS comes back up, it recovers data from the last HDS data backup and 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 five minutes, data replication proceeds as usual.

Methods to Prevent Data Loss from Logger and HDS Failure

Data loss manifests as data holes, which are one or more missing records in an historical database table.

There are two types of data loss: temporary and permanent:

• A temporary data hole can happen during the Logger recovery process. For example, Logger A goes down, then comes back up and contacts Logger B to synchronize and recover historical data that was written while it was down. While this recovery process is going on, the reporting database on Logger A may have temporary data holes, which will be filled when the recovery process completes.
• A permanent data hole can happen during an Emergency Purge. For example, there can be permanent data loss if an emergency purge deletes records on one Logger that have not been sent to the other Logger or to the HDS.

Data Retention and Backups

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. You must manually restore the rest of the data from the last HDS backup.

CPU Utilization

It is possible that the process on one of the Loggers is slow because of space issues or an overload of the SQL Server. In this situation, the data on the Logger with the slower SQL Server will lag in persistence of the historical data with respect to the other Logger. This causes the HDS on the corresponding side to lag as well.

As a consequence, if both sides have an HDS set up and the same reports are run from both HDSs, the reports might differ. This is usually a temporary inconsistency, since the condition that causes the SQL server process to slow might be remedied. Autogrowing of the database and load conditions often remediate. The Loggers and the HDSs eventually catch up and are in sync. Running the reports later will result in consistent reports.

However, it the database server runs of disk space, the situation is quite serious and might cause data to be out of sync for a longer duration until the problem is remedied. A permanent loss of data can occur when data is purged from the peer Logger and never replicated on the slower side.

Scheduled Purge and Retention Settings on Loggers

The goal of the scheduled purge is to free up database space by purging the oldest data.

Emergency Purge

The Packaged CCE logger retention settings and database size are preconfigured to be able to ensure sufficient database space for the data, in the unlikely event that the Logger Central Database becomes full or reaches a configured threshold size. Its objective is to free up space by purging data from the historical tables so that the database has more free space than the allowed minimum.

The emergency purge goes through each historical table in a predefined order one at a time and purges one hour's worth of data from the table. As data is purged from each historical table, a check is made to verify if the free space is more than the minimum threshold value. Once adequate space has been recovered, the emergency purge procedure stops. Otherwise, it continues through to the next historical table and keeps looping as necessary.

Permanent loss of historical data can occur if the emergency purge removes historical data that has not yet made it to an HDS and has also not been replicated to the peer Logger that is "down" or in the recovery process.

Database used percentage is displayed as a normal status message in the replication process every few minutes. You can occasionally monitor this value to make sure that is does not grow too often or too fast. Emergency purge occurs when the percentage used is greater than the configured value (usually 90%).

Data Loss from PIM Failure and Reporting

Here are some reporting considerations when you experience data loss from UCM or CVP VRU PIM failure.

The Peripheral Interface Manager (PIM) is the process on the Peripheral Gateway responsible for the actual connection to the peripheral and for normalizing the CTI interface on behalf of Packaged CCE.

If a PIM fails, if the link between the PIM and the UCM or CVP goes down, or if the UCM or CVP goes down, then all of the reporting data that has been gathered for the peripheral associated with the PIM is deleted.

When the PIM failures occur, the peripheral is marked offline to the central controller.

For UCCE agent PG's, the state of all agents on that peripheral is set to logged out and is reported as such to the CallRouter.

When the PG is duplexed, either the Side A or Side B PIM is active for each peripheral. If one side loses connection, the other comes up and activates.

Other Possible Points of Failover

• Peripheral Gateway / CTI Manager Service Failover
• Agent Desktop / CTI OS Server Failover

Peripheral Gateway / CTI Manager Service Failover

If the agent's PG shuts down or the CTI Manager service 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.

Table 16 Agent State before and after Peripheral Gateway/CTI Manager Service failover

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.

Agent Desktop / CTI OS Server Failover

If the agent desktop (CTI OS desktop) shuts down or loses communication with CTI OS Server, or if CTI OS Server shuts down, the agent is logged out of all MRDs supported by the peripheral that has lost communication with Packaged CCE 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 failover depends on the agent's state when the failover occurred, as described in the following table.

Table 17 Agent State before and after Agent Desktop/CTI OS Server failover

Agent state at failover	Agent state after failover
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.

Call type and Skill Group Metrics

This section provides information about call type and skill group metrics.

• Call Type Real Time Table Metrics
• Network VRU and Skill Group Metrics

Call Type Real Time Table Metrics

The following table shows the fields in the Call_Type_Real_Time table that affect reporting metrics by metric category:

Table 18 Call_Type_Real_Time table and reporting metrics

Queued Metrics	At VRU Metrics/ Answered Metrics	Service Level Metrics	Abandoned Metrics
AvgRouterDelayQHalf AvgRouterDelayQNow AvgRouterDelayQTo5 AvgRouterDelayQToday CallsLeftQTo5 CallsAtVRUNow RouterCallsQNow RouterCallsQNowTime RouterLongestCallQ RouterQueueCallsHalf RouterQueueCallsTo5 RouterQueueCallsToday RouterQueueWaitTimeHalf RouterQueueWaitTimeTo5 RouterQueueWaitTimeToday ServiceLevelCallsQHeld	At CVP : CallsAtVRUNow Answered: AnsweredWaitTimeHalf AnswerWaitTimeTo5 AnswerWaitTimeToday CallsAnsweredHalf CallsAnsweredTo5 CallsAnsweredToday CallsAtAgentNow	ServiceLevelAbandHalf ServiceLevelAbandTo5 ServiceLevelAbandToday ServiceLevelCallsHalf ServiceLevelCallsTo5 ServiceLevelCallsToday ServiceLevelCallsOfferedHalf ServiceLevelCallsOfferedTo5 ServiceLevelCallsOfferedToday ServiceLevelHalf ServiceLevelTo5 ServiceLevelToday	CallDelayAbandTimeHalf CallDelayAbandTimeTo5 CallDelayAbandTimeToday CTDelayAbandTimeHalf CTDelayAbandTimeTo5 CTDelayAbandTimeToday DelayAgentAbandTimeHalf DelayAgentAbandTimeTo55 DelayAgentAbandTimeToday DelayQAbandTimeHalf DelayQAbandTimeTo5 DelayQAbandTimeToday RouterCallsAbandQHalf RouterCallsAbandQTo5 RouterCallsAbandQToday RouterCallsAbandToAgentHalf RouterCallsAbandToAgentTo5 RouterCallsAbandToAgentToday TotalCallsAbandHalf TotalCallsAbandTo5 TotalCallsAbandToday

The following table shows the fields (by metric category) in the Call_Type_Interval table that affect reporting metrics:

Table 19 Call_Type_Interval table and reporting metrics

Queued Metrics	At VRU Metrics/ Answered Metrics	Service Level Metrics	Abandoned Metrics
AvgRouterDelayQ CallsQHandled RouterQueueCalls RouterQueueCallType Limit RouterQueueGlobalLimit RouterQueueWaitTime	At CVP : CTVRUTime VRUTime Answered: AnsInterval1 - AnsInterval10 AnswerWaitTime CallsAnswered	ServiceLevelAband ServiceLevelCalls ServieLevelCallsOffered ServiceLevel	AbandInterval1 - AbandInterval10 CallDelayAbandTime CTDelayAbandTime DelayAgentAbandTime DelayQAbandTime RouterCallsAbandQ RouterCallsAbandToAgent TotalCallsAband

Network VRU and Skill Group Metrics

The Answer Wait Time and ASA metrics do not include the time spent in the network queue, while the Service Level metrics do.

The Skill Group abandoned metrics allow you to determine the number of calls that abandoned while queued, but they do not allow you to determine the number of calls that abandoned after they left the CVP and before an agent answered them.

Note	None of the Skill Group metrics include time spent in self-service or calls that ended during self-service because a call is not associated with a skill group until it is queued, and a call is queued after self-service is complete.

The following table shows the fields (by metric category) in the Skill_Group_Real_Time table that affect reporting metrics:

Table 20 Skill_Group_Real_Time table and reporting metrics

Queued Metrics	At CVP Metrics/ Answered Metrics	Service Level Metrics	Abandoned Metrics
CallsQueuedNow LongestCallQ RouterCallsQNow RouterLongestCallInQ	At CVP: None. Answered: AnswerWaitTimeTo5 CallsAnsweredTo5	ServiceLevelTo5 ServiceLevelCallsTo5 ServiceLevelCallsAbandTo5 ServiceLevelCallsDequeuedTo5 ServiceLevelRonaTo5 ServiceLevelCallsOfferedTo5	RouterCallsAbandQTo5 RouterCallsAbandToAgentTo5

The following table shows the fields (by metric category) in the Skill_Group_Interval table that affect reporting metrics:

Table 21 Skill_Group_Interval table and reporting metrics

Queued Metrics	At CVP Metrics/ Answered Metrics	Service Level Metrics	Abandoned Metrics
CallsQueued RouterQueueCalls	At CVP: None. Answered: AnswerWaitTime CallsAnswered	ServiceLevel ServiceLevelCalls ServiceLevelCallsAband ServiceLevelCallsDequeued ServiceLevelError	AbandonRingCalls AbandonRingTime RouterCallsAbandQ RouterCallsAbandToAgent

Reporting on Skill Groups

These are some Cisco Unified Intelligence Center reports relevant to skill groups.

• Peripheral Skill Group Historical All Fields
• Peripheral Skill Group Real Time All Fields

Reporting on Precision Queues

These Cisco Unified Intelligence Center reporting templates are new for Precision Routing:

• Agent Precision Queue Membership - This report displays selected agents, the media routing domain into which the agent is logged, and the active precision queue with up to five associated attributes.
• Precision Queue Real Time All Fields - This report displays the current status of selected precision queues.
• Precision Queue Historical All Fields - This report displays interval data for consolidated call and precision queue statistics.
• Agent Precision Queue Historical All Fields - This report displays activity for selected agents for a selected interval, sorted by precision queue.

These Cisco Unified Intelligence Center reporting templates contain updates for Precision Routing:

• Agent Real Time - This report displays, for each agent, the active skill group or active precision queue, the state, and the call direction within each media routing domain into which the agent is logged.
• Agent Team Real Time - This report displays the current status for each selected agent team and displays the current state and the active skill group or active precision queue for each agent in the selected agent teams.
• Call Type Queue Historical All Fields - This report displays the summary statistics for skill groups and precision queues within Call Type ID.