Populating Interaction Resource Data

Genesys Info Mart stores interaction resource facts in the INTERACTION_RESOURCE_FACT (IRF) table, one of the core tables that is supplied in Genesys Info Mart. This table facilitates the creation of reports and serves as one of the primary tables from which aggregation tables are populated. (See the Reporting and Analytics Aggregates documentation set for details on aggregation tables.)

What do IRFs represent?

Genesys Info Mart creates IRFs to represent the involvement of a contact center resource of interest in an interaction. Resources of interest in the IRF context are:

• Handling resources — Agents, self-service IVRs, DNs without an agent, and multimedia strategies that handle an interaction (for example, a strategy that sends an AutoResponse). Genesys Info Mart creates a row in the IRF table whenever a new interaction or a new attempt to handle an existing interaction has been started, or when an interaction arrives at a handling resource.
• Mediation resources in which the interaction ends. Genesys Info Mart creates a row in the IRF table whenever an existing interaction terminates while in a mediation resource, such as a queue, routing point, or nonself-service IVR.

The IRF table supplies a single row within the Genesys Info Mart schema, which simplifies the SQL needed to generate reports on the resources that handle interactions within the contact center.

Each IRF represents:

• The contiguous time span of the association between the resource and the interaction
• The particular role played by the resource (the resource role)
• The result of the association from the perspective of the resource (the technical result)

IRFs are created for completed voice interactions and for both completed and active multimedia interactions. For more information, see How are IRFs populated?

IRF features

The IRF table:

• For interactions of any media type, provides counts and durations that categorize the time spent on the interaction in various activities, such as time spent in a queue, time spent handling the interaction, and time spent wrapping up the interaction. Because not all IRF activity involves a customer directly, separate counts and durations are included to reflect the time that the customer spent waiting versus being helped.
• Simplifies report queries by integrating conference and consultation durations into the original handling-resource row.
• Summarizes the total queue, routing point, and IVR wait times prior to the handling resource and stores the summary data with the handling-resource row in separate columns.
• Stores response duration per routing attempt, in addition to the initial routing sequence.
• Records the state of the resource immediately prior to involvement in the interaction, thus enabling reporting of interactions received or initiated during an AfterCallwork or NotReady agent state.
• Links the IRF to associated MEDIATION_SEGMENT_FACT records (MSFs), to provide information about:
  • The last mediation segment that was involved in the interaction, regardless of whether the interaction was distributed to a handling resource (LAST_MEDIATION_SEGMENT_ID)
  • The interaction resource that originated a transfer, conference, or voice consultation (RECEIVED_FROM_IXN_RESOURCE_ID)

Together with fields in the MSF table that link associated MSFs to the IRF, these fields enable downstream reporting applications to report on transfer details and queue activity, including interactions that were abandoned or cleared in virtual queues.

• If Genesys Info Mart has been configured to populate thread metrics (in other words, populate-thread-facts=true), provides thread metrics and agent-unique metrics for an interaction or thread, which identify whether the IRF represents:
  • This agent’s first participation in the interaction (where “this agent” refers to the agent resource that is the subject of the IRF record)
  • This agent’s first participation in a reply within the interaction
  • This agent’s first participation in the interaction thread
  • This agent’s first participation in a reply within this interaction thread
  • The first participation by any handling resource in the interaction thread
• For voice calls, provided that T-Server and ICON have been configured to provide the required data, indicates whether a given resource initiated release of the call.

For detailed information about the columns in the IRF table, see the Genesys Info Mart Physical Data Model for your RDBMS (for Microsoft SQL Server, Oracle, or PostgreSQL, respectively).

How are IRFs populated?

IRFs represent either the processing of interactions by handling resources (such as agents, self-service IVRs, and extensions/positions without associated agents) or unsuccessful attempts to reach such a handling resource (resulting in the interaction being abandoned in queue or abandoned in routing).

Each IRF row includes all prior queue, routing point, and IVR (nonself-service) counts and durations that were part of the distribution of the interaction to the resource.

