Jump to: navigation, search

Set up Historical Reporting

Important
Starting in 8.5.105.12, Genesys Callback reports callback metrics through UserEvents. You can enable this feature in your callback service. When enabled, GMS sends the UserEvents to the configured DN. You can then configure your reporting tools to listen to the User Events for this DN and report on callback details.


Prerequisites

Mandatory Genesys Components
Component Minimum Version
Orchestration Server 8.1.400.24
Universal Routing Server 8.1.400.22
Interaction Concentrator 8.1.506.07
Genesys Info Mart 8.5.005 (GA)
Reporting and Analytics Aggregates (RAA) 8.5.000.02
Genesys Interactive Insights (GI2) 8.5.000.02

Historical Reporting Architecture

Reporting on Genesys Callback relies on the user-event mechanism to provide Callback-related metrics and requires Interaction Concentrator, Genesys Info Mart, and Reporting and Analytics Aggregates (RAA) to collect and organize data to produce a database from which Genesys Interactive Insights (GI2) can rapidly extract the needed data.

GMS reporting historical architecture.png

  1. Genesys Callback reports callback metrics through UserEvents to the configured DN. SCXML strategies that you load through the templates in the Service Management UI collect metrics, and then pass the metrics as user data (KVPs) with two UserEvent events, one sent at the start of the session and another, at the end of the session. Genesys Info Mart has certain minimum requirements for the KVPs that must be sent. The out-of-box templates include these KVPs, as well as other KVPs that Genesys Info Mart requires for meaningful reporting. See Genesys Info Mart KVP Requirements for details.
  2. Interaction Concentrator (ICON) stores the user data (KVPs) attached to these events into the G_CUSTOM_DATA_S table of the Interaction Database (IDB).
  3. Genesys Info Mart transforms the data into the CALLBACK_FACT table of the Info Mart database; this format can be more quickly loaded into reports.
  4. Reporting and Analytics Aggregates (RAA) aggregates the data; in other words, RAA summarizes and organizes the data from Genesys Info Mart in such a way that GI2 is able to extract meaning.
  5. Genesys Interactive Insights (GI2) then presents two out-of-box callback reports: Callback Summary Report and Callback Details Report.

GMS-ReportingCallbackReports.png

For example, for reporting purposes, the following are some of the keys that GMS sends in UserEvents related to Outbound calls:

  • _CB_T_SERVICE_START
  • _CB_SERVICE_ID
  • _CB_D_CALLBACK_OFFER
  • _CB_N_CALLBACK_OFFERED
  • _CB_T_CALLBACK_OFFERED
  • _CB_T_CALLBACK_ACCEPTED
  • _CB_T_CUSTOMER_CONNECTED
  • _CB_N_IS_SNOOZED
  • _CB_T_NEXT_REDIAL_ATTEMPT
  • _CB_N_CALLBACK_MEDIA_ATTEMPTS
  • _CB_T_LAST_DIAL_ATTEMPT
  • _CB_N_AGENT_ADDED_TO_IXN

The keys that GMS sends depend on the scenario. To get a complete list of the keys that might be sent, refer to the Callback KVPs reference in this page.

Genesys Info Mart KVP Requirements

The following KVPs are mandatory. Genesys Info Mart will not create a record for the callback event if the KVP is missing from the UserEvent.

  • _CB_SERVICE_ID
  • _CB_T_SERVICE_START
  • _CB_D_CALLBACK_OFFER
  • _CB_N_CALLBACK_OFFERED
  • _CB_T_CALLBACK_OFFERED

The following four KVPs need to be sent in both UserEvents and as call-based attached data in TEvents.The duplicated KVPs enable Genesys Info Mart to associate the callback event with interaction data.

  • _CB_T_CALLBACK_ACCEPTED
  • _CB_T_SERVICE_START
  • _CB_SERVICE_ID
  • _CB_T_CUSTOMER_CONNECTED

For meaningful reporting, Genesys Info Mart requires a number of other KVPs, depending on the callback scenario. See the Callback KVPs reference, below, for the complete list.

Important
  • The _CB_SERVICE_ID is returned by the GMS API in response to the callback request.
  • For Inbound Calls, where the in-queue callback offer was presented and accepted, _CB_T_CALLBACK_ACCEPTED, _CB_T_SERVICE_START, and _CB_SERVICE_ID must be attached at the time at which the callback was accepted.
  • For Virtual and Outbound Calls, _CB_T_CUSTOMER_CONNECTED must be attached at the time at which the customer was connected.

