DES/Current/Designer/ApplicationPhases - Revision history

Brian.Marshall.IX: Published

2022-01-05T19:39:40Z

Published

Ed.jamer@genesys.com: Ed.jamer@genesys.com moved page PEC-ROU/Current/Designer/ApplicationPhases to DES/Current/Designer/ApplicationPhases: Text replacement - "PEC-ROU/Current/Designer/" to "DES/Current/Designer/"

2021-04-21T13:57:43Z

Ed.jamer@genesys.com moved page PEC-ROU/Current/Designer/ApplicationPhases to DES/Current/Designer/ApplicationPhases: Text replacement - "PEC-ROU/Current/Designer/" to "DES/Current/Designer/"

Brian.marshall@genesys.com: Published

2020-10-23T14:18:43Z

Published

Brian.marshall@genesys.com: Published

2020-10-23T13:07:50Z

Published

Brian.marshall@genesys.com: Published

2020-10-20T19:59:51Z

Published

Brian.marshall@genesys.com: Published

2020-10-20T19:50:27Z

Published

Show changes

WikiSysop: Text replacement - "\|Platform=([^\|])GenesysEngage-onpremises([\|])" to "|Platform=$1GenesysEngage-cloud$2"

2020-07-25T02:32:51Z

Text replacement - "\|Platform=([^\|]*)GenesysEngage-onpremises([\|]*)" to "|Platform=$1GenesysEngage-cloud$2"

Bmarshall: Published

2020-07-21T19:51:10Z

Published

New page