The grain of the fact is an accumulating snapshot of the contiguous participation of a contact center handling resource in interaction processing, including time spent wrapping up the interaction. Movement of a resource from one call to another does not cause creation of a new IRF, but is accumulated in a single fact. For example, when the transferredTo resource in a transfer scenario is moved from a consult call to the original call, this movement is represented in a single fact.

However, if a handling resource is participating in parallel calls, the resource is represented by two separate facts. For example, in a consultation call scenario there are two IRFs for the consulting resource, one for the existing call and one for the consultation call.

Special handling for Genesys Callback

Starting with release 8.5.005, Genesys Info Mart supports reporting on Genesys Callback activity on voice, web, or mobile channels, in deployments with Genesys Mobile Services (GMS). For premise customers, Genesys Info Mart support for Genesys Callback reporting is provided out-of-box. For more information about release and configuration requirements for GMS, ICON, and other components to support Genesys Callback reporting, see the information about setting up historical reporting in the Callback Solution Guide.

Callback applications provide Callback-related data that Genesys Info Mart processes and stores in dedicated CALLBACK_* tables, which were initially introduced in an earlier Genesys Info Mart release. The CALLBACK_FACT (CBF) table stores callback-specific facts, based on information GMS sends in UserEvents. There is one CBF record for each UserEvent that has callback information. For more information about the Callback-related tables, see the Genesys Info Mart Physical Data Model for your RDBMS (for Microsoft SQL Server, Oracle, or PostgreSQL, respectively).

Genesys Info Mart creates the following IRFs for Callback interactions:

• One IRF for the original customer interaction. The technical result is Deferred/CallbackAccepted, MET_SERVICE_OBJECTIVE=0, and IRF_ANCHOR=1.
• One IRF for each callback media attempt, identified by the new interaction subtype, OutboundCallback. There might be many callback media attempts before the callback completes. Genesys Info Mart treats the media attempts as predictive outbound calls. The technical result of Completed indicates a successful callback; a new technical result, Incomplete, is used in all other cases (for example, the wrong person was contacted or the callback was canceled).

IRFs relate to their associated CBF records via the SERVICE_ID. In releases earlier than 8.5.015.19, Genesys Info Mart never created MSFs associated with either the original call or the callback media attempts. Starting with release 8.5.015.19, you can use the cb-virtual-queue-pattern configuration option to fine-tune which, if any, callback virtual queues you want to exclude from mediation reporting.

Without the special handling, Genesys Info Mart:

• Treats the original interaction as being abandoned by the customer. Depending on how long the callback spent in the virtual queue and on the chunk size, Genesys Info Mart might populate an MSF for the virtual queue with a technical result of Diverted.
• Treats failed media attempts as being abandoned by the customer.

Special handling for Designer applications

Starting with release 8.1.402.07, in preparation for supporting interaction flows that involve applications developed with Genesys Designer, Genesys Info Mart provides alternative reporting for voice call flows that use Designer applications; these applications are loaded on a routing point and consist of self-service and assisted-service phases. (Support for Genesys Designer is available in certain Genesys Engage cloud and on-premises implementations.)

• If the call ends during the self-service phase of the Designer application, instead of creating an IRF for the routing point with a technical result of CustomerAbandoned/AbandonedWhileQueued, Genesys Info Mart creates an IRF for the Designer application, just as it would for any other self-service IVR application. The entire time that was spent in the application is represented as handling or talk time, and the technical result is Completed/Unspecified.
• If the call leaves the self-service phase and then is either routed to an agent from the assisted-service phase or abandoned from the assisted-service phase, Genesys Info Mart reports the time spent in the self-service phase as IVR_PORT_DURATION in the resulting IRF for the agent or routing point. ROUTING_POINT_DURATION encompasses the total time spent in the application and overlaps with IVR_PORT_DURATION.

The following table summarizes the reporting results for interaction flows that involve Designer applications.