Virtual Queues

As a best practice, Genesys recommends to create virtual queues associated with the following interaction types:

  • Virtual Queue for Inbound calls—This queue is where the regular inbound calls are going to be reported. Those calls are callbacks that were not offered or, offered and rejected.
  • Virtual Queue for Virtual callbacks—This queue is where the virtual callbacks are going to be waiting for an agent.
  • Virtual Queue for Outbound calls—This is where the callback application will place the real outbound call when it gets confirmation that the right person is connected. The call is removed from this queue after it is successfully delivered to an agent or is abandoned by the customer.
Important
Virtual queues (VQ) that are used for reporting will make metrics effective, but they are not used for routing in this context.

Related Resources for Historical Reporting

You may also be interested in reading:

Configure Historical Reporting

Important
Genesys Info Mart and Genesys Interactive Insights (GI2) support for callback offered through GMS is provided out-of-box, with no additional configuration required. To see callback data in GI2 reports, however, you need to modify configuration for other products as explained in this section.

Configure a Reporting DN

Open Genesys Administrator or Configuration Manager and create a new DN of type Trunk Group DN. The name of the DN is used inside SCXML scripts, so it should be meaningful and recognizable.
For example: Sip_Switch > DN > REPORTING

Configure your Callback Service

Callback-reportingSection85104.png


Edit your callback service in Callback and Mobile Engagement > Configured Services, and expand the Reporting section:

  • Set the _rep_userevent_enable option to true to enable reporting.
  • Set the _rep_userevent_dn option to the Trunk Group DN that you created previously, used as the destination DN of the reporting events.
  • Set the _rep_userevent_switch option to the Switch name where you created this DN. This is the SIP Switch used to report the events.


Configure Orchestration Server

In the connections of your Orchestration Server application, add the T-Server used to define the reporting Switch and DN in the GMS service configuration. For example, Sip_Switch.

Configure Interaction Concentrator

To make Callback reporting work, you need to configure Interaction Concentrator (ICON) for Voice. See here for details.

Set the KVP list

  • Configure ICON to store the KVP data provided in the UserData section of EventUserEvents. ICON will store this data in the G_CUSTOM_DATA_S table of the Interaction Database (IDB):
    ICON > Options > custom-states/store-event-data=all
    By default, store-event-data is set to none.
  • Configure ICON to store required duplicate KVP data provided in the UserData attribute of TEvents. ICON will store this data in the G_USERDATA_HISTORY table. To enable this storage, modify your ccon_adata_spec.xml file to capture the four TEvents KVPs described in the Callback KVPs reference below:
    • _CB_T_CALLBACK_ACCEPTED
    • _CB_T_CUSTOMER_CONNECTED
    • _CB_T_SERVICE_START
    • _CB_SERVICE_ID
Tip
See the ccon_adata_spec_GIM_example.xml file in the Genesys Info Mart installation package for an example of the required modification.

Check Interaction Concentrator Connections

Make sure that Interaction Concentrator is connected to the T-Server that is servicing the switch specified in the Callback Service.
For example: Sip_Switch.

Start Interaction Concentrator and use logs to verify that it registered on the REPORTING DN.

Important
Interaction Concentrator does not produce historical records for virtual interactions.

Configure Reporting and Analytics Aggregates

Edit the Genesys Info Mart application to enable the agg-feature\enable-callback option:
agg-feature\enable-callback=yes

Tip
See here for details about the configuration of your RAA application.

Verify Reporting Data

  1. Run your scenario by triggering Genesys Mobile Services and Orchestration Server (ORS) APIs directly.
  2. Make sure user events are being delivered to Interaction Concentrator applications by checking T-Server logs. You should see something like this:
00:34:20.757 Int 04543 Interaction message "RequestDistributeUserEvent" received from 
516 ("OrchestrationServer")
  -- Absent ThisDN, REPORTING was used
  @00:34:20.7570 [0] 8.1.000.62 send_to_client: message EventACK
  	AttributeEventSequenceNumber	0000000000000ef8
  	AttributeCustomerID	'Environment'
  	AttributeTimeinuSecs	757000
  	AttributeTimeinSecs	1348817660 (00:34:20)
  	AttributeReferenceID	431
  	AttributeThisDN	'REPORTING'
  	AttributeUserEvent	RequestDistributeUserEvent
  00:34:20.757 Trc 04542 EventACK sent to [516] (00000003 OrchestrationServer 192.168.27.50:40727)
  @00:34:20.7570 [0] 8.1.000.62 distribute_user_event: message EventUserEvent
  	AttributeEventSequenceNumber	0000000000000ef9
  	AttributeCustomerID	'Environment'
  	AttributeTimeinuSecs	757000
  	AttributeTimeinSecs	1348817660 (00:34:20)
  	AttributeUserEvent	EventUserEvent
  	AttributeUserData	[347] 00 0c 00 00..
  		'gms_AgentAvailable'	'1348817660755'
  		'gms_AgentConnected'	''
  		'gms_IxnCompleted'	''
  		'gms_ServiceName'	'inbound-delay'
  		'gms_ServiceStartAt'	'1348817660553'
  		'gms_ServiceStoppedAt'	''
  		'gms_SessionEventSeq'	3
  		'gms_SessionId'	'65UA6ISSJH76R340BNDQ2DG0DG000036'
  		'gms_UserConnected'	''
  		'gms_UserId'	''
  		'gms_WaitingForAgent'	'1348817660744'
  		'gms_externalId'	''
  	AttributeANI	'777'
  	AttributeDNIS	'333'
  	AttributeReferenceID	431
  	AttributeThisDN	'REPORTING'
  00:34:20.758 Trc 04542 EventUserEvent sent to [508] (0000000c Icon_Voice 192.168.27.50:42678)
  00:34:20.758 Trc 04542 EventUserEvent sent to [588] (00000004 Stat_Server 192.168.27.50:40728)
  00:34:20.758 Trc 04542 EventUserEvent sent to [592] (00000005 Universal_Routing_Server
 192.168.27.50:40744)

3. Check your Interaction Concentrator logs and the G_CUSTOM_DATA_S table in Interaction Database and make sure that data is recorded properly.

For example, you should see in Interaction Concentrator logs:

00:39:19.569 Int 04543 Interaction message "EventUserEvent" received from 65200 ("SIP_Server@REPORTING")
00:39:19.751 Int 04543 Interaction message "EventUserEvent" received from 65200 ("SIP_Server@REPORTING")
00:39:19.766 Int 04543 Interaction message "EventUserEvent" received from 65200 ("SIP_Server@REPORTING")
00:39:19.987 Trc 25016 Persistent Queue GUD: transaction 10929 is committed. 5 records written 
into the queue
00:39:19.987 Trc 25003 Database queue [GUD]: persistent queue transaction 10929 is being processed.
00:39:20.001 Trc 25004 Database queue [GUD]: persistent queue transaction 10929 is processed, committed
 and removed. 5 records are written.

4. Optionally, you can also check the content of the CALLBACK_FACT table in the Info Mart database to make sure that the transformation process is correctly executed as well. For example, you can try the following query:

SELECT * FROM dbo. CALLBACK_FACT

GMS-CALLBACK FACT-check.png

How to Pass Reporting KVPs of the Inbound Call in the Callback Request

Some historical reporting KVP values are known only by the IVR or application that requests the callback service. Including these KVPs in the historical reporting is optional. If you want to include them, the values can be passed in the HTTP request that starts the Callback service. The following is the list of the KVP parameters that can be passed in the HTTP request. Each maps to the corresponding _CB_X KVP.

  • _cb_t_callback_offered
  • _cb_d_callback_offer
  • _cb_ewt_when_callback_was_offered
  • _cb_pos_when_callback_was_offered
  • _cb_t_callback_accepted
  • _cb_dim_channel
  • _cb_dim_callback_offer_type
  • _cb_dim_offer_timing
  • _cb_n_callback_offers_per_session
  • _cb_d_last_callback_offer
Important
If the agent submits the completed reason in the disposition result, the system will set the reporting key _CB_DISPOSITION to the provided COMPLETED reason.

Reference: Callback KVPs

The following table describes the KVPs that, if sent by GMS in UserEvents, Genesys Info Mart uses to enable Callback reporting.

The following four KVPs must also be sent as call-based attached data.

  • _CB_SERVICE_ID
  • _CB_T_SERVICE_START
  • _CB_T_CALLBACK_ACCEPTED
  • _CB_T_CUSTOMER_CONNECTED
