populate-workbin-as-hold
Section: gim-etl-populate
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies whether the time that an interaction is in an Interaction Workbin is considered to be hold time or mediation.
- false—Workbin time is considered to be mediation. Whether or not the workbin activity will be represented by an MSF record depends on the value of the populate-mm-workbin-facts option.
- true—Workbin time is considered to be hold if the handling resource places the interaction into its own personal workbin. The hold ends when any resource takes the interaction out of the workbin. Various hold metrics are reported in the IRF record that is associated with that handling resource.
populate-workbin-as-hold
Section: gim-etl-populate
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Dependencies: None
Specifies whether the time that an interaction is in an Interaction Workbin is considered to be hold time or mediation.
- false—Workbin time is considered to be mediation. Whether or not the workbin activity will be represented by an MSF record depends on the value of the populate-mm-workbin-facts option.
- true—Workbin time is considered to be hold if the handling resource places the interaction into its own personal workbin. The hold ends when any resource takes the interaction out of the workbin. Various hold metrics are reported in the IRF record that is associated with that handling resource.
populate-mm-ixnqueue-facts
Section: gim-etl-populate
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Dependencies: None
Enables or disables the population of eServices/Multimedia Interaction Queue activity to the MSF table. Genesys Info Mart uses this value for all configured eServices/Multimedia Interaction Queues, unless you configure an option that has the same name on an individual Script object for a specific Interaction Queue in the interface you use for configuration.
- false—The placement of an interaction in an Interaction Queue will not be represented in the MSF table.
- true—The placement of an interaction in an Interaction Queue will be represented in the MSF table.
Starting with release 8.5.003, Genesys Info Mart always creates an MSF record for the first Interaction Queue that an inbound interaction enters, regardless of the setting of this option.
populate-mm-ixnqueue-facts
Section: gim-etl-populate
Default Value: false
Valid Values: true, false
Changes Take Effect: On the next ETL cycle
Dependencies: None
Enables or disables the population of eServices/Multimedia Interaction Queue activity to the MSF table. Genesys Info Mart uses this value for all configured eServices/Multimedia Interaction Queues, unless you configure an option that has the same name on an individual Script object for a specific Interaction Queue in the interface you use for configuration.
- false—The placement of an interaction in an Interaction Queue will not be represented in the MSF table.
- true—The placement of an interaction in an Interaction Queue will be represented in the MSF table.
Starting with release 8.5.003, Genesys Info Mart always creates an MSF record for the first Interaction Queue that an inbound interaction enters, regardless of the setting of this option.
E-Mail Interactions
This page illustrates e-mail interaction flows that are available in multimedia deployments.
The e-mail interaction flows on this page describe the recognized, validated multimedia interactions that have been tested and that are supported by Genesys Info Mart for Genesys eServices e-mail. However, Genesys Info Mart supports full processing of any 3rd Party Media interactions, in addition to e-mail and chat interactions.
Use the e-mail interaction flows as a guide to interactions that do not involve an online session with a customer (offline interactions).
The interaction flows described in this guide are intended as examples that you can modify for your environment. However, Genesys does not guarantee results for modified interaction flows.
See Multimedia diagram conventions and Diagram Conventions for important information about interpreting the diagrams.
The following call flows are supported:
- Strategy routes e-mail to agent, and agent replies
- Agent invited into e-mail interaction, and invitation revoked
- E-mail interaction handled by a strategy with autoresponse
- Agent transfers e-mail directly to another agent
- Agent’s attempt to transfer e-mail directly to another agent fails
- Transfer of e-mail from agent to agent through a queue
- Unsuccessful transfer from agent to agent through a queue
- Transfer from agent to agent through a queue with multiple VQs
- Agent consults to another agent before sending reply — non-blocking
- Agent consults to another agent before sending reply — blocking
- Agent unsuccessfully consults to another agent before sending reply
- Agent saves draft reply before sending (mediation)
- Agent pulls e-mail from an Interaction Queue or Workbin
- Agent saves draft reply before sending (hold)
- Agent sends outbound e-mail
- Multipart reply
- Multipart e-mail reply with unsent reply
- Routing strategy repeatedly fails to find a target
Strategy routes e-mail to agent, and agent replies
The diagram shows the outcome of an e-mail interaction that a routing strategy routes to Agent 1, who accepts the invitation (IRF1).
Agent 1 creates an outbound reply e-mail (IRF2), closing the original inbound e-mail. The outbound e-mail is placed into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Completed
Agent invited into e-mail interaction, and invitation revoked
The diagram shows the outcome when an e-mail interaction is offered to an agent by a routing strategy, but the agent does not accept the invitation. The e-mail interaction is returned to the interaction queue so that it can be re-evaluated.
Technical Descriptors illustrated:
- RoutedTo/Redirected [Revoked]
E-mail interaction handled by a strategy with autoresponse
The diagram shows the outcome of an e-mail interaction that a routing strategy determines can be handled with an Autoresponse.
The e-mail is submitted to an inbound interaction queue. The routing strategy pulls the e-mail from the interaction queue and identifies that it can be handled with an Autoresponse, and an autoresponse is generated. Strategy 1 is now considered to be a handling resource. Strategy 1 connected to and stopped the original inbound interaction, represented in IRF1, and created an outbound Autoresponse reply, which is represented in IRF2. The time that Strategy 1 is connected to each e-mail is represented as “Talk” time. Outbound Queue and Outbound Strategy represent the processing that occurs when the e-mail is sent outside the contact center.
The diagram illustrates Genesys Info Mart reporting in releases earlier than 8.5.003 when the populate-mm-ixnqueue-facts configuration option is set to false. Starting with release 8.5.003, Genesys Info Mart always creates an MSF record for the first Interaction Queue that an inbound interaction enters before first handling, regardless of the value of the populate-mm-ixnqueue-facts option.
Technical Descriptors illustrated:
- Puller/Completed
- Initiated/Completed
Agent transfers e-mail directly to another agent
The diagram shows the outcome of an e-mail interaction that is routed to an agent, who transfers the e-mail to another agent, who replies to the e-mail.
Agent 1 (IRF1) transfers an inbound interaction to Agent 2. Agent 2 stops the original inbound interaction while creating an outbound reply (IRF2 and IRF3). The outbound reply is placed into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer. When an agent directly invites another agent into an interaction, the original agent remains in the interaction until the target agent accepts the invitation. In the case of a transfer, the transfer does not occur until the target agent accepts the invitation.
Technical Descriptors illustrated:
- RoutedTo/Transferred
- ReceivedTransfer/Completed
- Initiated/Completed
Agent’s attempt to transfer e-mail directly to another agent fails
The diagram shows the outcome of an unsuccessful attempt to transfer an e-mail to another agent.
The interaction is routed to Agent 1. Agent 1 accepts the inbound e-mail (IRF1) and creates an outbound reply (IRF2), closing the original inbound e-mail. Agent 1 works on this reply and then attempts to transfer this reply to Agent 2, for Agent 2 to complete the reply (IRF3). Agent 2 does not accept the invitation into the interaction. Agent 1 remains in the interaction during the attempt to transfer. In this case, since Agent 2 was not available, Agent 1 completes the reply and places it into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Completed
- ReceivedTransfer/Abandoned [Revoked]
Transfer of e-mail from agent to agent through a queue
The diagram shows the outcome of an e-mail interaction that is routed to an agent, who transfers the e-mail through a queue to another agent, who replies to the e-mail.
Agent 1 transfers an inbound interaction through Interaction Queue 2 to Agent 2 (IRF2). Agent 2 stops the original inbound interaction while creating an outbound reply (IRF2 and IRF3). The outbound reply is placed into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer.
Technical Descriptors illustrated:
- RoutedTo/Transferred
- ReceivedTransfer/Completed
- Initiated/Completed
Unsuccessful transfer from agent to agent through a queue
The diagram shows the outcome of an unsuccessful attempt to transfer an e-mail interaction from one agent to another agent through a queue.
The interaction is routed to Agent 1. Agent 1 accepts the inbound e-mail (IRF1) and creates an outbound reply, closing the original inbound e-mail (IRF2). Agent 1 works on this reply, and then attempts to transfer the reply interaction through Interaction Queue 2 to another agent for continued processing. The reply interaction is routed from the queue to Agent 2 (IRF3). Agent 2 does not accept the invitation, and this revoked invitation is returned to Interaction Queue 2, so that another routing target can be found.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Transferred
- ReceivedTransfer/Redirected [Revoked]
Transfer from agent to agent through a queue with multiple VQs
The diagram shows the outcome of an inbound e-mail interaction that is routed to an agent, who transfers the e-mail through a queue to another agent, when the routing strategies contain several VQs. In this example, Strategy 1 contains three parallel VQs (VQ1, VQ2, VQ3) and Strategy 2 contains three sequential VQs (VQ4, VQ5, VQ6).
Strategy 1 takes the e-mail from Interaction Queue 1 and places the e-mail simultaneously in all three VQs that are associated with the strategy. Strategy1 finds a routing target through VQ1 and routes the interaction to the target (Agent 1).
Agent 1 handles the e-mail (IRF1) and then decides to transfer it to another agent through Interaction Queue 2, for continued processing. Strategy 2 takes the e-mail from Interaction Queue 2 and places it in VQ4. When Strategy 2 does not find an available agent who is associated with VQ4, the strategy places the e-mail in VQ5, where it finds an available agent (Agent 2). The strategy routes the e-mail to Agent 2 (IRF2). Because the interaction did not reach the third VQ that is associated with Strategy 2, there is no MSF for VQ6. Given the focus of this example, the diagram does not show the continued processing after Agent 2 gets control of the interaction; the technical result for IRF2 depends on what Agent 2 does with the interaction.
The diagram illustrates Genesys Info Mart reporting in releases earlier than 8.5.003 when the populate-mm-ixnqueue-facts configuration option is set to false. Starting with release 8.5.003, Genesys Info Mart always creates an MSF record for the first Interaction Queue that an inbound interaction enters, regardless of the value of the populate-mm-ixnqueue-facts option.
Technical Descriptors illustrated:
- RoutedTo/Transferred
- ReceivedTransfer/depends on subsequent activity
Agent consults to another agent before sending reply — non-blocking
The diagram shows an agent consulting with another agent before sending a reply, when the first agent continues to work on the reply during the consultation period.
The interaction is routed to Agent 1. Agent 1 accepts the inbound e-mail (IRF1) and creates an outbound reply (IRF2), closing the original inbound e-mail. Agent 1 initiates a Consult interaction and transfers it to Agent 2 (IRF3). Agent 2 accepts the Consult interaction (IRF4) and initiates a Consult Reply interaction (IRF5). In a typical Consult scenario, the Consult Reply is placed into Agent 1’s Collaboration Workbin. The Consult Reply typically remains in the workbin for the life of the entire interaction, enabling the Consult Reply to be viewed at any time during the processing of the interaction and making it available for viewing by another agent, if Agent 1 transfers ownership of this interaction to another agent. The outbound reply is placed into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer.
By placing the Consult Reply in Agent 1’s Collaboration Workbin, Agent 2 transfers the Consult Reply back to Agent 1. In a common scenario, the Consult Reply remains in the Collaboration Workbin for the remainder of the interaction, until it is cleaned up when the interaction ends. At that time, a new IRF row (not shown) is added, to show the Consult Reply being pulled from the workbin and Completed. The “Talk” boxes in the Consult portion of the diagram are not shaded, because the customer is not considered to be present during offline consultations.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Completed
- InitiatedConsult/Transferred
- ReceivedConsult/Completed
- ReceivedConsult/Transferred
Agent consults to another agent before sending reply — blocking
The diagram shows an agent consulting with another agent before sending a reply, when the first agent suspends work on the reply until the consultation response is received.
The interaction is routed to Agent 1. Agent 1 accepts the inbound e-mail (IRF1) and creates an outbound reply, closing the original inbound e-mail (IRF2). Agent 1 initiates a Consult interaction and transfers it to Agent 2 (IRF3). In the meantime, Agent 1 suspends work on the outbound reply and places it in a Draft Workbin (MSF3), until the results of Agent 2’s collaboration are available. Agent 2 accepts the Consult interaction (IRF4) and initiates a Consult Reply interaction (IRF5). After working on the Consult Reply, Agent 2 places it in Agent 1’s Collaboration Workbin (MSF4), where it typically remains for the remaining life of the interaction. Agent 1 retrieves the suspended outbound reply from the Draft Workbin and completes the reply (IRF6).
The outbound reply is placed into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer.
For the time that the interaction is in Agent 1’s Draft Workbin, the diagram illustrates the situation when workbin time is considered to be mediation (populate-workbin-as-hold=false). Agent saves draft reply before sending (hold) shows the flow for this portion of the interaction when the workbin time is considered to be hold.
By placing the Consult Reply in Agent 1’s Collaboration Workbin, Agent 2 transfers the Consult Reply back to Agent 1. In a common scenario, the Consult Reply remains in the Collaboration Workbin for the remainder of the interaction, until it is cleaned up when the interaction ends. At that time, a new IRF row (not shown) is added, to show the Consult Reply being pulled from the workbin and Completed.
The “Talk” boxes in the Consult portion of the diagram are not shaded, because the customer is not considered to be present during offline consultations.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Transferred
- InitiatedConsult/Transferred
- ReceivedConsult/Completed
- ReceivedConsult/Transferred
- Puller/Completed
Agent unsuccessfully consults to another agent before sending reply
The diagram shows an agent’s unsuccessful attempt to consult with another agent before sending a reply.
The interaction is routed to Agent 1. Agent 1 accepts the inbound e-mail (IRF1) and creates an outbound reply, closing the original inbound e-mail (IRF2). Agent 1 initiates a Consult interaction (IRF3) and transfers it to Agent2. Agent 2 does not accept the invitation into the Consult interaction (IRF4). Agent 1 continues working on the outbound reply (IRF2). The outbound reply is placed into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Completed
- InitiatedConsult/Transferred
- ReceivedConsult/Abandoned [Revoked]
Agent saves draft reply before sending (mediation)
The diagram shows the outcome of an e-mail interaction that is routed to an agent who replies to the e-mail, after first saving an initial version of the reply in a workbin, where the time in the workbin is considered to be mediation.
The interaction is routed to Agent 1. Agent 1accepts the inbound e-mail (IRF1) and creates an outbound reply, closing the original inbound e-mail (IRF2). Agent 1 saves the outbound reply e-mail in a Draft Workbin. Later, Agent 1 pulls the reply e-mail from the workbin, makes some final modifications to the reply, and then places the reply into Outbound Queue, from which Outbound Strategy sends it out of the contact center to the customer (IRF3).
For the outcome of the same interaction flow when the workbin time is considered to be hold, see Agent saves draft reply before sending (hold).
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Transferred
- Puller/Completed
Agent pulls e-mail from an Interaction Queue or Workbin
The diagram shows the outcome when an e-mail interaction is pulled from an Interaction Queue or Workbin (MSF1) for further handling by Agent 1. After working on the e-mail, Agent 1 places the interaction into another Interaction Queue or Workbin (MSF2), for further processing.
Technical Descriptors illustrated:
- Puller/Transferred
Agent saves draft reply before sending (hold)
The diagram shows the outcome of an e-mail interaction that is routed to an agent who replies to the e-mail, after first saving an initial version of the reply in a workbin, where the time in the workbin is considered to be hold, instead of mediation.
For information about when workbin time is considered to be hold, read the description of the populate-workbin-as-hold option.
For the outcome of the same interaction flow when the workbin time is considered to be mediation, see Agent saves draft reply before sending (mediation).
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Completed
Agent sends outbound e-mail
The diagram shows the outcome of an e-mail interaction that the agent initiates. In other words, the e-mail is not a response to an e-mail that has been routed to the agent or transferred to the agent.
This scenario applies when an agent sends an unsolicited outbound interaction to a customer or, starting with release 8.5.003, the agent is sending an outbound reply to a customer where the interaction being replied to has already been terminated in Genesys Info Mart.
Technical Descriptors illustrated:
- Initiated/Completed
Multipart reply
The diagram shows the outcome of a multipart reply.
In this example, Agent 1 initiates two outbound replies. For example, Agent 1 may have received a new customer order (IRF1) and initiated one reply, which is to be completed by Agent 2 in Shipping (IRF2). At the same time, Agent 1 also initiated a reply to the customer, confirming the order and providing billing-related information. Agent 1 transfers the first outbound reply directly to Agent 2 (IRF3). Agent 1 remains in this outbound reply until Agent 2 accepts the invitation into the interaction. Agent 2 later completes this reply, placing it in an Outbound Queue, from which Outbound Strategy sends it out of the contact center. Agent 1 also creates and completes the second outbound reply (IRF4), now stopping the original inbound interaction, and places this second reply in an Outbound Queue, from which Outbound Strategy sends it out of the contact center. In this example, the second reply that Agent 1 created was actually the first reply sent to the customer.
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Transferred
- ReceivedTransfer/Completed
- Initiated/Completed
Multipart e-mail reply with unsent reply
The diagram shows the outcome of a multipart reply in which one of the replies was stopped without being sent.
This example illustrates the OutboundStopped technical result. The OutboundStopped technical result applies to any outbound multimedia interaction that is stopped without being sent; it is not limited to outbound replies. In this example, the outbound reply initiated by Agent 1 (IRF2), and transferred to Agent 2, is stopped by Agent 2 (IRF3). Agent 2 worked on the outbound reply for some time, but then stopped the reply without sending it. In the meantime, as in Multipart reply, Agent 1 worked on a second reply, which was sent to the customer (IRF4).
Technical Descriptors illustrated:
- RoutedTo/Completed
- Initiated/Transferred
- ReceivedTransfer/OutboundStopped
- Initiated/Completed
Routing strategy repeatedly fails to find a target
The diagram shows the outcome of an inbound e-mail interaction that is eventually routed to an agent after the routing strategy repeatedly failed to find an available agent.
In this example, Strategy 1 puts the interaction back into Interaction Queue 1 several times, until the strategy finally routes the interaction successfully to Agent 1 (IRF1). All the unsuccessful attempts to select an agent are combined into one mediation (MSF1 for Interaction Queue 1), except for the last attempt, which is when the interaction was successfully routed (MSF2 for VQ1). Given the focus of this example, the diagram does not show the continued processing after Agent 1 gets control of the interaction; the technical result for IRF1 depends on what Agent 1 does with the interaction.
Technical Descriptors illustrated:
- RoutedTo/depends on subsequent activity