IRF Resource	Technical Descriptor	Customer Handle Count	Talk Count/ Duration	Mediation Count	Routing Point Duration	IVR Port Duration
Scenario 1: Call ended or abandoned in the self-service phase An inbound call arrives at a routing point, RP 123, where the Designer application named TestApplication is running. The self-service phase is entered and 10 seconds is spent playing messages, presenting menu options, and so on. After 10 seconds, either TestApplication ends the call or the customer hangs up.
TestApplication	Received/Completed/ Unspecified	1	1/10	0	0	0
Scenario 2: Call abandoned in the assisted-service phase An inbound call arrives at a routing point, RP 123, where the Designer application named TestApplication is running. The self-service phase is entered and 10 seconds is spent playing messages, presenting menu options, and so on. After 10 seconds, the assisted-service phase is entered, and the call spends 2 seconds in assisted service before the customer hangs up, before being routed to an agent.
RP 123	Received/CustomerAbandoned/ AbandonedWhileQueued	0	0/0	2	12	10
Scenario 3: Call routed to agent An inbound call arrives at a routing point, RP 123, where the Designer application named TestApplication is running. The self-service phase is entered and 10 seconds is spent playing messages, presenting menu options, and so on. After 10 seconds, the assisted-service phase is entered, and the call spends 2 seconds in assisted service before being routed to Agent1 and then handled by the agent for 60 seconds.
Agent1	RoutedTo/Completed/ Unspecified	1	1/60	2	12	10

Special handling for “runaway strategies”

Special logic protects Genesys Info Mart from being overwhelmed by strategies that cause very large quantities of Party, Virtual Queue, and Party History records in IDB. In most cases, having very large numbers of parties and virtual queues involved in a single interaction results from inappropriate strategies, which generate excessive numbers of unsuccessful attempts to route interactions to a handling resource. For example, a strategy might be configured to pull a batch of multimedia interactions from an Interaction Queue, attempt to route the interactions, place the interactions that it was not able to route back into the Interaction Queue, and retry at 1-second intervals.

In these “runaway strategy” scenarios, the transformation job abbreviates the representation of unsuccessful routing attempts.

Genesys Info Mart’s handling of “runaway strategy” scenarios changed a number of times between the initial 8.1.0 release and release 8.1.401.02, when the max-msfs-per-irf configuration option was introduced, enabling you to control the number of MSF records associated with a single IRF record in the Info Mart database. For more details, see the option description in the Genesys Info Mart Options Reference.

For information about the way that queue and routing point metrics for “runaway strategy” interactions are populated in IRF records, see the IRF column descriptions in the Genesys Info Mart Physical Data Model for your RDBMS (for Microsoft SQL Server, Oracle, or PostgreSQL, respectively).

Genesys recommends that users in large-scale, production-level environments evaluate their strategy configurations, to minimize the risks to data quality by ensuring that their environments are not susceptible to these types of scenarios.

Dimensions associated with the IRF table

• IRF start and end dates and times are stored as UTC timestamps (START_TS and END_TS) and as references to the DATE_TIME dimension (START_DATE_TIME_KEY and END_DATE_TIME_KEY). For more information, see Representing Dates and Times of Day.
• The RESOURCE_ dimension indicates the routing point, queue, IVR, or agent that either initiated or handled this resource fact. The RESOURCE_ dimension actually has two references, RESOURCE_KEY and MEDIA_RESOURCE_KEY, which typically refer to the same resource. The following are exceptions:
  • For IVRs, RESOURCE_KEY is for the IVR Application Name and MEDIA_RESOURCE_KEY for the associated DN.
  • For Agents, RESOURCE_KEY is for the Agent, and MEDIA_RESOURCE_KEY for the associated DN.