Important
The sample attached-data specification file in the Genesys Info Mart IP includes these four KVPs by default.
KVP Description Info Mart Database Target

_CB_TENANT_DBID

The Tenant DBID. CALLBACK_FACT.TENANT_KEY

_CB_DISPOSITION

Callback state using the format <state>.<sub state> where:
  • <state> can be set to: SCHEDULED, QUEUED, ROUTING, PROCESSING, COMPLETED.
  • <sub state> can be set: REDIAL_LIMIT_REACHED, CANCELLED, AGENT, ABANDONED_IN_QUEUE, REJECTED, PUSH_SEND, PUSH_DELIVERY_CONFIRMED, PUSH_SEND_ERROR, FAILED, CONNECTED, TRANSFERRED_TO_RP.
CALLBACK_DIM_3.DISPOSITION (referenced through CALLBACK_FACT.CALLBACK_DIM_3_KEY)

_CB_SERVICE_ID*

The ID of the callback service request. Depending on the scenario, the value equals the ID of the GMS service instance or ID of the ORS session. CALLBACK_FACT.SERVICE_ID

_CB_ORIGINATION_IXN_ID

Introduced: GMS 8.5.200.07

The ID of the inbound call where the callback was originally offered and accepted. You must pass the _cb_origination_ixn_id parameter in your Start Callback query when creating a callback request. If you do not pass the _cb_origination_ixn_id parameter, the value of _CB_ORIGINATION_IXN_ID will be undefined. For chat scenarios, this ID should be the chat interaction ID. CALLBACK_FACT.ORIGINATION_IXN_ID

_CB_FIRST_OUT_IXN_ID

Introduced: GMS 8.5.200.07

The call ID of the first outbound call that the callback service created. CALLBACK_FACT.FIRST_OUT_IXN_ID

_CB_LAST_OUT_IXN_ID

Introduced: GMS 8.5.200.07

The call ID of the last outbound call that the callback service created. CALLBACK_FACT.LAST_OUT_IXN_ID

_CB_DIAL_1_RESULT

Introduced: GMS 8.5.200.07

The result of the first callback dialing attempt. One of the following values:
  • CREATE_CALL_ERROR
  • BUSY
  • NO_ANSWER
  • ANSWERING_MACHINE
  • ERROR_TONE
  • FAX
  • PERSON
  • CONNECTED
  • FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA
  • PUSH_DELIVERY_CONFIRMED
  • PUSH_SEND_ERROR
  • PUSH_DELIVERY_NOT_CONFIRMED
  • USERORIGINATED_CONNECTED

Notes: FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA is a result that must be reported by the user application; otherwise, there is no CTI data that will enable Genesys Callback to identify this result.

CALLBACK_DIAL_RESULTS.DIAL_1_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)

_CB_DIAL_2_RESULT

Introduced: GMS 8.5.200.07

The result of the second callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_2_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)

_CB_DIAL_3_RESULT

Introduced: GMS 8.5.200.07

The result of the third callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_3_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)

_CB_DIAL_4_RESULT

Introduced: GMS 8.5.200.07

The result of the fourth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_4_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)

_CB_DIAL_5_RESULT

Introduced: GMS 8.5.200.07

The result of the fifth callback dialing attempt. See _CB_DIAL_1_RESULT for possible values. CALLBACK_DIAL_RESULTS.DIAL_5_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIAL_RESULTS_KEY)

_CB_T_DIAL_1

Introduced: GMS 8.5.200.07

UTC Timestamp of the first dialing attempt. CALLBACK_FACT.DIAL_1_TS

_CB_T_DIAL_2

Introduced: GMS 8.5.200.07

UTC Timestamp of the second dialing attempt. CALLBACK_FACT.DIAL_2_TS

_CB_T_DIAL_3

Introduced: GMS 8.5.200.07

UTC Timestamp of the third dialing attempt. CALLBACK_FACT.DIAL_3_TS

_CB_T_DIAL_4

Introduced: GMS 8.5.200.07

UTC Timestamp of the fourth dialing attempt. CALLBACK_FACT.DIAL_4_TS

_CB_T_DIAL_5

Introduced: GMS 8.5.200.07

UTC Timestamp of the fifth dialing attempt. CALLBACK_FACT.DIAL_5_TS

_CB_IXN_START_IGNORING_AVAILABILITY

Introduced: GMS 8.5.200.07

