Call Types and Services

Call Type and Service 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 was transferred

  • Number of callers who heard a busy signal

  • Number of calls who encountered an error

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 and service reports show these metrics in a format that gives a more complete picture of the customer experience. The call type reports also 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 transfers 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 nonvoice (for example, email and text chat).

  • Voice call types are categorized initially by the dialed number (DN) and, optionally, by the caller-entered digits (CED) and the calling line ID (CLID).

  • Nonvoice call types are categorized initially by the Script Selector. For Enterprise Chat and Email, call types also can be optionally categorized by Application String 1 and 2.

For reporting statistics that reflect the customer's experience, create call types that reflect the caller's needs and change call types during the call when necessary.


Note


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

Note


  • Call types cannot span ACDs and PGs. If your system uses both Unified CCE components and legacy ACDs, create separate call types for the ACDs and the Unified CCE components.

  • 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 and other call-handling issues.

  • The system does no create or report Call Type Skill Groups records if they exceed the Call Type Skill Group limit. Routing of contacts continues even when you exceed this limit. To view the limits, see the Solution Design Guide for Cisco Unified Contact Center Enterprise at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-implementation-design-guides-list.html.


Guidelines for Call Types

Consider the call types that 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 calls are translation-routed, you can define call types to:

  • Provide enterprise-wide routing statistics for the call center. For example, the number of calls to route 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 VRU 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 VRU 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 VRU metrics from queue metrics?

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

Do you plan to use Outbound Option?

If so, create a separate call type for Outbound Option calls. Outbound Option uses a routing script in addition to a physical call to reserve agents. The call type real-time and half-hour reports contain data that pertains only to reservation calls and do not include reporting information for any outbound calls.

Do you want to configure a separate call type associated with RONA situations?

If you configure a separate call type associated with RONA, you can direct calls that Ring No Answer to a routing script designed for this situation. You can report on this Redirection on No Answer call type to see how calls that redirect on no answer are eventually handled.

You can also handle this situation with requery.

Do you want to determine the service level for call types?

Service level indicates how well you meet 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 quickly?

If you want to use abandoned short calls, configure the call type Abandon Wait Time. 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 (Unified CCE)?

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

Changing Call Types

You can change call type throughout the life of a call. You can 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 network VRU application script, you might change the call type at specific points in the script to indicate that a transaction is complete.

    For example, if the customer calls a bank and successfully checks an account balance using a Self-Service script, you might change the call type to indicate that the account balance transaction is complete and a new transaction is started. In this case, you create a call type for each transaction on which you want to report.

  • You might change the call type when a call enters a queue at the end of an Information Gathering VRU application in order to separate Information Gathering and queuing metrics. In this case, you would create call types associated with the Information Gathering applications and call types associated with queuing.

The service level threshold timer at the call type starts when 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


If you use Unified CVP, the call type changes depending on the following factors:
  • When you use a single CVP, the TCD record for each leg of the call is associated with the last call type.

  • When you use multiple CVPs and VRUs, the controlling VRU (for example, CVP1) receives the updated call type in the last connect message. The call type of CVP2 is the same as the call type associated when the agent had received the call.

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

Enterprise Routing and Enterprise Reporting for Calls (Unified CCE)

When Unified CCE receives a route request for a call, it first determines the call type, finds the script currently scheduled for that call type, and routes the call to the desired destination (for example, to a service, skill group, agent, or announcement).

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

For legacy ACDs where Unified CCE software is used for Enterprise Routing, consider the following to ensure that your reports contain correct and relevant metrics:

  • Ensure all calls are routed by Unified CCE software.

  • Deploy a Service Control VRU to provide treatment and to queue calls in the enterprise while waiting for an available agent in a skill group. Queue calls to skill groups in Unified CCE (Enterprise Queuing) for all call centers. Avoid using ACD queues (site queues).

  • Use Translation Routes for routing calls to the legacy ACD. Always use translation routing when routing calls between ACDs.

  • Once the call is routed and is terminated on the legacy ACD, have no treatment at the ACD.

  • Avoid having agents transfer calls directly to other agent stations or agent IDs. Instead, use post routing capabilities to provide treatment and queuing for transferred calls.

  • Avoid handling RONA situations on the ACD, where possible. Instead, use post-routing capabilities to have the RONA calls routed by Unified CCE.

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 Unified CCE Packaged CCE software.