• The PLACE dimension indicates the place at which the IRF was processed.
• The TENANT dimension identifies the tenant of the resource.
• The TECHNICAL_DESCRIPTOR dimension identifies the resource role and technical result of the IRF. For information about the resource roles and technical results for interaction resources, see Technical Descriptors.
• The INTERACTION_DESCRIPTOR dimension identifies the customer segment (indicating the value of the customer), the type of service being requested, and the business result of the IRF.
• The STRATEGY dimension identifies the Genesys routing strategy or IVR application that processed the IRF.
• The ROUTING_TARGET, REQUESTED_SKILL, and REQUESTED_SKILL_COMBINATION dimensions indicate Genesys Universal Routing Server (URS) activities by identifying the target that was selected and the list of skills that were required to process the IRF.
• The CUSTOMER dimension represents the ID of the customer that is involved in the interaction.
• If Genesys Info Mart has been configured to populate thread metrics, the ANCHOR_FLAGS dimension supports metrics about unique agent participation in an interaction or thread. For related information, see Interaction Threads.

Supporting tables

Genesys Info Mart uses the following additional tables to support the IRF table:

• The IXN_RESOURCE_STATE_FACT table contains all the individual states, durations, and interval clips for each state the interaction-fact resource was in during the interaction.
• The INTERACTION_RESOURCE_STATE dimension table contains the states defined for the resource that is handling the interaction.

User data

Many interaction attributes are formally modeled. However, deployment-specific attributes, in the form of user-defined attached data, are also represented in the model.

Genesys Info Mart provides unified user-data processing from both call-related EventUserEvents and call-based TEvents, with flexible data storage that you can configure according to the number and types of user data captured in your contact center environment. A customizable database schema enables you to treat each key-value pair (KVP) field as a fact, a dimension, or both, and to store user data KVPs in a configurable number of user data dimensions and facts that are associated with core fact tables. Genesys Info Mart also processes the user data that arrives after call completion and updates call records accordingly.

There are two kinds of user data:

• High-cardinality user data — Data for which there can be a very large number of possible values. A Customer ID number is an example of high-cardinality user data. You can configure Genesys Info Mart to store the KVP value as a character data type, as a numeric data type, or as a date/time data type.
• Low-cardinality user data — Data for which there is a limited range of possible values. Customer Segment, Service Type, and Service Subtype are good examples of low-cardinality user data. For example, in a CUSTOMER table with a column named NEW_CUSTOMER, this column would contain only two distinct values, Y or N, which respectively denote whether the customer was new or not. Because only two possible values are held in this column, its cardinality type is low cardinality.

High-cardinality user data is stored as facts. Low-cardinality user data is most efficiently stored as dimensions. You can create up to 800 custom low-cardinality user data dimensions. The only limits on the quantity of high-cardinality user data that you store are performance based. There are no absolute limits.

High-cardinality user data requires only a single join from the IRF table. Low-cardinality user data that is stored as dimensions requires two joins, one to the CTL_UDE_KEYS_TO_DIM_MAPPING table and another to the dimension table.

You can use the same KVP as both fact and dimension. Genesys provides templates for you to configure your own User Data keys.

Important

Be aware that other Genesys applications might use Genesys-defined KVPs. Depending on your reporting needs, you might need to co-ordinate use of Genesys-defined KVPs in your deployment by modifying the behavior of your routing strategies or, on the Genesys Info Mart side, changing the propagation rule for a particular KVP or creating a custom KVP.

For example, by default, the Genesys gateway application for Web Real-Time Communication (WebRTC) uses the ServiceType KVP with a value of WebRTC to indicate that the interaction is a WebRTC call. By default, Genesys Info Mart will store INTERACTION_DESCRIPTOR.SERVICE_TYPE=WebRTC, unless a routing strategy subsequently attached the ServiceType KVP with a different value during the call.

Customer and noncustomer metrics

Each IRF record includes numerous *_COUNT and *_DURATION metrics. There are two categories of metrics:

• Customer metrics (prefixed by CUSTOMER_), which reflect the “customer experience” — that is, how the customer was treated during an interaction
• Noncustomer metrics (not prefixed by CUSTOMER_), which reflect the “handling resource experience” — that is, how the contact center’s handling resources spent time in an interaction

For detailed descriptions of the metrics, see the IRF column descriptions in the Genesys Info Mart Physical Data Model for your RDBMS (for Microsoft SQL Server, Oracle, or PostgreSQL, respectively).