For premise callback, _CB_IXN_START_IGNORING_AVAILABILITY will always be 0. CALLBACK_DIM_4.DIAL_IGNORING_AVAILABILITY

_CB_FINAL_RECORD

Indicates whether this is a final record about this callback service: 0 = No, 1 = Yes. CALLBACK_FACT.FINAL_RECORD

_CB_EWT_WHEN_READY_TO_START_MEDIA_IXN

The value of Expected Wait Time (EWT), in seconds, for the service request when the contact center was ready to start the first callback interaction, such as an outbound dialing attempt. CALLBACK_FACT.EWT_READY_TO_START_IXN

_CB_EWT_WHEN_CALLBACK_WAS_OFFERED

The value of EWT, in seconds, at the time the callback was offered. CALLBACK_FACT.EWT_WHEN_OFFERED

_CB_POS_WHEN_READY_TO_START_MEDIA_IXN

The customer position in the queue when the contact center was ready to start the first callback interaction, such as an outbound dialing attempt. CALLBACK_FACT.POS_READY_TO_START_IXN

_CB_POS_WHEN_CALLBACK_WAS_OFFERED

The customer position in the queue when callback was offered. CALLBACK_FACT.POS_WHEN_OFFERED

_CB_D_CALLBACK_OFFER

The duration of the callback offer, in seconds. CALLBACK_FACT.CALLBACK_OFFER_TIME

_CB_OFFER_EWT_INBOUND_VQ

Introduced: GMS 8.5.111.04

Estimated Wait Time for the queue where rejected calls and not offered callbacks are being placed. This value is identical to _CB_EWT_WHEN_CALLBACK_WAS_OFFERED if the same Virtual Queue is used to place accepted callbacks. CALLBACK_FACT.EWT_WHEN_REJECTED

_CB_N_ABANDONED_DURING_CALLBACK_OFFER

Introduced: GMS 8.5.111.04

Indicates whether the caller dropped the call without explicitly accepting or rejecting the callback offer: 0 = No, 1 = Yes. CALLBACK_DIM_4.ABANDONED_DURING_CB_OFFER (referenced through CALLBACK_FACT.CALLBACK_DIM_4_KEY)

_CB_CUSTOMER_ANI

Introduced: GMS 8.5.111.04

ANI of the customer for in-queue scenarios. This value can match _CB_CUSTOMER_PHONE_NUMBER if the same number is confirmed or entered. Could also be empty if the ANI is not detected. CALLBACK_FACT.CUSTOMER_ANI

_CB_T_SERVICE_END

Introduced: GMS 8.5.111.04

UTC timestamp for when service was completed or terminated. CALLBACK_FACT.SERVICE_END_TS

_CB_D_CUSTOMER_WAITED_BEFORE_OFFER

Introduced: GMS 8.5.106.14

The amount of time, in seconds, the customer waited in the queue before a callback was offered. CALLBACK_FACT.WAITED_BEFORE_OFFER_TIME

_CB_D_WAITING_FOR_AGENT_OFFLINE

The amount of time, in seconds, the customer was waiting offline for an agent to become available. CALLBACK_FACT.WAIT_AGENT_OFFLINE_TIME

_CB_D_ESTABLISH_MEDIA_IXN

The amount of time, in seconds, it took to establish the callback interaction, such as an outbound call. CALLBACK_FACT.ESTABLISH_MEDIA_IXN_TIME

_CB_D_CUSTOMER_CONNECTED_WAITING_FOR_AGENT

The amount of time, in seconds, the customer was waiting to be connected to the agent after the callback interaction was established. CALLBACK_FACT.CONN_WAITING_AGENT_TIME

_CB_T_CALLBACK_ACCEPTED*

The UTC timestamp when the callback offer was accepted. CALLBACK_FACT.CALLBACK_ACCEPTED_TS

_CB_T_CALLBACK_OFFERED

The UTC timestamp when the callback was offered. CALLBACK_FACT.CALLBACK_OFFERED_TS

_CB_T_READY_TO_START_MEDIA_IXN

The UTC timestamp when the contact center was ready to start the callback interaction. The value matches the time of either an outbound dialing attempt or a push notification prompting the customer to start a call or chat session.

Note: Set this value only once, before the first dial attempt.

CALLBACK_FACT.READY_START_MEDIA_IXN_TS

_CB_T_CUSTOMER_CONNECTED*

