Report Template Reference Guide For Cisco Unified Intelligence Center, Release 9.0(2) - Unified ICM/Unified CCE reporting concepts [Cisco Unified Intelligence Center]

Abandoned Calls

A call is considered abandoned if the caller hangs up before connecting to an agent.

A high number of abandoned calls might be an indication that callers are waiting in the queue for too long.

Abandoned calls are reported against the following:

Service: Service reports provide cumulative statistics for all abandoned calls.
Call Types: Call Type reports provide additional visibility on where calls are abandoning.
Skill Groups: Skill Group reports provide additional visibility on where calls are abandoning.

Note

Calls that abandon before the Abandon Call Wait Time threshold are considered Short Calls. 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 and it is not considered offered or abandoned.

Agent states

The following states can appear in reports. A state with an asterisk (*) is a voice media only state.

Logged Off = 0
Logged On = 1
Not Ready = 2
*Ready = 3
*Talking = 4
Work Not Ready = 5
Work Ready = 6 - An agent doing wrap-up work (post-call activities, such as completing paperwork or consulting with associates) is in either the Work Ready or the Work Not Ready state.
Busy Other = 7
Reserved = 8
Unknown = 9
Hold (Calls On Hold) = 10
Active = 11
Paused = 12
Interrupted = 13
Not Active = 14

Average Speed of Answer

Average Speed of Answer (ASA), also called Average Answer Wait Time, is 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.

Answer Wait Time starts when the call enters the queue and is set at these levels: Agent, Skill Group, Call Type, and Service.

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

At the Call Type and Service levels, 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 (hour, minutes, seconds) is 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 Call Types: The average answer wait time from when first queue to skill group or 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 Routes: The average answer wait time, for all tasks offered to the route during the interval waited before being answered.

For Services:

(Hist) The average answer wait time for all tasks offered to the route during the interval waited before being answered.

(RT) The average speed of answer for all tasks associated with the service during the last five minutes waited before being answered.

For Skill Groups: The skill group'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.

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 call types and 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. Call type intervals provide additional insight into how long callers are waiting before their calls are answered or before they abandon.

For example, if your service level is two minutes, you might want to set up intervals for 30 seconds, one minute, 80 seconds, 120 seconds, 180 seconds, 210 seconds, and 240 seconds. Using these intervals, you can see whether calls are being answered in the thirty seconds after the service level threshold of 180 seconds or if most are waiting a full minute longer to be answered.

The intervals also give you insight into how long callers are willing to wait before abandoning. Perhaps many callers do not abandon until two minutes past the service level. This might indicate that you can modify your service level goal.

To avoid reporting inconsistencies, only modify Bucket Interval settings 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.

The Unified 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).

Call Detail Data

There are two database tables that store call detail, as follows:

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 the 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 ANI, any CEDs entered, and the type of request made. In addition, route call detail tells you how long the call was held in a enterprise queue.
Termination Call Detail A detailed termination call detail (TCD) data record is written for each call that arrives at a peripheral (provided the proper monitoring is enabled for the peripheral). The TCD record is written after the call segment terminates and the after-call work is complete. Specifically, the CallRouter creates the Termination_Call_Detail record when it receives a ClosedCallInd message from the Open Peripheral Controller (OPC). OPC generates the ClosedCallInd message when a call is terminated (that is, when any after-call work associated with the call is complete, or when a call that was not connected to an agent is terminated). 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 call's final disposition (that is, how the call terminated: abandoned in network, disconnect/drop, abandoned delay, and so forth). There can be many TCDs created per call, and it is possible for a call to have TCDs records but no RCD records. The Termination_Call_Detail table includes records that indicate which TCDs were used to create the Call Type 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.

Note

These two detail tables can become very large. You must extract the data from the HDS into your own custom database on a separate server (one that is not used for other Unified ICM/Unified CCE components). Use only DBDateTime (date and time of the record that was written to the HDS database) to perform the extraction. You can index the tables on the custom database according to the custom reporting needs.

To use Call Detail data in reports, you must create custom reports that populate from your custom database.

Call types

A call type is a category of incoming call. Based on the call type, the Router 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 anytime.

Call types are the highest level of reporting entity and the first reporting entity for which the Unified ICM captures data. You can also use them to provide cradle-to-grave reporting under certain circumstances and you can also use them to provide an enterprise view of applications in the call center.

Call type intervals

Call type intervals are specific time increments that allow you to see data for abandoned and answered calls.

A default set of intervals is provided at the system level, and you can configure call type intervals in relation to your service levels.

For example, if your service level threshold is 15 seconds and you want to see when callers are abandoning within that service level, you can set intervals of 5 seconds, 10 seconds, and 15 seconds.

If you do not configure intervals at the call type level, the system level intervals are used.

To configure call type intervals:

First use the Configuration Manager Bucket Interval configuration tool.
Then, using the Configuration Manger Call Type configuration tool for a given call type or the Configuration Manager System Information tool for system wide call types, assign intervals to individual call types.

Intervals are measured in minutes and seconds. The header time format is MM:SS.

Reports can show up to ten intervals. You can configure up to nine intervals with the tenth interval showing all the remaining data. Intervals not configured appear as blank intervals in the report and appear after the configured intervals.

No interval headers appear if the report is run over a period of time when no data is present. This happens because the report interval headers depend on the data being present.

Error count

The error count field increments when:

Translation-routed calls are abandoned while on route to destination target.
Calls with misconfigured labels use default routing. (In this case, the ICRDefaultRoutedToHalf field also increments.)
Calls with misconfigured labels do not use default routing (for instance, when a default route has not been defined).

FTE

The full-time equivalent (FTE in reports) is the number of full-time agents that are required to perform the work done during that interval for a skill group.

To calculate the FTE, Unified Intelligence Center divides the total time that work was performed by the total time in the interval. For example, if agents spent a total of three hours (180 minutes) handling tasks during a half-hour interval (30 minutes), the FTE for task handling during the interval is 180 minutes/30 minutes, which equals six full-time persons. This means that if all agents handled tasks full-time, six agents could complete the work.

HandleTime

HandleTime is the time spent from the call being answered by the agent to the time the agent completed after-call work time for the call.

This includes any HoldTime, TalkTime, and WorkTime associated with the call (from the Termination_Call_Detail table).

The HandleTime value is counted when the after-call work time associated with the call (if any) is completed.

Handled

A handled call is:

An incoming ACD call that was answered by an agent, and then completed.
A call associated with Outbound Option that the agent answered, and then completed.
A non-voice task that the agent started working on then completed.

A handled call/task is completed when the agent associated with the call/task finishes the wrap-up work associated with the call/task.

Historical and Interval Data

Unified ICM software stores some historical data in half-hour tables and other historical information in either half-hour or fifteen-minute summaries (but not both), based on Interval flags set in Configuration Manager. Parameters established during setup determine the retention of this data.

Note

All customers should choose an interval and stay with it, as changing back and forth between 15- and 30-minutes intervals impacts reporting.

As a best practice, run large historical reports at off-peak hours. Take advantage of the Scheduled Reports feature to do this.

Historical Data

Description

Interval (30- or 15-minute, based on configuration)

Some, but not all, Half_Hour tables now have an equivalent Interval table. The Half_Hour tables still appear in the database but are no longer populated.

Seven new Interval tables correspond to seven existing Half_Hour tables. Also one new Interval table (Call_Type_Skill_Group_Interval) corresponds to a new Call_Type_Skill_Group_Half_Hour table.

Eight Interval tables support fifteen-minute reporting if you configure the system for it. The equivalent Interval tables are populated by either 15- or 30-minute data, based on configuration.

Note

By default, data is captured in 30-minute intervals.

Fields in the Interval tables are no longer appended by ToHalf. For example, the Agent_Half_Hour table has a field named AvailTimeToHalf. In the Agent_Interval table, that field is named AvailTime.

Interval tables are:

Agent_Interval
Agent_Skill_Group_Interval
Peripheral_Interval
Service_Interval
Skill_Group_Interval
Call_Type_Interval
Call_Type_Skill_Group_Interval

Campaign_Query_Rule_Interval

Note

The Campaign_Query_Rule_Interval table has no interval configuration. Both the Campaign_Query_Interva; table and theCampaign_Query_Rule_Half_Hour table contain 30-minute data.

Half Hour

Those Half_Hour tables that do not have new Interval tables are only 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, if an error occurred at 15:47:00, it counts in the 15:30:00 to 15:59:59 half-hour interval. Data for this interval is not written to the database until the interval is complete (for example 16:00:00). Therefore, the latest error half-hour data is available for the previous completed interval (that is, the 15:00:00 to 15:29:59).

Grouped Grids

By default, all reports from stock templates appear in grid views (tables).

Click the Grouping button on the Views > Edit page to see or change report groupings.

Unified Intelligence Center supports four groupings (none, one, two, or three) and allows you to vertically-align the grouping value at the top, middle, or bottom of the report.

Reports with Grouped Grids
Support dynamic sorting.
Do not support options from the grouped columns.
Support thresholds.
Support summaries for up to three grouped columns in addition to a summary for the report as a whole.
Support rows per page.
Can include data about who ran the report and the filter used.

Media Routing Domain

A Media Routing Domain (MRD) is a collection of skill groups and services that are associated with a common media class.

The Unified ICM uses MRDs to organize how requests for different media are routed.

Each skill group is assigned to a MRD. The Unified ICM software uses MRDs to route a task to an agent who is associated with a skill group and a particular medium.

Each MRD belongs to a Media Class.

You can report on activity for all of the MRDs that you configure in your system. The Voice MRD is created by default for all deployments.

Overflow Out

The software keeps counts of the number of calls moved out of each service or route (overflowed out) and moved into each service or route (overflowed in).

Overflow Out is incremented when the one of the following occurs:

The call type associated with the current call is changed through use of a Call Type or Requalify node.
The call is sent to a label using a label node.
The call is redirected. When a call is redirected, the PIM no longer can receive events for the call and has no way of referencing or tracking the call. For example, the call might be redirected to a non-Unified ICM monitored device and then returned to the switch with a different call ID. The Unified ICM generates the termination call detail record with only the data originally tracked for the call. Calls marked as Redirected are counted as Overflow Out calls in the Unified ICM service and route tables.
The call was not default-routed, and the label was not a ring, busy, or announcement label.
The call hit a release node

In the Unified CCE, to more accurately reflect call status, CallDisposition is set to 15 (Redirected) instead of 4 (Abandon Delay) in the following cases:

When a call leaves a CTI route point to be sent to IVR.
When the agent transfers a call to another skill group, no agent is available, and the call is sent to IVR.

