Contents
Integrating with Outbound Contact
This page describes how Interaction Concentrator (ICON) processes data from the Genesys Outbound Contact solution. It contains the following sections:
- Outbound Objects and Models
- Available Outbound Data
- Outbound Contact Deployment Scenarios
- Extracting Outbound Contact Data
For information about ICON configuration and other Configuration Layer settings that make data about Outbound Contact activity available in Interaction Database (IDB), see Configuring for Outbound Contact Data in the Interaction Concentrator Deployment Guide.
Outbound Objects and Models
This section introduces the terminology, elements (objects), and models that pertain to Genesys Outbound Contact.
Outbound Contact Objects
The following terms refer to the Outbound Contact objects and elements about which ICON stores reporting data:
- Campaign: A master plan for managing customer data, generating calls, and monitoring and handling call results. Outbound Contact uses campaigns to automate outbound dialing.
- Campaign Group: A runtime association among a campaign, a calling list, and a group of resources (such as agents) that is assigned to handle the campaign activity.
- Calling List: A database table made up of records that contain customer data, which could have dialing filters applied.
- Record: The basic unit of customer data. Each record represents one customer phone number.
- Field: A single piece of data (for example, a phone number) within a record. A calling list includes mandatory fields, which are required in order for the Outbound Contact solution to operate. A calling list can also include custom fields.
- Chain: Records that are logically united, usually representing the same customer contact information. For example, three records with the home, business, and cell phone numbers for the same customer comprise a chain of records.
- Format: A template that organizes the data in a calling list. When calling lists are created and populated with records, the customer data in the records fills the fields and conforms to the field properties that are established in the format, according to either the system default setting or a user-defined setting.
For more detailed information about Outbound Contact objects, see the Outbound Contact Deployment Guide.
Campaign Model
The following figure shows the finite state machine (FSM) for a campaign group.
Chain Model
The following figure shows the FSM for a chain.
Chain States
In the figure "Finite State Machine for a Chain", the chain states are as follows:
- NULL: The initial state, in which no records for this chain have yet been selected from the database. This is also the final state, in which all records in the chain are either finalized or unloaded, and updated in the database.
- Processing: The state in which the processing of a record from the chain has started, and resources for this processing have been allocated.
- Processed: The state in which a record is processed. Depending on the actual processing result, the record(s) in the chain are finalized or rescheduled.
- Scheduled: The state in which a record in the chain is scheduled for processing, either because the chain has been loaded from the calling list or because of the previous processing attempt. The chain can be scheduled for processing either at a specified date and time or for now—that is, as soon as resources for processing the chain are available to Outbound Contact Server (OCS).
Available Outbound Data
This section describes how ICON communicates with Outbound Contact Server (OCS) and what kind of data OCS can send to ICON, provided that both OCS and ICON are properly configured.
ICON and OCS Communications
ICON connects to OCS at the port that OCS opens for regular client connections. Unlike other OCS clients, ICON uses a special protocol to receive reporting-related data. The OCS data includes runtime information about OCS objects, as well as certain statistics that OCS calculates specifically for reporting purposes.
If two or more OCS instances are running simultaneously in a given contact center, a single ICON instance can process and store data from either a single OCS instance or multiple OCS instances.
Outbound Objects Data
ICON stores campaign and chain information, including both their history within a given campaign session and the associations between calls and parties, when this data is available.
Specifically, you can integrate ICON with OCS so that the following data is stored in IDB for outbound reporting purposes:
- History of changes in campaign configuration properties, and the target values of optimization parameters.
- History and results of chain processing.
- History of changes that OCS makes in calling list records during chain processing, and that ICON is configured to track.
- Results of each attempt to generate an outbound call, whether successful or not.
- Call progress detection (CPD) call results.
- Call results assigned by an agent, which are stored independently from the CPD call results, and which do not overwrite them.
For the full list and descriptions of IDB tables that store outbound data, see the Interaction Concentrator Physical Data Model document for your RDBMS.
Precalculated OCS Metrics
In addition to raw object data, you can configure OCS to calculate, and ICON to store, a set of outbound-related statistics, which are also referred to as precalculated metrics.
The following table lists the precalculated metrics that OCS provides to ICON for storage in the GO_METRICS IDB table.
Precalculated OCS Metrics Arriving at Set Intervals
OCS calculates the following subset of metrics for all currently active campaign groups, and for all calling lists that participate in the active campaign groups. OCS delivers these metrics to ICON in a single data packet every 10 minutes.
| Metric | Description |
|---|---|
| Total number of records per calling list | Number of physical records in the calling list database view (for example, records from the database table and, possibly, the WHERE clause from the dialing filter). |
| Total number of records per campaign group | Number of physical records in all database views whose calling lists are assigned to the campaign that participates in the campaign group. |
| Total number of chains per calling list | Number of logical chains in the calling list database view (for example, records from the database table and, possibly, the WHERE clause from the dialing filter). A logical chain is defined as one or more database table records with the same Chain ID value. |
| Total number of chains per campaign group | Number of logical chains in all database views, whose calling lists are assigned to the campaign that participates in the campaign group. |
| Current number of records not processed per calling list | Number of physical records in the calling list database view (for example, records from the database table and, possibly, the WHERE clause from the dialing filter) that have the type GENERAL and the status READY. |
| Current number of records not processed per campaign group | Number of physical records in all database views that have the type GENERAL and the status READY, and whose calling lists are assigned to the campaign that participates in the campaign group. |
| Current number of chains not processed per calling list | Number of logical chains in the calling list database view (for example, records from the database table and, possibly, the WHERE clause from the dialing filter), in which at least one record of the chain has the type GENERAL and the status READY. |
| Current number of chains not processed per campaign group | Number of logical chains in all database views, in which at least one record of the chain has the type GENERAL and the status READY, and whose calling lists are assigned to the campaign that participates in the campaign group. |
| Current number of busy dialer ports per campaign group | Current number of busy (that is, occupied with outbound calls that are in the process of being placed) CPD Server ports or Switch call classifier ports. |
| Current number of engaged (busy) ports per campaign group | Current number of ports used by engaged calls that CPD Server already placed.
Note: OCS calculates this metric only for campaign groups that are activated in Active Switching Matrix (ASM) dialing modes with CPD Server. |
| Outbound Calls Overdialed | Indicates that Outbound Dialing Engine is to consider a given call overdialed. For information about overdialed calls, see the Outbound Contact documentation. Note: OCS calculates this metric for all currently active campaign groups. When a call is overdialed, OCS delivers this metric to ICON. OCS does not deliver this metric at a preset interval, but instead calculates it and passes it to ICON on a per-occurrence basis (that is, for each overdialed call). |
Precalculated OCS Metrics Arriving at Each Occurrence
OCS calculates the following subset of metrics for all currently active campaign groups. As a result of each successful dial attempt, OCS delivers these metrics to ICON in the form of a single snapshot event. OCS does not deliver these metrics at a preset interval, but instead calculates them and passes them to ICON on a per-occurrence basis (that is, for each successfully dialed outbound call).
| Metric | Description |
|---|---|
| Outbound Call Dialing Time | The time, in milliseconds, between (a) initiation of dialing and (b) the moment when the call was answered by the called party or when a call that did not reach the called party was released. Note: The time that the call was answered by the called party is available only when SIP Server or CPD Server is used for dialing. Therefore, if calls are not dialed through SIP Server or CPD Server, this metric will be available only for unsuccessful calls. |
| Outbound Call Transfer Time | The time, in milliseconds, between completion of CPD and the moment when the call was established on the Agent or IVR DN. Note: The time that CPD completed is available only when CPD Server is used for dialing. Therefore, if calls are not dialed through CPD Server, this metric is not available. |
| CPD Time | The time, in milliseconds, from the moment when the call was answered by the called party until the moment when CPD was done. Note: Both time stamps are available only when CPD Server is used for dialing. Therefore, if calls are not dialed through CPD Server, this metric is not available. |
Outbound Contact Deployment Scenarios
Interaction Concentrator supports all types of Outbound Contact deployments and, most importantly, stores outbound data consistently, regardless of the deployment scenario.
This section discusses two main deployment scenarios:
- Single-site deployment, in which one ICON instance is dedicated to handling outbound data.
- Multi-site deployment, in which a single OCS instance serves all sites. In this environment, you can use a single ICON instance for each site, or a single ICON instance for all sites.
Diagram Conventions
To simplify the deployment diagrams in this section:
- DB Server, which enables a connection between ICON and IDB, is omitted from the diagrams, although it is required in actual deployments.
- Storage of configuration data is not shown, although it is required in actual deployments.
Single-Site Deployment Example
The simplest deployment scenario, which is suitable for single-site contact centers, consists of a single ICON instance that is dedicated to storing all outbound data to a single IDB instance (shown in the figure below).
In this scenario, ICON is dedicated to storing outbound data, including both object information and precalculated metrics, which comes ultimately from the switch to which OCS is connected. This ICON instance does not have a connection to T-Server or, in a multimedia solution, to Interaction Server, nor does it gather interaction data from T-Server or Interaction Server. It is assumed that another ICON instance stores CTI–related data and interaction data to either the same IDB or a separate IDB.
Multi-Site Deployment Examples
There are a number of options available if you want to collect Outbound Contact data from multiple sites/switches.
Example 1
The simplest multi-site deployment scenario consists of a single ICON instance connected to a single OCS that gathers data from multiple switches/sites. In the following architecture, ICON collects data from all of the switches connected to the OCS instance which is specified on the ICON Application object Connection tab.
Example 2
You might want to use a similar architecture, with a single OCS taking in data from multiple switches, but prefer to have ICON store data from only some of the switches. To limit the Outbound Contact data that ICON stores, add connections to the T-Servers associated with the desired switches to the ICON Application object Connection tab. This architecture is shown in the graphic below, in which ICON is connected to an instance of OCS that is then connected to four switches. To have ICON store Outbound Contact data only from switches 1 and 2, add connections to T-Servers 1 and 2, which are connected to the desired switches.
Example 3
The figure below shows a variation on the multi-site deployment scenario shown in Example 2. In this case, Outbound Contact data is split between two ICONs, though it is all processed by the same OCS instance.
In this scenario:
- ICON 1 stores:
- Data related to outbound activity generated by OCS at Site 1 only.
- CTI data related to call activity reported by T-Server 1, which is serving Site 1.
- ICON 2 stores:
- Data related to outbound activity generated by OCS at Site 2 only.
- CTI data related to call activity reported by T-Server 2, which is serving Site 2.
Matching Outbound and CTI Data in IDB
To match CTI or interaction data (reported by T-Server or Interaction Server) and outbound data (reported by OCS) for the same interaction, use the call attempt identifier (CallAttId) that ICON stores in the GOX_Chain_Call table.
OCS Reporting Limitation
OCS is not able to track certain types of outbound calls when the Campaign Group is running in the following dialing modes:
- Preview mode—Calls that are dialed by the Agent Desktop
- Power GVP mode—Calls that are dialed by GVP Dialer
- Push Preview mode—Interactions that are pushed to the Agent Desktop from Interaction Server
Chain-related events for these types of calls do not contain the unique identifier (Call GUID) of the outbound call(s) dialed during chain processing. As a result, ICON does not receive the information it needs to create a record in the GOX_Chain_Call table.
Workaround
As a workaround, you can use the call attempt GUID to bridge data about outbound chain activity with data about telephony activity. OCS reports the call attempt GUID in chain-related events, and T-Server and Interaction Server include it in the user data of outbound calls.
Extracting Outbound Contact Data
To extract Outbound data from IDB, Genesys recommends an approach similar to that used for voice data interactions:
Use records from the GO_CAMPAIGN and GO_CHAIN tables as the base records. The records from these two tables can be extracted independently.
Only terminated records are considered for extraction.
Use a combination of the values in the following fields as the unique record identifier:
- SessID
- OCSID
- CallingListID
- RECORDHANDLE
- CHAINGUID
- TYPE
- CALLATTID
- ADDED_TS
Extraction of Campaign-Level Data
Use the value of the SessID field as a unique identifier to extract terminated records from the GO_CAMPAIGN, GO_CAMPAIGNHISTORY, and GO_CAMPPROP_HIST tables.
Extraction of Chain-Level Data
Use the value of the CHAINGUID field as a unique identifier to extract terminated records from the GO_CHAIN, GO_CHAINREC_HIST, GO_RECORD, GO_CUSTOM_FIELDS, GO_FIELDHIST, GO_SECURE_FIELDS, GO_SEC_FIELDHIST and GO_CHAIN_CALL tables.
Extraction of Precalculated Metrics
OCS precalculates some metrics and sends this data to ICON. OCS does not provide a unique identifier for these metrics, but you can use the object’s identifier (for the metric calculated) and the metric’s timestamp to identify records.