The UTC timestamp when the customer was reconnected to the contact center and started waiting for an agent to be connected. CALLBACK_FACT.CUSTOMER_CONNECTED_TS

_CB_N_AGENT_ADDED_TO_IXN

Indicates whether the agent was successfully added to the callback interaction: 0 = No, 1 = Yes. CALLBACK_FACT.AGENT_ADDED_TO_IXN

_CB_N_TRANSFER_TO_AGENT_FAILED

Number of times the callback interaction failed to transfer to the agent. CALLBACK_FACT.XFER_TO_AGENT_FAILED

_CB_N_CUSTOMER_ABANDONED_WHILE_WAITING_FOR_AGENT

Indicates whether the customer abandoned the callback interaction while waiting to be connected to an agent: 0 = No, 1 = Yes. CALLBACK_FACT.ABANDONED_WAITING

_CB_N_TIMEOUT_WHILE_WAITING_FOR_AGENT

Indicates whether the customer was disconnected because the timeout for waiting for an agent was reached: 0 = No, 1 = Yes. CALLBACK_FACT.TIMEOUT_WAITING

_CB_N_IXN_REQ_AGENT

Indicates whether the interaction required agent assistance: 0 = No, 1 = Yes. CALLBACK_FACT.IXN_REQ_AGENT

_CB_N_CALLBACK_OFFERED

Indicates whether callback was offered, at least once, during the session: 0 = No, 1 = Yes. CALLBACK_FACT.CALLBACK_OFFERED

_CB_N_CALLBACK_ACCEPTED

Indicates whether a callback offer was accepted: 0 = No, 1 = Yes. CALLBACK_FACT.CALLBACK_ACCEPTED

_CB_N_CALLBACK_MEDIA_ATTEMPTS

The total number of callback attempts or notifications, both successful and unsuccessful. CALLBACK_FACT.CALLBACK_ATTEMPTS

_CB_T_SERVICE_START*

The UTC timestamp when the callback service started. This value represents either the time of the callback request or the time that the callback offer was played, depending on deployment. CALLBACK_FACT.SERVICE_START_TS, CALLBACK_FACT.START_DATE_TIME_KEY

_CB_DIM_VQ_DBID

The DBID of the virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY

VQ_CFG_TYPE_ID

The configuration type ID of the virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY

VQ_CFG_TYPE

The configuration type of the virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY

_CB_DIM_VQ

The virtual queue used to find the target agent. Genesys Info Mart uses this value in combination to identify the RESOURCE_KEY to use. CALLBACK_FACT.RESOURCE_KEY

_CB_DIM_CHANNEL

The interaction channel from which the callback originated. One of the following values:
  • IVR
  • WEB
  • MOBILE
CALLBACK_DIM_1.CHANNEL (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)

_CB_DIM_CALLBACK_OFFER_TYPE

The type of callback offer that was presented to the customer. For example, after business hours, SCHEDULED is the only available option; during business hours, business rules might allow only the WAIT_FOR_AGENT option or a combination of SCHEDULED and WAIT_FOR_AGENT. One of the following values:
  • SCHEDULED
  • WAIT_FOR_AGENT
  • COMBINED_SCHEDULED_AND_WAIT_FOR_AGENT
  • IMMEDIATE
CALLBACK_DIM_1.CALLBACK_OFFER_TYPE (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)

_CB_DIM_TYPE

The type of callback the customer requested. One of the following values:
  • IMMEDIATE - The interaction is created right away while the customer is waiting for the agent (in an online chat session or waiting for a voice call).
  • WAIT_FOR_AGENT - The interaction is delayed until the agent is about to become available or actually becomes available (as in an agent first scenario).
  • SCHEDULED - The time for the callback interaction is negotiated with the customer.
CALLBACK_DIM_1.CALLBACK_TYPE (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)

_CB_DIM_CONNECT_ORDER

The order in which the final callback interaction was connected. One of the following values:
  • CUSTOMER_FIRST
  • AGENT_FIRST_PREVIEW
  • AGENT_FIRST_NO_PREVIEW
CALLBACK_DIM_1.CONNECT_ORDER (referenced through CALLBACK_FACT.CALLBACK_DIM_1_KEY)

_CB_DIM_DIAL_DIALOG_RESULT

The result of the final dialog for the callback. One of the following values:
  • RIGHT_PERSON
  • RESCHEDULED
  • CANCELLED
  • TRANSFERRED_TO_RP
