Application phases

From Genesys Documentation
Revision as of 19:51, July 21, 2020 by Bmarshall (talk | contribs) (Published)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This topic is part of the manual Designer User's Guide for version Current of Designer.

Application flows are comprised of sections of common blocks, known as application phases. Learn about the role each phase plays within the Designer application flow.

Related documentation:

Each application flow in Designer contains four phases:

Des phases.png

You can learn more about each phase in the sections below.

Initialize

This phase initializes application-level user variables and parameters to use when the application executes. The application initializes during this phase.

By default, the following actions take place:

  • Initialize and set up user variables.
  • Load application run-time parameters from external sources.
  • Process interaction properties (for example, ANI and DNIS) and application run-time parameters. System variables or properties may be initialized internally.
  • If configured, additional processing that was set up by the user.

Self Service

The Self Service phase is the IVR portion of the interaction. This phase hosts blocks that provide automated interaction with the customer via speech, chat, and/or DTMF. It attempts to provide automated service and contain the interaction within an IVR, so there is no need to route the interaction to an agent.

If routing is necessary, this phase collects necessary data from the user through various questions and menus, and then determines how to route the interaction in the next phase, Assisted Service.
Tip
To enable voice call recording for the Self Service phase, set the EnableSSRecording variable to true in the System Variables section.
The following are typical actions that take place during the Self Service phase:
  • Play Messages. These may be pre-recorded audio files or dynamic text spoken using TTS.
  • Check business hours and customize logic based on the outcome (for example, take this action if we are closed).
  • Collect user input.
  • Present choices to customers using menus.
  • Navigate customers appropriately, based on their responses (segmentation and branches).
  • Call external RESTful APIs and fetch data into user variables.
  • Update user variables and write ECMAScript expressions.
  • Set up and process global commands and hot words.

The Self Service phase updates user variables with collected or calculated data. This data is later used by other blocks in the Self Service or Assisted Service phase.

Interaction processing might complete during the Self Service phase. In this scenario, the application control skips the Assisted Service phase and proceeds to the Finalize phase. For example, if the business hours check determines that the contact center is closed, the corresponding announcement is played to the caller and the call is terminated.

Assisted Service

This phase hosts blocks that route the interaction to a live agent, if necessary.

During the Assisted Service phase, the application attempts to route interactions to agents. Routing is performed based on data collected in previous phases. For example, target skills are taken from user variables.

The following are typical actions for this phase:

  • Attempt to route the call while playing music or prompts.
  • Call external RESTful APIs.
  • Update user variables.

There may be multiple Route Call blocks in sequence. Each Route Call block might try to route the interaction to different targets with different timeouts. For example, it might expand a target by geographical location.

Each Route Call block has a timeout, after which the next Route Call block in sequence is executed. If any of the blocks successfully routes a call, the Assisted Service phase is complete and processing continues to the Finalize phase.

Finalize

This phase provides post-processing and interaction termination after the customer has been serviced.

When interaction processing is finished, the application goes to the Finalize phase to perform post-processing for various scenarios that are based on how the interaction was completed.

The following are examples of typical scenarios:

  • Interaction was abandoned by the customer (while in either the Self Service or Assisted Service phase).
  • Interaction was completed in Self Service phase.
  • Interaction was routed to an agent in the Assisted Service phase.
  • Interaction was delivered to voicemail in the Assisted Service phase.
  • User opted to leave a queue and schedule a callback.

You can also use the Finalize phase to submit application data to an external system for reporting metrics, or to select a disposition code for post-processing.

Disposition codes

When you click on the Finalize block in the application flow, each of the tabs (General, Error, Self Service, Assisted Service, and Callback) has a list of disposition codes that you can enable.

When you select a disposition, a block for it is created below the main Finalize block. You can then drag other valid blocks (such as an HTTP REST block) below the disposition block to further customize the handling for that disposition.

Here's an example:Des finalize disposition example.gif
Tip
Setting up handlers for the Finalize phase is optional. You might not need to do anything special for these cases.
This list contains additional information about some of the common disposition codes that can be enabled in the Finalize phase:

All

When an application enters the Finalize phase, it has only one disposition code, so only one disposition block is executed. However, the All disposition code is unique in that it is always executed, in addition to (and after) any disposition block related to the actual disposition code of the application. This is the only case where more than one disposition block is executed.

Typically, you would select the All disposition code when you want to execute some post-processing logic, no matter what the actual application disposition code is. This is more efficient than duplicating the same logic in every possible disposition block.

default

This code is used when no other disposition code is applicable. For example, it could indicate that a call was not routed, not terminated (by any party), and was likely still active when the session and/or application completed.

System Error

There was an unexpected error in the application (such as a script validation error).

Application Timeout

The application got stuck in a loop and reached the timeout limit.

Terminated (Terminate Call)

The application reached a Terminate Call block.

Terminated (Business Hours)

The call came in outside of regular business hours, as specified in the Business Hours block.

Terminated (Special Days)

The call came in on a special day, as specified in the Special Day block.

Terminated (Emergency)

The emergency flag was set, as specified in the Emergency block.

Terminated (Menu Option)

The caller chose a menu option to exit or end the call.

Abandoned in Self Service

The caller hung up before completing the Self Service phase of the application.

Abandoned in Queue

The caller completed the Self Service phase, but hung up while waiting to speak with an agent.

Completed in Self Service

The caller successfully completed their call in the Self Service phase — the application did not need to go to Assisted Service and went directly to Finalize. If the call ended in Self Service due to some other condition or event (such as the call being received outside of business hours or the customer hanging up), then the appropriate disposition code for that condition or event is used (Abandoned in Self Service, Terminated, and so on).

Routed to Agent

The interaction was successfully delivered to an agent.

Routed to DN

The call was successfully delivered to a direct number.

Comments or questions about this documentation? Contact us for support!