Draft:PEC-ROU/Current/Developer/Digital Channels

• 

• Developer

This topic gives you an introduction to the digital channels available in Designer and highlights some best practices when working with these channels.

Related documentation:

• How Routing works

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 Engage 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 phase 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.

Preventing sessions from looping

To prevent sessions from infinite looping, Designer has a number of controls enabled by default in each application.

The AutoStopInteraction system variable:

• If set to true, the interaction is automatically terminated just before the application session wraps up.
• When set to auto, which is the default value, the application decides whether to stop the interaction or not based on the interaction media type. <<TO DO : add channel specific details>>

The ExpirationTime system variable:

This is the maximum time in minutes from the time this interaction was first processed by a Designer application to keep this interaction alive. When an application session wraps up and the AutoStopInteraction variable is set to auto, the application terminates the interaction if that interaction is being processed for longer than the specified ExpirationTime.

We strongly recommend that you ensure your application terminates the interaction if it does not route it to another target (agent or another application). This should apply to most use cases. If your scenario specifically requires that the same interaction be processed again by the same application, you must ensure there are sufficient guard conditions to prevent this infinite looping. These guard conditions can be added by tweaking the system variables described above depending on your expectations.

For instance, if you want to process an interaction with an application for up to 10 minutes and may need multiple attempts by the application to do so, but there is no cap on the number of attempts (each session would be an attempt), set the system variables as follows:

• AutoStopInteraction = auto
• ExpirationTime = 15

Remember that all application changes require the application be published for the changes to take effect. In working with streams other than Dev, you will need to make another build and load the build on to the specific stream.

There may be certain scenarios where the application must process the interaction and perhaps update its userdata or check its status to perform non-interaction related processing like sending an HTTP request to an API with the status. In this case, it is advisable to provide a gap or delay between successive sessions (attempts) that process the interaction. This can be done by parking the interaction into a special parking queue for a specific time. This is done by using a Route Call block in the default General application type and selecting the Parking Queue option. This sends the interaction to a special parking or holding queue in Designer, keeps it there for the specified amount of time (in minutes), and then moves the interaction back to the original queue. The interaction is pulled again from this queue and processed by its connected application, that is, the original application, to make another attempt. Enabling the parking queue functionality may require configuration changes in your instance of Designer. Please contact your Genesys account team to initiate this activity.

Important

Designer manages queues internally and does not require you, as a user of Designer, to manage them separately.

Best Practices

By default, the General application type in Designer works only for the voice channel. Only when the Enable Omni-Channel support for Default applications setting is enabled, the application starts supporting the chat channel in addition to voice.

Interaction Termination

The Life cycle of an Interaction section talks about an interaction's life cycle and how to prevent an interaction from looping in sessions. You must ensure each application handles the interaction by routing it or terminating it. Very few use cases will require repeated processing of interactions by the same application. This case is also discussed in the same section.

User Disconnect Handling

Before version 9.0.111.16, Designer applications would jump to the Finalize phase if a chat user disconnected. The application would finish processing the Finalize phase and then terminate the interaction. A new option is introduced in later versions, to continue processing when the customer disconnects, to provide control over this behavior. If enabled, the application would continue processing normally instead of jumping to the Finalize phase. This setting should be switched on to ensure processing continues uninterrupted. Without this option switched on, interaction related processing could be performed unreliably. For example, routing to an agent could be interrupted when Designer terminates the interaction in response to the user disconnecting. Changing this setting requires publishing the application again.

Sending Chat Transcripts

Chat transcripts should be sent in the Finalize phase instead of the Self service or Assisted Service phase. The Finalize phase is processed even if the other phases are interrupted. Therefore, placing the Send Chat Transcript block in the Finalize phase ensures that the chat transcript is always sent irrespective of any interruptions that may occur.

Provisioning

<<TO DO>>