{{Article
|Standalone=No
|DisplayName=Application phases
|TocName=Application phases
|Context=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.
|ComingSoon=No
|Platform=GenesysEngage-onpremises
|Role=Administrator
|Application=Designer
|Prereq=
|Section={{Section
|sectionHeading=
|anchor=
|alignment=Vertical
|Media=
|image=
|structuredtext=Each application flow in Designer contains four phases:

[[File:des_phases.png]]

You can learn more about each phase in the sections below.<br />
|structuredtextwide=
|FAQHeading=
|Status=No
}}{{Section
|sectionHeading=Initialize
|anchor=initialize
|alignment=Vertical
|Media=
|image=
|structuredtext=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.
|structuredtextwide=
|FAQHeading=
|Status=No
}}{{Section
|sectionHeading=Self Service
|anchor=selfservice
|alignment=Vertical
|Media=
|image=
|structuredtext=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'''.{{NoteFormat|To enable voice call recording for the Self Service phase, set the '''EnableSSRecording''' variable to '''true''' in the '''System Variables''' section.|2}}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.
|structuredtextwide=
|FAQHeading=
|Status=No
}}{{Section
|sectionHeading=Assisted Service
|anchor=assistedservice
|alignment=Vertical
|Media=
|image=
|structuredtext=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.
|structuredtextwide=
|FAQHeading=
|Status=No
}}{{Section
|sectionHeading=Finalize
|anchor=finalize
|alignment=Vertical
|Media=
|image=
|structuredtext=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.
{{AnchorDiv|dispositions}}
===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:[[File:des_finalize_disposition_example.gif]]{{NoteFormat|Setting up handlers for the '''Finalize''' phase is optional. You might not need to do anything special for these cases.|2}}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.
|structuredtextwide=
|FAQHeading=
|Status=No
}}
}}

@@ Line 72: / Line 72: @@
 |anchor=finalize
 |alignment=Vertical
-|structuredtext=This phase provides post-processing and interaction termination after the customer has been serviced.
+|structuredtext=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:
@@ Line 84: / Line 82: @@
 *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 {{Link-SomewhereInThisVersion|manual=Designer|topic=ApplicationPhases|anchor=dispositions}} for post-processing.
+You can also use the '''Finalize''' phase to submit application data to an external system for reporting metrics, or to select a {{Link-SomewhereInThisVersion|manual=Designer|topic=ApplicationPhases|anchor=dispositions}} for post-processing. When you click on the '''Finalize''' block in the application flow, each of the tabs has a list of {{Link-SomewhereInThisVersion|manual=Designer|topic=ApplicationPhases|anchor=dispositions|display text=dispositions}} that you can select. 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 {{Link-SomewhereInThisVersion|manual=Designer|topic=HTTPREST|display text=HTTP REST}} block) below the disposition block to further customize the handling for that disposition.
 Here's an example:
@@ Line 97: / Line 91: @@
 |Status=No
 }}{{Section
-|sectionHeading=Disposition Codes
+|sectionHeading=Dispositions
 |anchor=dispositions
 |alignment=Vertical
-|structuredtext=This section contains additional information about the disposition codes that be enabled in the '''Finalize''' phase.
+|structuredtext=This section describes the dispositions that can be selected in the {{Link-SomewhereInThisVersion|manual=Designer|topic=ApplicationPhases|anchor=finalize|display text=Finalize}} phase.
 ===General===
@@ Line 112: / Line 106: @@
 {{!}}Default
 {{!}}This code is used when no other disposition code is applicable. For example, it could indicate that an interaction was not routed, not terminated (by any party), and was likely still active when the session and/or application completed.
 {{!}}-
 {{!}}Terminated (Terminate Call)
@@ Line 121: / Line 118: @@
 {{!}}Terminated (Special Days)
 {{!}}The interaction arrived on a special day, as specified in the {{Link-SomewhereInThisVersion|manual=Designer|topic=SpecialDay}}.
 {{!}}-
 {{!}}Default Routed

@@ Line 114: / Line 114: @@
 {{!}}-
 {{!}}Terminated (Terminate Call)
-{{!}}The application reached a Terminate Call block.
+{{!}}The application reached a {{Link-SomewhereInThisVersion|manual=Designer|topic=TerminateCall}}.
 {{!}}-
 {{!}}Terminated (Business Hours)
-{{!}}The interaction arrived outside of regular business hours, as specified in the Business Hours block.
+{{!}}The interaction arrived outside of regular business hours, as specified in the {{Link-SomewhereInThisVersion|manual=Designer|topic=BusinessHrs}}.
 {{!}}-
 {{!}}Terminated (Special Days)
-{{!}}The interaction arrived on a special day, as specified in the Special Day block.
+{{!}}The interaction arrived on a special day, as specified in the {{Link-SomewhereInThisVersion|manual=Designer|topic=SpecialDay}}.
 {{!}}-
 {{!}}Default Routed
 {{!}}The interaction was delivered to the default routing destination.
 {{!}}-
 {{!}}Interaction Less
@@ Line 148: / Line 148: @@
 {{!}}-
 {{!}}Terminated (Emergency)
-{{!}}The emergency flag was set, as specified in the Emergency block.
+{{!}}The emergency flag was set, as specified in the {{Link-SomewhereInThisVersion|manual=Designer|topic=Emergency}}.
 {{!}}-
 {{!}}Terminated (Menu Option)
@@ Line 180: / Line 180: @@
 {{!}}}
 ===Callback===
-The following final dispositions can be set by the '''Callback V2''' block. However, this disposition value can be overwritten by any subsequent block that the Designer application enters.
+The following final dispositions can be set by the {{Link-SomewhereInThisVersion|manual=Designer|topic=CallbackV2}} block. However, this disposition value can be overwritten by any subsequent block that the Designer application enters.
 {{{!}} class="sortable"
 !'''Disposition'''

@@ Line 121: / Line 121: @@
 {{!}}Terminated (Special Days)
 {{!}}The interaction arrived on a special day, as specified in the Special Day block.
-<!--{{!}}-
+{{!}}-
 {{!}}Default Routed
-{{!}}The interaction was default routed.
+{{!}}The interaction was delivered to the default routing destination.
 {{!}}-
 {{!}}Interaction Less
-{{!}}-->
+{{!}}Used when a consult interaction is merged with a parent interaction that the application session is not able to take ownership of. Without an interaction to associate with the session, the application applies this disposition code and proceeds to the '''Finalize''' phase.
 {{!}}}
 ===Error===
@@ Line 165: / Line 165: @@
 {{!}}-
 {{!}}Routed to DN
-{{!}}The interaction was successfully delivered to a direct number.
+{{!}}The interaction was successfully delivered to a Direct Number.
-<!--{{!}}-
+{{!}}-
 {{!}}Routing Incomplete
-{{!}}
+{{!}}The interaction was not delivered to the target destination.
 {{!}}-
 {{!}}Routed to Voicemail
-{{!}}
+{{!}}The interaction was delivered to voicemail.
 {{!}}-
 {{!}}Routed to Queue
-{{!}}
+{{!}}The interaction was delivered to a virtual queue.
 {{!}}-
 {{!}}Routed to Parking Queue
-{{!}}-->
+{{!}}The interaction was sent to a "parking" queue to wait until the business is open.
 {{!}}}
 ===Callback===

@@ Line 121: / Line 121: @@
 {{!}}Terminated (Special Days)
 {{!}}The interaction arrived on a special day, as specified in the Special Day block.
-{{!}}-
+<!--{{!}}-
 {{!}}Default Routed
-{{!}}
+{{!}}The interaction was default routed.
 {{!}}-
 {{!}}Interaction Less
-{{!}}
+{{!}}-->
 {{!}}}
 ===Error===
@@ Line 166: / Line 166: @@
 {{!}}Routed to DN
 {{!}}The interaction was successfully delivered to a direct number.
-{{!}}-
+<!--{{!}}-
 {{!}}Routing Incomplete
 {{!}}
@@ Line 177: / Line 177: @@
 {{!}}-
 {{!}}Routed to Parking Queue
-{{!}}
+{{!}}-->
 {{!}}}
 ===Callback===

← Older revision	Revision as of 13:57, April 21, 2021
(No difference)

@@ Line 5: / Line 5: @@
 |Context=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.
 |ComingSoon=No
-|Platform=GenesysEngage-onpremises
+|Platform=GenesysEngage-cloud
 |Role=Administrator
 |Application=Designer

DES/Current/Designer/ApplicationPhases - Revision history

Brian.Marshall.IX: Published

Ed.jamer@genesys.com: Ed.jamer@genesys.com moved page PEC-ROU/Current/Designer/ApplicationPhases to DES/Current/Designer/ApplicationPhases: Text replacement - "PEC-ROU/Current/Designer/" to "DES/Current/Designer/"

Brian.marshall@genesys.com: Published

Brian.marshall@genesys.com: Published

Brian.marshall@genesys.com: Published

Brian.marshall@genesys.com: Published

WikiSysop: Text replacement - "\|Platform=([^\|]*)GenesysEngage-onpremises([\|]*)" to "|Platform=$1GenesysEngage-cloud$2"

Bmarshall: Published

WikiSysop: Text replacement - "\|Platform=([^\|])GenesysEngage-onpremises([\|])" to "|Platform=$1GenesysEngage-cloud$2"