Call type reporting provides full customer experience in Unified CCE, similar to Service reporting in Unified ICM.

Call type reports can be used for the following purposes:

  • Calls answered by agents

  • Calls abandoned at the VRU

  • Calls that abandon while en-route to an agent or while being offered to an agent's phone

  • Short calls

  • Calls that are given 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

  • Reporting on Enterprise Queuing statistics

  • 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 VRU , if a Network VRU is deployed

  • Reporting on certain activities such as calls that are transferred, provided call types are configured for those activities

Call Type Reporting and Outbound Option Campaigns

You can use call type reporting on Outbound Option reservation calls and transfer to IVR calls. However, because a routing script is not used for the outbound call to the customer, call type reporting is not applicable for the customer call.

Call Type Reporting in Parent/Child Deployment

Call Type reports on the Unified CCE parent help to determine the following:

  • Number of calls received by the call type to route to different peripherals (example: multiple Unified CCE children, or different ACDs)

  • Number of calls routed to different peripherals (example: multiple children, or different ACDs)

  • Number of calls that encountered routing errors

However, there are a limited number of scenarios where you can use Call Type reports to measure customer experience at the parent:

  • If you use translation routing at the parent, certain Call Type reports might be useful in measuring customer experience associated with those translation routed calls.

  • If you use a network VRU at the parent for network queuing or network prompting, the Call Type reports are useful to provide information on the calls handled by the VRU applications. The Call Type reports also provide the queuing statistics. In a Contact Center Gateway deployment, if you queue the calls at the network, use Call Type reports on the parent to report on the queuing statistics. The number of calls queued and the network queue time is not available at the child.

Calls Offered Calculation 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 VRU/CCE scripts are calls that abandon in the network while they are being sent to the VRU. An example of this condition is if a call abandons while it is sent to the VRU from a CTI Route point in Unified Communications Manager. These calls increment the ErrorCount column in the Call_Type tables.

    If the caller abandons within the Abandon Wait Time, calls that abandon en route to the VRU might be counted as short calls, instead of as errors.

    If an on-premise VRU is used, then the probability of calls abandoning en route to the VRU is low.

  • Calls that abandon en route to agents are calls that encounter an error when the call is at the agent desktop. This call is counted as part of the AgentErrorCount 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. Calls that do encounter an incorrectly configured label can at least go to the default label and get handled and 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.

  • The label points to the wrong agent: In this case, the pre-call message is sent to one agent, but the actual call is sent to a different agent. This call is reported as an incomplete call.

If the node does not define a label, the call encounters error conditions and is reported as an error.

How Calls That Experience Redirection on No Answer with IP IVR Affect Call Type Reporting

Redirection on No Answer calls are calls that redirect off the agent's phone because the ring time exceeds the Ring No Answer timer defined in the agent desktop settings. For Redirection on No Answer situations, you configure a separate call type and routing script to be used if agents do not answer ringing calls within the ring no answer time. In the Redirection on No Answer script, you queue the call at a higher priority so that the call does not fall to the bottom of the queue.

In a Unified CCE, environment, Redirection on No Answer situations increment call type statistics as follows:

  • For the initial call type, CallsOffered is incremented. When the call redirects, the CallsRONA field is incremented.

  • For the Redirection on No Answer call type, CallsOffered is incremented and also fields related to the completion of the call. For example, if the call is handled then the CallsHandled field is incremented.

    Because CallsOffered is incremented twice for the call, use a different call type for Redirection on No Answer calls. A different call type for Redirection on No Answer calls ensures that the call does not peg the same call type twice.

    In call type reports, these calls are grouped into the "Other" column. You can also view a count of Redirection on No Answer calls in agent and skill group reports.

How Calls That Experience Redirection on No Answer with CVPAffect Call Type Reporting

