Digital Channels in Designer
This topic gives you an introduction to the digital channels available in Designer and highlights some best practices when working with these channels.
Overview
Digital Channels in Designer refer to all channels except voice. We can further classify them into immediate channels like chat and near immediate channels that typically involve intermittent communication or activity such as email.
Designer applications can work with all these digital channels either through the default General application type which is reserved for both immediate and near immediate channels or through a second application type called Digital, which is reserved for working exclusively with the near immediate channels. Some of these channels may support multiple flavors of media processing components.
Most Genesys components fall under the 8.x or 9.x versions. 9.x is at times prefixed with advanced, for example, advanced chat. Depending on the version of the component the features vary and it is best to always use the current version. For instance, it is best to use chat 9.x or advanced chat in Designer, and not chat 8.x, as 8.x does not offer the ability to interact with the user by collecting input from the user. Also, chat 8.x is limited only to sending messages from the application to the user.
The Interaction
Designer and other components in Genesys work with a generic concept called an Interaction. An interaction represents an instance of, say, an email or a chat session or an open media item which needs to be processed by one or more Designer applications. Each interaction has a type of media associated with it and based on this type of media it may have different attributes. For example, a chat interaction may have an email associated with it but an open media interaction may not.
All Genesys services and components work with this central idea of an interaction. Based on the data associated with an interaction which is typically called user data or attached data, these services and components can provide interactivity for the particular interaction if the channel supports it, can route the interaction to an agent, and finally report on the interaction.
Note that Designer Analytics does not report on interactions - instead, it reports on application sessions. Application sessions process interactions. An incoming interaction typically triggers an application through a contact point associated with the application. For chat, this may be a chat and for email this could be a POP mailbox associated with an interaction. Once the application is triggered, it starts working with the interaction providing interactivity and processing, reporting on it, and routing it. The application also controls the lifecycle of the interaction including terminating the interaction.
A single interaction may be processed by multiple applications and will therefore have multiple sessions that work on that interaction. In most cases these are sequential sessions punctuated by non-automated processing like interacting with an agent. For example, an incoming chat may be processed by an application that interacts with the chat user, and then offers a survey. If the user accepts it, the application flags the interaction for a survey and routes it to an agent. Once that agent communication is finished the interaction will be processed by a second Designer application which will do the actual survey - present questions and collect answers. In this use case we will have two Designer sessions associated with this interaction and we will have two session detail records in Designer Analytics, processing the same interaction, but sequentially – one before reaching the agent and the second, after the agent wraps up.
Life cycle of an Interaction
An interaction is created in the Genesys PureEngage ecosystem when an external integration into Genesys triggers some processing. This could be an email sent to a mailbox monitored by the Genesys email solution, or a chat sent from a webpage into the Genesys Chat service or a Facebook post, and so on. Edge media servers handle the external touchpoint and create this new interaction. Interactions are also created internally in Genesys while processing, for example, a new email can be created by a Designer application or an agent.
Interactions are queued before they are processed by a Designer application - the size of the queue is controlled by the capacity configured in the system for the queue. Each queue is connected to a single Designer application and feeds the application with new interactions. If a queue is not connected to a Designer application, it will likely accumulate interactions without processing any and will result in a build up. To prevent this from happening, Designer manages queues internally and does not require any actions on your part.
The application runs in a new session and starts processing the interaction. That session can route the interaction to an agent, to another application, or it can decide to terminate the interaction once it considers all processing has been completed. If the interaction is routed to an agent, the agent controls the interaction and the Designer application session that routed the interaction to the agent jumps to its Finalize section upon successful routing. In Finalize, the application performs additional non-interaction related post processing and then the session wraps up. At this point session data becomes available in Designer Analytics. The agent can also decide to terminate the interaction once they consider it has been satisfactorily handled or the agent can put it into a different queue for further processing which will trigger another Designer application connected to this queue. In this case, the second application further processes the interaction in a new session.
If an application does not route the interaction and also does not terminate the interaction, the interaction is put back into the queue it was pulled from. This interaction will be pulled again from the queue in a FIFO (first in, first out) order and processed again by the same application in a new session. This can, obviously, become a large or even an infinite loop with unintended consequences. This scenario must be prevented and the next section discusses this in more detail.
Life cycle of an Interaction
An interaction is created in the Genesys PureEngage ecosystem when an external integration into Genesys triggers some processing. This could be an email sent to a mailbox monitored by the Genesys email solution, or a chat sent from a webpage into the Genesys Chat service or a Facebook post, and so on. Edge media servers handle the external touchpoint and create this new interaction. Interactions are also created internally in Genesys while processing, for example, a new email can be created by a Designer application or an agent.
Interactions are queued before they are processed by a Designer application - the size of the queue is controlled by the capacity configured in the system for the queue. Each queue is connected to a single Designer application and feeds the application with new interactions. If a queue is not connected to a Designer application, it will likely accumulate interactions without processing any and will result in a build up. To prevent this from happening, Designer manages queues internally and does not require any actions on your part.
The application runs in a new session and starts processing the interaction. That session can route the interaction to an agent, to another application, or it can decide to terminate the interaction once it considers all processing has been completed. If the interaction is routed to an agent, the agent controls the interaction and the Designer application session that routed the interaction to the agent jumps to its Finalize section upon successful routing. In Finalize, the application performs additional non-interaction related post processing and then the session wraps up. At this point session data becomes available in Designer Analytics. The agent can also decide to terminate the interaction once they consider it has been satisfactorily handled or the agent can put it into a different queue for further processing which will trigger another Designer application connected to this queue. In this case, the second application further processes the interaction in a new session.
If an application does not route the interaction and also does not terminate the interaction, the interaction is put back into the queue it was pulled from. This interaction will be pulled again from the queue in a FIFO (first in, first out) order and processed again by the same application in a new session. This can, obviously, become a large or even an infinite loop with unintended consequences. This scenario must be prevented and the next section discusses this in more detail.