The table below summarizes which party is considered to be the customer and which is the handling resource for various types of interactions.

“Customer” and Handling Resource, by Type of Interaction

Type of Interaction	“Customer”	Handling Resource
Inbound	The external party that initiated the interaction to the contact center	The contact center party that receives the interaction
Internal	The internal party that initiated the interaction within the contact center	The contact center party that receives the interaction
Outbound	The external party that is contacted by the contact center	The contact center party that initiated the interaction or, in the case of Outbound Contact, that was offered the interaction for handling
Consultation	None	Both contact center parties that are involved in the consultation: The party that initiates the consultation The party that receives the consultation

Customer metrics

IRFs are created only for contact center resources. As shown in the table above, the customer is generally an external party, for whom no IRF is created. Customer metrics accrue on the IRF for the handling resource, to show the customer experience alongside the noncustomer (handling resource) experience in the same IRF.

In this document, the time that the customer is considered to be present in the interaction is referred to as customer time.

Voice

For voice calls, customer time accrues on the IRF for the party that is considered to be the handling resource (as indicated in the table above), as long as the party that is considered to be the customer is present in the context of the IRF. (For the IRF that represents an outbound or initiated Outbound Contact call, customer dial time accrues even though the customer is not yet present on the call.) Customer time stops accruing at the moment the party that is considered to be the customer releases or is released from the call.

For consultations, as shown in the table above, both the initiator and the receiver of the consultation are handling resources. There is no customer present on the consultation, and no customer time accrues on the IRFs related to the consultation.

For graphical representations of customer time in various call topologies, see Validated Voice Call Flows.

Multimedia

For multimedia interactions, as for voice calls, customer time accrues on the IRF for the party that is considered to be the handling resource (as indicated in the table above), However, for multimedia interactions, unlike for voice calls, the notion of the customer being present often does not apply. In order for Genesys Info Mart to represent the customer experience for multimedia interactions, all time that the handling resource spends handling a multimedia interaction is considered to be customer time, except for initiated and received consultations (or e-mail collaborations).

For graphical representations of customer time in various interaction topologies, see Validated Multimedia Interaction Flows.

Noncustomer metrics

Noncustomer metrics accrue on all types of IRFs. Noncustomer metrics are divided into separate “buckets” that represent the possible different phases of an interaction — interaction initiated or offered, initiated consult, received consult, post-consult transfer, conference initiated, conference joined.

ASM engage metrics

When Outbound Contact campaigns run in an Active Switching Matrix (ASM) dialing mode, the time that the engaged agent is waiting to be connected to the customer is referred to as ASM engage duration. Starting with release 8.5.004, the populate-irf-asm-engage-duration option enables you to configure Genesys Info Mart to report ASM engage duration separately from agent talk time in VoIP environments. For more information, see the descriptions of the IRF.ASM_COUNT and IRF.ASM_ENGAGE_DURATION columns in the Genesys Info Mart Physical Data Model for your RDBMS (for Microsoft SQL Server, Oracle, or PostgreSQL, respectively).

Reporting implications

There are two important considerations for your reports:

• Customer and noncustomer metrics are not necessarily equal — The counterpart customer and noncustomer metrics (for example, CUSTOMER_TALK_DURATION and TALK_DURATION) accrue in parallel within a given IRF, but you cannot assume that they will be equal. The respective values of the metrics depend on:
  • The behavior of the parties in the specific interaction. For example, in a voice call topology that includes a conference between the customer and two agents, the customer and noncustomer representations of talk duration will not be the same if the handling resource continues on the conference after the customer hangs up.
  • The type of interaction. For example, in the IRFs for the initiator and the receiver of a consultation, CUSTOMER_TALK_DURATION will be 0 (zero), while CONS_INIT_TALK_DURATION and CONS_RCV_TALK_DURATION, respectively, will be nonzero.