Percent utilization

Percent utilization (% Utilization in reports) is computed 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 Unified Intelligence Center subtracts the Not Ready time from the total time that agents were logged in. 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%.

Real-time data and real-time reports

In real-time, each PG passes current status information to Unified ICM software. This current (real-time) data, which is kept in the Router's memory, includes data about agents, skill groups, services, call types, trunk groups, and other entities.

Every 15 seconds (by default), the Router forwards the current (in-memory) data to the Distributor Admin Workstation, where it is stored on a number of real-time tables in the local Admin Workstation databases and distributed to the Client AWs.

Old real-time data is constantly overwritten by new real-time data.

Time Increment	Description
Half	Half values contain a value for the current half-hour. The current half-hour is defined as the time period falling between xx:00:00 and xx:29:59, or xx:30:00 and xx:59:59. For example, if it is currently xx:18:33, the CallsOfferedHalf real-time element contains a value that reflects the first 18 minutes and 33 seconds of the specific half-hour. When a new half-hour begins, at time (xx:00:00 or xx:30:00), the database element is reset to zero.
Now	Now contains a snapshot of the activity at a particular instant (the last check). For example, Unified ICM 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 left the queue. This change is seen at the next real-time update of the report screen.
To5	The To5 values track data on a rolling five-minute basis. The rolling five-minute data employs a sliding five-minute window. The To5 data is updated every three seconds. When the oldest three-second interval expires, a new three-second interval is added. In this manner, the window is always placed on the current five-minute interval.
Today	To arrive at values for Today, Unified ICM software adds the values at the end of each half-hour interval since midnight. It also counts the values for the current half-hour. At the end of each half hour, half-hour data (for example CallsOfferedHalf) is summed into the Today data. At midnight, the real-time Today count is cleared in the database. Midnight is defined using the time of the peripheral.

Real-time reports are generally small, with fewer than 20 rows. They are refreshed by default every 30 seconds. You can configure this refresh rate value on the Report Wizard Data Settings tab.

Redirection on No Answer

The Redirection on No Answer (RONA) feature ensures that if an agent does not answer a call within a configurable amount of time, the call is assigned to a different skill group or agent. The original agent is made Not Ready with a reason code of 32767 so that additional calls are not routed to that agent.

For agent reporting, you can see how many calls experienced RONA through the Redirect No Answer report field in agent and skill group reports. A high number of RONA calls for an agent might indicate that the agent is not responding quickly enough to incoming calls. If multiple agents have a high number of reroute on RONA, it might indicate that the Ring No Answer time is too low.

For call type reporting, the Calls RONA database field is updated for the call type when a call redirects on no answer. In Call Type reports, these calls are grouped into the Other category.

Service levels

The service level tells you what percentage of calls are answered within the amount of time specified in the service level threshold.

Service-level data is collected in the Unified ICM Schema database for call types, Media Routing Domains, peripherals, and skill groups. You can view this data in the Unified CCE reports.

Note

With the existence of a network VRU, when calls are translation-routed, the measurement of service level begins when the call arrives at the routing script, or when its call type is changed.

This means that if you perform self-service on a call before the call is queued to an agent, you must set up the routing script to change the call type of the call when self-service is completed. Otherwise, the time spent in self-service negatively impacts the service level.

Service-level threshold

Service-level threshold is the number of seconds set as the maximum time a caller should wait before being connected with an agent. Calls answered within the service-level threshold are considered to have met the service level, while calls not answered within the service-level threshold are considered not to have met the service level.

For example, if you set a service-level threshold of 30 seconds, you want all calls to be answered within 30 seconds. Every call answered within 30 seconds improves the service level. Every call that is not answered within 30 seconds reduces the service level.

Using 30 seconds as an example threshold, if you had 50 calls that were answered in under 30 seconds and 80 calls that took longer than 30 seconds to answer, then Unified ICM software, when ignoring abandoned calls, would calculate the service level as follows: 50/(50+80) x 100 = Service Level %.

In this example, the service level would be 38 percent.

You can compute the service level in three ways, depending on how calls that abandon before the service-level timer expires are treated. Each computation is described in the Unified ICM Service-Level Calculation section further on in this topic.

Service-level event

Calls are counted for service level purposes as soon as it is determined how the call contributes to the service-level calculation. This determination is made when either the call is answered, the caller abandons, or the service-level timer passes before the call is answered or abandoned - whichever occurs first.

Each of these events are called a service-level event:

The call is answered by an agent before the service-level threshold expires. In this case, the ServiceLevelCalls and ServiceLevelsCallsOffered database fields are incremented.
The call abandons or Re-routes on No Answer (RONAs) to IVR before the service-level threshold expires. In this case, the ServiceLevelAband and ServiceLevelCallsOffered database fields are incremented.
The call reaches the service-level threshold without being answered by an agent or abandoned. In this case, only the ServiceLevelCallsOffered database field is incremented.

Tasks that abandon before the short calls timer, as defined in the Unified ICM configuration, do not count towards the service level offered or service level abandoned call counters. Also, 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.

Enterprise service-level calculation

Any call that has a service-level event is treated as a service-level call offered, which means that it is used in the service-level calculation. Unified ICM software provides a uniform calculation across all peripherals.

You can calculate the enterprise service level in any of three ways:

Abandoned calls ignored. The number of calls answered within the service-level threshold divided by the number of calls that had a service-level event minus the number of calls that were abandoned before exceeding the service-level threshold. Calls abandoned before the service-level threshold expired are removed from this calculation.
Abandoned calls negatively impact service level. The number of calls answered within the service-level threshold divided by the number of calls that had a service-level event. This treats abandoned calls as though they had exceeded the service-level threshold.
Abandoned calls positively impact service level. The number of calls answered within the service-level threshold plus the number of calls abandoned within the threshold, all divided by the number of calls that had a service-level event. This treats abandoned calls as though they were answered within the service-level threshold.

The system administrator specifies which service-level calculation to use when they configure the peripheral service. Regardless of the service-level calculation method being used, the Unified ICM tracks the data needed to calculate the service level.

Peripheral service level

While Unified ICM software calculates its own service level, it also tracks, for some peripherals, the service level calculated by the peripheral. This service level, called the peripheral service level, is a proprietary service level as calculated by the peripheral. Some peripherals support more than one type of service-level calculation. The method of service-level calculation used by the peripheral is set by the System Manager when they configure the peripheral service.

Note

If Unified ICM software is connected to the Unified CCE through a Unified CCE Gateway PG, peripheral service levels are not applicable.

Configuring service levels

You can configure service-level calculations and their thresholds in the Unified ICM Configuration Manager.

Note

In the Unified ICM Configuration Manager, you configure the service level for the peripheral separately from that of the Unified ICM/Unified CCE service level (the service level for call types, services, and routes).

Service levels and skill groups

If agents log in to sub-priorities within a skill group, the service level LAA includes only those agents who are logged in to the Priority 1 skill level. All other agents in all other skill priorities are not considered in the service level LAA.

Example call type service level calculations

In an IP Contact Center environment, call types are used to calculate service levels. Call type reports display this service-level data.

The following are the service-level calculations for call types

SL Aban Ignored The Unified ICM/Unified CCE Enterprise service level where abandoned tasks are ignored. The calculation removes tasks abandoned after the service-level threshold for the interval. Derived from: (Call_Type_Interval.ServiceLevelCalls / (Call_Type_Interval.ServiceLevelCallsOffered -Call_Type_Interval.ServiceLevelAband))
SL Aban Positive The Unified ICM/Unified CCE Enterprise service level where abandoned tasks positively impact the service level. This calculation treats abandoned tasks as though they were connected within the service-level threshold for interval. Derived from: ((Call_Type_Interval.ServiceLevelCalls + Call_Type_Interval.ServiceLevelAband) / Call_Type_Interval.ServiceLevelCallsOffered)
SL Aban Negative The Unified ICM/Unified CCE Enterprise service level where abandoned tasks negatively impact the service level. This calculation treats abandoned tasks as though they had exceeded the service-level threshold for the interval. Derived from: (Call_Type_Interval.ServiceLevelCalls / Call_Type_Interval.ServiceLevelCallsOffered)

Example service level calculations

In a Unified ICM environment, services are used to calculate service levels. Service reports display this service-level data. These reports are not appropriate for IP Contact Centers.

The following are the service-level calculations for services:

SL Aban Ignored The Unified ICM/Unified CCE Enterprise service level where abandoned tasks are ignored. The calculation removes tasks abandoned after the service-level threshold for the interval. Derived from: (Service_Interval.ServiceLevelCalls / (Service_Interval.ServiceLevelCallsOffered -Service_Interval.ServiceLevelAband))
SL Aban Positive The Unified ICM/Unified CCE Enterprise service level where abandoned tasks positively impact the service level. This calculation treats abandoned tasks as though they were connected within the service-level threshold for the interval. Derived from: ((Service_Interval.ServiceLevelCalls + Service_Interval.ServiceLevelAbandToHalf) / Service_Half_Hour.ServiceLevelCallsOffered)
SL Aban Negative The Unified ICM/Unified CCE Enterprise service level where abandoned tasks negatively impact the service level. This calculation treats abandoned tasks as though they had exceeded the service-level threshold for the interval. Derived from: (Service_Interval.ServiceLevelCalls/ Service_Interval.ServiceLevelCallsOffered)

Services

For Unified ICM deployments, a service refers to a particular type of processing required by the caller. Services are configured to map to an application on the peripheral that provides the service. For example, a service on Unified ICM might map to an Application on Aspect or to a VDN on Avaya.

Every call routed to a peripheral must have an associated peripheral service. The application on the peripheral provides the call treatment, and Service reports are used to measure the customer experience across peripheral services.

A single peripheral might have several services defined such as Sales, Technical Support, and Customer Accounts.

You can determine the service level for a service as well as how abandoned calls impact the service level.

In an Unified CCE environment, calls are routed through IVRs rather than services. Therefore most service reports are not applicable in an Unified CCE environment. However, for both a Unified ICM environment and a Unified CCE environment, use the historical IVR peripheral service reports and the historical IVR trunk group reports for measuring the performance of your IVRs.

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.

You can configure the number of seconds for an abandoned short call and the number of seconds for an answered short call.

Skill groups

An agent skill group is a collection of agents at a single contact center who share a common set of competencies and can handle the same types of requests.

An enterprise skill group is a configured entity that serves to group a collection of skill groups on different peripherals. Configuring them allows you to report on skill groups across all ACDs, thus providing an enterprise view.