The Redirection on No Answer feature, configured in Agent Desk Settings in the Configuration tool and in CVP, ensures that when an agent does not answer a call, the call is taken away from the agent after a specified number of seconds and re-assigned to another agent or requeued. Redirection on No Answer is also used to change the agent state to Not Ready when a call is rerouted from the agent's phone. When the Ring No Answer time in the Agent Desk Settings expires, Unified CCE software makes the agent unavailable for routing requests. When the Unified CVP Ring No Answer timeout expires, the call is re-queried for routing to a different skill group or agent. You configure the Unified CVP Ring No Answer timer to be approximately 2 seconds longer than the Agent Desk Settings Ring no answer time so that the agent is made Not Ready before the call is requeried. If the agent is not made unavailable first, the script might reassign the call to the same agent.


Note


The Unified 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 Unified CVP. If the response is not received within 30 seconds, the call fails.

Because the Ring No Answer time and Unified CVP Ring No Answer timeout are several seconds apart, it is possible that the call continues to ring on the agent's phone after the agent is made Not Ready. If the agent answers the phone in this brief interval, the context of the call is not reported and reports show that the agent went directly into Active state from Not Ready state.

You can configure the routing script to handle Redirection on No Answer situations in two ways: the script can change the call type when the call is requeried, or the script can continue to use the same call type.

The manner in which you script for Redirection on No Answer affects the report data that you see, as follows:

  • If you change the call type, 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 Redirection onNo Answer occurrences in call type reports. For example, if you create a specific call type for use in Redirection onNo 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 can't 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 Nonmonitored Devices Affect Reporting

The Label node is used to divert a call to voice mail or web attendant or some other device that Unified CCE does not monitor because of digits collected by the caller during a voice menu or due to some other conditions. These calls are counted as RoutedNonAgent and appear in the "Other" column of call type reports.


Note


Use a Unified CCE routing scripting script, not a VRU script, to route calls to nonmonitored devices. If you use the VRU script, calls are reported as abandoned at the call type.

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

Services

For Unified CCE 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 CCE 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 a Unified CCE environment. For a Unified CCE environment, use the historical IVR peripheral service reports and the historical IVR trunk group reports to measure the performance of your IVRs.

Service Members

For Unified CCE, each Service has one or more skill groups whose members can provide the service. These skill groups are called service members. A skill group can be associated with (that is, can be a member of) more than one service.

Service and service members help track how scripts on an ACD are routing calls.

It is important to configure service members in Configuration Manager to accurately reflect their scripting in the ACD.

The system records calls that were offered to a service member, abandoned by that skill group, and reported against another skill group. (Call_Type_Skill_Group.CallsReportedAgainstAnother).

Enterprise Services (Unified CCE)

An Enterprise Service is a collection of services on different peripherals.

While an individual service is associated with a specific peripheral, an Enterprise Service can span several services from different peripherals in the contact center.

Creating and reporting on Enterprise Services gives contact center managers a consolidated measure of customer experience across similar services configured in different ACD peripherals distributed throughout the contact center.


Note


Avoid queuing to multiple services on the same or on several peripherals. Instead, configure and queue to Enterprise Services.

Service Reports

In Unified CCE, a service is an ACD concept that identifies a particular type of processing that the caller requires and defines the call treatment. For example, in the contact center for a software company, callers with questions about installing software are directed to the Technical Support service.

In a Unified CCE environment, calls are routed to services or skill groups at the ACD. All skill groups belong to specific services and, therefore, skill group data rolls up to the service.

Reports for services provide call treatment information for all the skill groups assigned to those services. Service reports are useful to measure customer experience data for which call treatment is done on the ACD.

In a Unified CCE environment, calls are routed through IVRs. Most Unified ICM service reports are therefore not applicable in a Unified CCE environment.

The service reports that are relevant for Unified CCE are the Peripheral Service reports that display data pertaining to IVR services.

For Unified CCE, use Service reports only to report on IVR status and activity. Use Call Type reports for the most complete view of the customer's experience and to ensure that your system is performing optimally.

Service Data Reports

The following reports display service data.

For Unified CCE environments, there are two categories of service reports:

  • Peripheral Services (Services)

    This service is tied to a specific peripheral (ACD). A single peripheral might have several services defined, such as Sales, Technical Support, and Customer Accounts.

  • Enterprise Services

    This service is a collection of services from several peripherals across an enterprise.

Reports include:

  • Unified Intelligence Center Enterprise Service Historical All Fields

For Unified CCE environments, service reports include:

  • Unified Intelligence Center Peripheral Service Real Time

  • Unified Intelligence Center Peripheral Service Historical All Fields