• Overlapping IRFs — For noncustomer metrics, the “buckets” that represent the separate phases of an interaction do not overlap within a single IRF, but they can overlap for parallel IRFs. For example, when the handling resource on an inbound interaction initiates a consultation, there will be two parallel IRFs with overlapping HOLD_DURATION and CONS_INIT_TALK_DURATION metrics.

Recommendations and tips

Observe the following guidelines:

• Do not try to combine customer and noncustomer metrics.
• Do not expect that the sum of noncustomer metrics will equal the sum of customer metrics.
• To avoid double-counting time from overlapping IRFs for a given agent, do not combine IRFs that represent initiated consultations with other IRFs for the same agent. Instead, use initiated-consultation IRFs to calculate consultation metrics separately.
• For voice calls, use customer metrics when the reporting focus is on the customer experience. Use noncustomer metrics when the focus is on the activities of the handling resource(s), regardless of whether the customer party is present on the call.
• For multimedia interactions, use customer metrics when you do not want to consider e-mail collaboration or chat consultation time. Use noncustomer metrics when you want to include collaboration/consultation time.
• The HANDLE_COUNT and CUSTOMER_HANDLE_COUNT fields are useful to identify various interaction scenarios. For example, the following table summarizes the different results in these fields for the resource that is the subject of the IRF (IRF resource), for a number of common scenarios.

HANDLE_COUNT and CUSTOMER_HANDLE_COUNT Values

Scenario	Type of Interaction	HANDLE_COUNT	CUSTOMER_HANDLE_COUNT
Any outbound interaction initiated by an IRF resource	Outbound	1	1
Any interaction offered to an IRF resource that is accepted (answered) by that IRF resource	Inbound, internal, or outbound	1	1
Any interaction offered to an IRF resource that is not accepted by that IRF resource (for example, redirected or abandoned)	Inbound, internal, or outbound	0	0
Any consultation initiated by an IRF resource where there is an InitiatedConsult IRF (in other words, not including chat consultations, for which there is no InitiatedConsult IRF)	Consultationa	1	0
Any consultation offered to an IRF resource that is accepted (answered) by that IRF resource	Consultationa	1	0
Any consultation offered to an IRF resource that is not accepted by that IRF resource (for example, redirected or abandoned)	Consultationa	0	0

a. Strictly speaking, a consultation (collaboration) is not itself a type of interaction; it occurs within the context of an interaction.

Limitation for customer-related voice activity

In general, the IRF table is populated in a way that enables downstream reporting applications to distinguish customer-related activity, including transfers and conferences, from internal agent–related activity — for example, in data and metrics such as the Technical Descriptor, CONFERENCE_INITIATED_COUNT, and CUSTOMER_HANDLE_COUNT.

However, the population of the dimensional model breaks down for consult/transfers and consult/conferences that occur within an existing conference: When a voice interaction contains a conference that involves a customer and more than one agent, and one of those agents initiates a subsequent transfer or conference out of the first conference, there is no clear way to reliably determine whether the customer is still present when the subsequent transfer or conference occurs. Therefore, metrics such as count of customer-related transfers or count of customer-related conferences cannot be calculated reliably, although the equivalent metrics for internal agent–related transfers or conferences can.

Abandoned and terminated interactions

To represent every interaction in the IRF table, rows are created to represent attempts to reach a resource of interest. These rows contain data about queues, routing points, and routing queues in which the interaction has been abandoned in the distribution device by the customer, during a consultation, or during an internal call that was initiated by a resource of interest.

Abandoned interactions

Abandoned interactions are identified as interactions in which the last resource that was involved was not a handling resource. In such cases a row is created to represent an attempt to reach another handling resource. This IRF row contains data from all prior related mediation device segments that were involved with the attempt to reach another handling resource.

Interactions terminated in a mediation IVR or DN (no IVR or agent resource association)

A mediation IVR in the context of the IRF table is an IVR resource that is not considered to be self-service because the IVR application (or a URS strategy on its behalf) did not set attached data to indicate self-service. An interaction that terminates in a mediation IVR is considered to be abandoned.