A peripheral skill group is a skill group associated with a specific single peripheral (ACD, PBX, IVR) in the contact center enterprise.

Abandoned Calls

A call is considered abandoned if the caller hangs up before connecting to an agent.

A high number of abandoned calls might be an indication that callers are waiting in the queue for too long.

Abandoned calls are reported against the following:

Service: Service reports provide cumulative statistics for all abandoned calls.
Call Types: Call Type reports provide additional visibility on where calls are abandoning.
Skill Groups: Skill Group reports provide additional visibility on where calls are abandoning.

Note

Calls that abandon before the Abandon Call Wait Time threshold are considered Short Calls. 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 and it is not considered offered or abandoned.

Agent states

The following states can appear in reports. A state with an asterisk (*) is a voice media only state.

Logged Off = 0
Logged On = 1
Not Ready = 2
*Ready = 3
*Talking = 4
Work Not Ready = 5
Work Ready = 6 - An agent doing wrap-up work (post-call activities, such as completing paperwork or consulting with associates) is in either the Work Ready or the Work Not Ready state.
Busy Other = 7
Reserved = 8
Unknown = 9
Hold (Calls On Hold) = 10
Active = 11
Paused = 12
Interrupted = 13
Not Active = 14

Average Speed of Answer

Average Speed of Answer (ASA), also called Average Answer Wait Time, is 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.

Answer Wait Time starts when the call enters the queue and is set at these levels: Agent, Skill Group, Call Type, and Service.

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

At the Call Type and Service levels, 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 (hour, minutes, seconds) is 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 Call Types: The average answer wait time from when first queue to skill group or 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 Routes: The average answer wait time, for all tasks offered to the route during the interval waited before being answered.

For Services:

(Hist) The average answer wait time for all tasks offered to the route during the interval waited before being answered.

(RT) The average speed of answer for all tasks associated with the service during the last five minutes waited before being answered.

For Skill Groups: The skill group'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.

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 call types and 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. Call type intervals provide additional insight into how long callers are waiting before their calls are answered or before they abandon.

For example, if your service level is two minutes, you might want to set up intervals for 30 seconds, one minute, 80 seconds, 120 seconds, 180 seconds, 210 seconds, and 240 seconds. Using these intervals, you can see whether calls are being answered in the thirty seconds after the service level threshold of 180 seconds or if most are waiting a full minute longer to be answered.

The intervals also give you insight into how long callers are willing to wait before abandoning. Perhaps many callers do not abandon until two minutes past the service level. This might indicate that you can modify your service level goal.

To avoid reporting inconsistencies, only modify Bucket Interval settings 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.

The Unified 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).

Call Detail Data

There are two database tables that store call detail, as follows:

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 the 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 ANI, any CEDs entered, and the type of request made. In addition, route call detail tells you how long the call was held in a enterprise queue.
Termination Call Detail A detailed termination call detail (TCD) data record is written for each call that arrives at a peripheral (provided the proper monitoring is enabled for the peripheral). The TCD record is written after the call segment terminates and the after-call work is complete. Specifically, the CallRouter creates the Termination_Call_Detail record when it receives a ClosedCallInd message from the Open Peripheral Controller (OPC). OPC generates the ClosedCallInd message when a call is terminated (that is, when any after-call work associated with the call is complete, or when a call that was not connected to an agent is terminated). 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 call's final disposition (that is, how the call terminated: abandoned in network, disconnect/drop, abandoned delay, and so forth). There can be many TCDs created per call, and it is possible for a call to have TCDs records but no RCD records. The Termination_Call_Detail table includes records that indicate which TCDs were used to create the Call Type 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.

Note

These two detail tables can become very large. You must extract the data from the HDS into your own custom database on a separate server (one that is not used for other Unified ICM/Unified CCE components). Use only DBDateTime (date and time of the record that was written to the HDS database) to perform the extraction. You can index the tables on the custom database according to the custom reporting needs.

To use Call Detail data in reports, you must create custom reports that populate from your custom database.

Call types

A call type is a category of incoming call. Based on the call type, the Router 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 anytime.

Call types are the highest level of reporting entity and the first reporting entity for which the Unified ICM captures data. You can also use them to provide cradle-to-grave reporting under certain circumstances and you can also use them to provide an enterprise view of applications in the call center.

Call type intervals

Call type intervals are specific time increments that allow you to see data for abandoned and answered calls.

A default set of intervals is provided at the system level, and you can configure call type intervals in relation to your service levels.

For example, if your service level threshold is 15 seconds and you want to see when callers are abandoning within that service level, you can set intervals of 5 seconds, 10 seconds, and 15 seconds.

If you do not configure intervals at the call type level, the system level intervals are used.

To configure call type intervals:

First use the Configuration Manager Bucket Interval configuration tool.
Then, using the Configuration Manger Call Type configuration tool for a given call type or the Configuration Manager System Information tool for system wide call types, assign intervals to individual call types.

Intervals are measured in minutes and seconds. The header time format is MM:SS.

Reports can show up to ten intervals. You can configure up to nine intervals with the tenth interval showing all the remaining data. Intervals not configured appear as blank intervals in the report and appear after the configured intervals.

No interval headers appear if the report is run over a period of time when no data is present. This happens because the report interval headers depend on the data being present.

Error count

The error count field increments when:

Translation-routed calls are abandoned while on route to destination target.
Calls with misconfigured labels use default routing. (In this case, the ICRDefaultRoutedToHalf field also increments.)
Calls with misconfigured labels do not use default routing (for instance, when a default route has not been defined).

FTE

The full-time equivalent (FTE in reports) is the number of full-time agents that are required to perform the work done during that interval for a skill group.

To calculate the FTE, Unified Intelligence Center divides the total time that work was performed by the total time in the interval. For example, if agents spent a total of three hours (180 minutes) handling tasks during a half-hour interval (30 minutes), the FTE for task handling during the interval is 180 minutes/30 minutes, which equals six full-time persons. This means that if all agents handled tasks full-time, six agents could complete the work.

HandleTime

HandleTime is the time spent from the call being answered by the agent to the time the agent completed after-call work time for the call.

This includes any HoldTime, TalkTime, and WorkTime associated with the call (from the Termination_Call_Detail table).

The HandleTime value is counted when the after-call work time associated with the call (if any) is completed.

Handled

A handled call is:

An incoming ACD call that was answered by an agent, and then completed.
A call associated with Outbound Option that the agent answered, and then completed.
A non-voice task that the agent started working on then completed.

A handled call/task is completed when the agent associated with the call/task finishes the wrap-up work associated with the call/task.

Historical and Interval Data

Unified ICM software stores some historical data in half-hour tables and other historical information in either half-hour or fifteen-minute summaries (but not both), based on Interval flags set in Configuration Manager. Parameters established during setup determine the retention of this data.

Note

All customers should choose an interval and stay with it, as changing back and forth between 15- and 30-minutes intervals impacts reporting.

As a best practice, run large historical reports at off-peak hours. Take advantage of the Scheduled Reports feature to do this.

Historical Data

Description

Interval (30- or 15-minute, based on configuration)

Some, but not all, Half_Hour tables now have an equivalent Interval table. The Half_Hour tables still appear in the database but are no longer populated.

Seven new Interval tables correspond to seven existing Half_Hour tables. Also one new Interval table (Call_Type_Skill_Group_Interval) corresponds to a new Call_Type_Skill_Group_Half_Hour table.

Eight Interval tables support fifteen-minute reporting if you configure the system for it. The equivalent Interval tables are populated by either 15- or 30-minute data, based on configuration.

Note

By default, data is captured in 30-minute intervals.

Fields in the Interval tables are no longer appended by ToHalf. For example, the Agent_Half_Hour table has a field named AvailTimeToHalf. In the Agent_Interval table, that field is named AvailTime.

Interval tables are:

Agent_Interval
Agent_Skill_Group_Interval
Peripheral_Interval
Service_Interval
Skill_Group_Interval
Call_Type_Interval
Call_Type_Skill_Group_Interval

Campaign_Query_Rule_Interval

Note

The Campaign_Query_Rule_Interval table has no interval configuration. Both the Campaign_Query_Interva; table and theCampaign_Query_Rule_Half_Hour table contain 30-minute data.

Half Hour

Those Half_Hour tables that do not have new Interval tables are only 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, if an error occurred at 15:47:00, it counts in the 15:30:00 to 15:59:59 half-hour interval. Data for this interval is not written to the database until the interval is complete (for example 16:00:00). Therefore, the latest error half-hour data is available for the previous completed interval (that is, the 15:00:00 to 15:29:59).

Grouped Grids

By default, all reports from stock templates appear in grid views (tables).

Click the Grouping button on the Views > Edit page to see or change report groupings.

Unified Intelligence Center supports four groupings (none, one, two, or three) and allows you to vertically-align the grouping value at the top, middle, or bottom of the report.

Reports with Grouped Grids
Support dynamic sorting.
Do not support options from the grouped columns.
Support thresholds.
Support summaries for up to three grouped columns in addition to a summary for the report as a whole.
Support rows per page.
Can include data about who ran the report and the filter used.

Media Routing Domain

A Media Routing Domain (MRD) is a collection of skill groups and services that are associated with a common media class.

The Unified ICM uses MRDs to organize how requests for different media are routed.

Each skill group is assigned to a MRD. The Unified ICM software uses MRDs to route a task to an agent who is associated with a skill group and a particular medium.

Each MRD belongs to a Media Class.

You can report on activity for all of the MRDs that you configure in your system. The Voice MRD is created by default for all deployments.

Overflow Out

The software keeps counts of the number of calls moved out of each service or route (overflowed out) and moved into each service or route (overflowed in).

Overflow Out is incremented when the one of the following occurs:

The call type associated with the current call is changed through use of a Call Type or Requalify node.
The call is sent to a label using a label node.
The call is redirected. When a call is redirected, the PIM no longer can receive events for the call and has no way of referencing or tracking the call. For example, the call might be redirected to a non-Unified ICM monitored device and then returned to the switch with a different call ID. The Unified ICM generates the termination call detail record with only the data originally tracked for the call. Calls marked as Redirected are counted as Overflow Out calls in the Unified ICM service and route tables.
The call was not default-routed, and the label was not a ring, busy, or announcement label.
The call hit a release node

In the Unified CCE, to more accurately reflect call status, CallDisposition is set to 15 (Redirected) instead of 4 (Abandon Delay) in the following cases:

When a call leaves a CTI route point to be sent to IVR.
When the agent transfers a call to another skill group, no agent is available, and the call is sent to IVR.

Percent utilization