CALLBACK_DIM_2.DIAL_DIALOG_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)

_CB_DIM_CALL_DIRECTION

The direction of the final callback interaction. One of the following values:
  • CUSTOMER_TERMINATED - Outbound Callback scenarios in which the contact center is dialing out to the customer's number.
  • CUSTOMER_ORIGINATED - Inbound Callback scenarios in which the contact center notifies the customer-facing application that it is time for the callback interaction, after which the application creates the interaction (such as a call or chat), obtaining the phone number if necessary. In this scenario, a customer call comes into the contact center as a regular inbound call, but it is recognized as the callback interaction.
CALLBACK_DIM_2.CALL_DIRECTION (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)

_CB_DIM_FINAL_DIAL_RESULT

The result of the final callback dialing attempt. One of the following values:
  • CREATE_CALL_ERROR
  • BUSY
  • NO_ANSWER
  • ANSWERING_MACHINE
  • ERROR_TONE
  • FAX
  • PERSON
  • CANCEL
  • CONNECTED
  • FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA
  • PUSH_DELIVERY_CONFIRMED
  • PUSH_SEND_ERROR
  • PUSH_DELIVERY_NOT_CONFIRMED
  • USERORIGINATED_CONNECTED

Notes:
1. FAILED_TO_ESTABLISH_CUSTOMER_ORIGINATED_MEDIA is a result that must be reported by the user application; otherwise, there is no CTI data that will enable Genesys Callback to identify this result.

2. CANCEL is set when the on_dial plugin returned action=CANCEL.

CALLBACK_DIM_2.FINAL_DIAL_RESULT (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)

_CB_DIM_OFFER_TIMING

Specifies whether the callback offer was made during operational (business) or non-operational hours. One of the following values:
  • ON-HOURS
  • OFF-HOURS
CALLBACK_DIM_2.OFFER_TIMING (referenced through CALLBACK_FACT.CALLBACK_DIM_2_KEY)

_CB_DIM_FINAL_TARGET

The routing target that was used to find the agent. CALLBACK_DIM_3.FINAL_TARGET (referenced through CALLBACK_FACT.CALLBACK_DIM_3_KEY)

_CB_ORS_SESSION_ID

Introduced: GMS 8.5.114.09

The Orchestration Server (ORS) session ID used to manage the callback. If multiple sessions were used (for example, because an ORS session terminated unexpectedly during the callback), the last session ID is reported. CALLBACK_FACT.ORS_SESSION_ID

_CB_EWT_WHEN_READY_TO_START_LAST_MEDIA_IXN

Introduced: GMS 8.5.200.07

Estimated Wait Time in seconds when the last dial attempt was made or the last push notification sent. CALLBACK_FACT.EWT_WHEN_LAST_DIAL

_CB_POS_WHEN_READY_TO_START_LAST_MEDIA_IXN

Introduced: GMS 8.5.200.07

Position in queue when the last dial attempt was made or the last push notification sent. CALLBACK_FACT.POS_WHEN_LAST_DIAL

_CB_PRIORITY_WHEN_CALLBACK_ACCEPTED

Introduced: GMS 8.5.200.07

Priority of the interaction (real or virtual) when the callback offer was accepted. CALLBACK_FACT.PRIORITY_WHEN_CB_ACCEPTED

_CB_PRIORITY_WHEN_CUSTOMER_CONNECTED

Introduced: GMS 8.5.200.07

Priority of the virtual interaction when the customer was connected. CALLBACK_FACT.PRIORITY_WHEN_C_CONNECTED

_CB_PRIORITY_AT_THE_END_OF_ONLINE_WAIT

Introduced: GMS 8.5.200.07

Priority of the virtual interaction when the customer was connected to the agent.

If the customer abandoned while waiting in queue, then this value is the priority of the call when the customer disconnected.

CALLBACK_FACT.PRIORITY_WHEN_A_CONNECTED

_CB_EWT_THRESHOLD_WHEN_OFFERED

Introduced: GMS 8.5.200.07

Value of the EWT threshold used to decide whether the callback offer should be made or not. Pass this value as an argument of the application that is responsible for making the callback offer. CALLBACK_FACT.EWT_THRESHOLD_WHEN_OFFERED


*This KVP must be sent twice -- as call-based attached data in a TEvent and as UserEvent-based user data.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 26 April 2018, at 20:43.