Percent utilization (% Utilization in reports) is computed 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 Unified Intelligence Center subtracts the Not Ready time from the total time that agents were logged in. 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%.

Real-time data and real-time reports

In real-time, each PG passes current status information to Unified ICM software. This current (real-time) data, which is kept in the Router's memory, includes data about agents, skill groups, services, call types, trunk groups, and other entities.

Every 15 seconds (by default), the Router forwards the current (in-memory) data to the Distributor Admin Workstation, where it is stored on a number of real-time tables in the local Admin Workstation databases and distributed to the Client AWs.

Old real-time data is constantly overwritten by new real-time data.

Time Increment	Description
Half	Half values contain a value for the current half-hour. The current half-hour is defined as the time period falling between xx:00:00 and xx:29:59, or xx:30:00 and xx:59:59. For example, if it is currently xx:18:33, the CallsOfferedHalf real-time element contains a value that reflects the first 18 minutes and 33 seconds of the specific half-hour. When a new half-hour begins, at time (xx:00:00 or xx:30:00), the database element is reset to zero.
Now	Now contains a snapshot of the activity at a particular instant (the last check). For example, Unified ICM 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 left the queue. This change is seen at the next real-time update of the report screen.
To5	The To5 values track data on a rolling five-minute basis. The rolling five-minute data employs a sliding five-minute window. The To5 data is updated every three seconds. When the oldest three-second interval expires, a new three-second interval is added. In this manner, the window is always placed on the current five-minute interval.
Today	To arrive at values for Today, Unified ICM software adds the values at the end of each half-hour interval since midnight. It also counts the values for the current half-hour. At the end of each half hour, half-hour data (for example CallsOfferedHalf) is summed into the Today data. At midnight, the real-time Today count is cleared in the database. Midnight is defined using the time of the peripheral.

Real-time reports are generally small, with fewer than 20 rows. They are refreshed by default every 30 seconds. You can configure this refresh rate value on the Report Wizard Data Settings tab.

Redirection on No Answer

The Redirection on No Answer (RONA) feature ensures that if an agent does not answer a call within a configurable amount of time, the call is assigned to a different skill group or agent. The original agent is made Not Ready with a reason code of 32767 so that additional calls are not routed to that agent.

For agent reporting, you can see how many calls experienced RONA through the Redirect No Answer report field in agent and skill group reports. A high number of RONA calls for an agent might indicate that the agent is not responding quickly enough to incoming calls. If multiple agents have a high number of reroute on RONA, it might indicate that the Ring No Answer time is too low.

For call type reporting, the Calls RONA database field is updated for the call type when a call redirects on no answer. In Call Type reports, these calls are grouped into the Other category.

Service levels

The service level tells you what percentage of calls are answered within the amount of time specified in the service level threshold.

Service-level data is collected in the Unified ICM Schema database for call types, Media Routing Domains, peripherals, and skill groups. You can view this data in the Unified CCE reports.

Note

With the existence of a network VRU, when calls are translation-routed, the measurement of service level begins when the call arrives at the routing script, or when its call type is changed.

This means that if you perform self-service on a call before the call is queued to an agent, you must set up the routing script to change the call type of the call when self-service is completed. Otherwise, the time spent in self-service negatively impacts the service level.

Service-level threshold

Service-level threshold is the number of seconds set as the maximum time a caller should wait before being connected with an agent. Calls answered within the service-level threshold are considered to have met the service level, while calls not answered within the service-level threshold are considered not to have met the service level.

For example, if you set a service-level threshold of 30 seconds, you want all calls to be answered within 30 seconds. Every call answered within 30 seconds improves the service level. Every call that is not answered within 30 seconds reduces the service level.

Using 30 seconds as an example threshold, if you had 50 calls that were answered in under 30 seconds and 80 calls that took longer than 30 seconds to answer, then Unified ICM software, when ignoring abandoned calls, would calculate the service level as follows: 50/(50+80) x 100 = Service Level %.

In this example, the service level would be 38 percent.

You can compute the service level in three ways, depending on how calls that abandon before the service-level timer expires are treated. Each computation is described in the Unified ICM Service-Level Calculation section further on in this topic.

Service-level event

Calls are counted for service level purposes as soon as it is determined how the call contributes to the service-level calculation. This determination is made when either the call is answered, the caller abandons, or the service-level timer passes before the call is answered or abandoned - whichever occurs first.

Each of these events are called a service-level event:

The call is answered by an agent before the service-level threshold expires. In this case, the ServiceLevelCalls and ServiceLevelsCallsOffered database fields are incremented.
The call abandons or Re-routes on No Answer (RONAs) to IVR before the service-level threshold expires. In this case, the ServiceLevelAband and ServiceLevelCallsOffered database fields are incremented.
The call reaches the service-level threshold without being answered by an agent or abandoned. In this case, only the ServiceLevelCallsOffered database field is incremented.

Tasks that abandon before the short calls timer, as defined in the Unified ICM configuration, do not count towards the service level offered or service level abandoned call counters. Also, 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.

Enterprise service-level calculation

Any call that has a service-level event is treated as a service-level call offered, which means that it is used in the service-level calculation. Unified ICM software provides a uniform calculation across all peripherals.

You can calculate the enterprise service level in any of three ways:

Abandoned calls ignored. The number of calls answered within the service-level threshold divided by the number of calls that had a service-level event minus the number of calls that were abandoned before exceeding the service-level threshold. Calls abandoned before the service-level threshold expired are removed from this calculation.
Abandoned calls negatively impact service level. The number of calls answered within the service-level threshold divided by the number of calls that had a service-level event. This treats abandoned calls as though they had exceeded the service-level threshold.
Abandoned calls positively impact service level. The number of calls answered within the service-level threshold plus the number of calls abandoned within the threshold, all divided by the number of calls that had a service-level event. This treats abandoned calls as though they were answered within the service-level threshold.

The system administrator specifies which service-level calculation to use when they configure the peripheral service. Regardless of the service-level calculation method being used, the Unified ICM tracks the data needed to calculate the service level.

Peripheral service level

While Unified ICM software calculates its own service level, it also tracks, for some peripherals, the service level calculated by the peripheral. This service level, called the peripheral service level, is a proprietary service level as calculated by the peripheral. Some peripherals support more than one type of service-level calculation. The method of service-level calculation used by the peripheral is set by the System Manager when they configure the peripheral service.

Note

If Unified ICM software is connected to the Unified CCE through a Unified CCE Gateway PG, peripheral service levels are not applicable.

Configuring service levels

You can configure service-level calculations and their thresholds in the Unified ICM Configuration Manager.

Note

In the Unified ICM Configuration Manager, you configure the service level for the peripheral separately from that of the Unified ICM/Unified CCE service level (the service level for call types, services, and routes).

Service levels and skill groups

If agents log in to sub-priorities within a skill group, the service level LAA includes only those agents who are logged in to the Priority 1 skill level. All other agents in all other skill priorities are not considered in the service level LAA.

Example call type service level calculations

In an IP Contact Center environment, call types are used to calculate service levels. Call type reports display this service-level data.

The following are the service-level calculations for call types

SL Aban Ignored The Unified ICM/Unified CCE Enterprise service level where abandoned tasks are ignored. The calculation removes tasks abandoned after the service-level threshold for the interval. Derived from: (Call_Type_Interval.ServiceLevelCalls / (Call_Type_Interval.ServiceLevelCallsOffered -Call_Type_Interval.ServiceLevelAband))
SL Aban Positive The Unified ICM/Unified CCE Enterprise service level where abandoned tasks positively impact the service level. This calculation treats abandoned tasks as though they were connected within the service-level threshold for interval. Derived from: ((Call_Type_Interval.ServiceLevelCalls + Call_Type_Interval.ServiceLevelAband) / Call_Type_Interval.ServiceLevelCallsOffered)
SL Aban Negative The Unified ICM/Unified CCE Enterprise service level where abandoned tasks negatively impact the service level. This calculation treats abandoned tasks as though they had exceeded the service-level threshold for the interval. Derived from: (Call_Type_Interval.ServiceLevelCalls / Call_Type_Interval.ServiceLevelCallsOffered)

Example service level calculations

In a Unified ICM environment, services are used to calculate service levels. Service reports display this service-level data. These reports are not appropriate for IP Contact Centers.

The following are the service-level calculations for services:

SL Aban Ignored The Unified ICM/Unified CCE Enterprise service level where abandoned tasks are ignored. The calculation removes tasks abandoned after the service-level threshold for the interval. Derived from: (Service_Interval.ServiceLevelCalls / (Service_Interval.ServiceLevelCallsOffered -Service_Interval.ServiceLevelAband))
SL Aban Positive The Unified ICM/Unified CCE Enterprise service level where abandoned tasks positively impact the service level. This calculation treats abandoned tasks as though they were connected within the service-level threshold for the interval. Derived from: ((Service_Interval.ServiceLevelCalls + Service_Interval.ServiceLevelAbandToHalf) / Service_Half_Hour.ServiceLevelCallsOffered)
SL Aban Negative The Unified ICM/Unified CCE Enterprise service level where abandoned tasks negatively impact the service level. This calculation treats abandoned tasks as though they had exceeded the service-level threshold for the interval. Derived from: (Service_Interval.ServiceLevelCalls/ Service_Interval.ServiceLevelCallsOffered)

Services

For Unified ICM deployments, a service refers to a particular type of processing required by the caller. Services are configured to map to an application on the peripheral that provides the service. For example, a service on Unified ICM might map to an Application on Aspect or to a VDN on Avaya.

Every call routed to a peripheral must have an associated peripheral service. The application on the peripheral provides the call treatment, and Service reports are used to measure the customer experience across peripheral services.

A single peripheral might have several services defined such as Sales, Technical Support, and Customer Accounts.

You can determine the service level for a service as well as how abandoned calls impact the service level.

In an Unified CCE environment, calls are routed through IVRs rather than services. Therefore most service reports are not applicable in an Unified CCE environment. However, for both a Unified ICM environment and a Unified CCE environment, use the historical IVR peripheral service reports and the historical IVR trunk group reports for measuring the performance of your IVRs.

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.

You can configure the number of seconds for an abandoned short call and the number of seconds for an answered short call.

Skill groups

An agent skill group is a collection of agents at a single contact center who share a common set of competencies and can handle the same types of requests.

An enterprise skill group is a configured entity that serves to group a collection of skill groups on different peripherals. Configuring them allows you to report on skill groups across all ACDs, thus providing an enterprise view.

A peripheral skill group is a skill group associated with a specific single peripheral (ACD, PBX, IVR) in the contact center enterprise.