Overview: Dynamic Scripting workflow module (Edify Console)

Edify Console > Workflows > Workflow modules > Overview: Dynamic scripting workflow module (Edify Console)

This article provides an overview of the Dynamic Scripting workflow module in Edify Console.

Overview

In Edify workflows, the Dynamic Scripting module is used to create highly-configurable, branching flows, like when you want to create surveys that a queue user can recite to a customer or put guardrails around steps or flows that are crucial to follow in a specific order. 

With the dynamic scripting module, you can create a chain of pre-prepared questions that the queue user can ask the customer or follow as it relates to the process they need to complete. This module also allows the queue user to save customer responses.

The Dynamic Scripting module is highly configurable; you can use workflow logic to route it to an appropriate destination based on a customer’s response.

You can link multiple Dynamic Scripting modules together to make dynamic surveys based on the customer’s responses.

Once you’ve created your Dynamic Scripting workflow, you can configure a queue to use it for dynamic scripting. Once it’s added to a queue, queue users can access it through the script tab of an interaction. Alternatively, you can add a dynamic scripting module in an embedded workflow for a queue user to run in an interaction.

Below are some common use cases for the Dynamic Scripting module

Use case: Create branching resolutions from dynamic scripting

Here is an example of how you can implement Dynamic Scripting modules into your workflow. 

Your business sells hardware to consumers, and you notice that a large portion of your inbound calls relate to troubleshooting issues. You’ve cultivated a list of common issues from these calls to create a technical support checklist.

To create an efficient user-customer engagement for troubleshooting, you decide to convert this checklist into a scripted experience for queue users.

When the customer calls your company, they reach an inbound workflow experience. A Time Control module determines if the call is received during staffed hours. Then, the workflow proceeds through a series of modules like the Say+Intent module to collect the customer’s information and needs. 

Once the workflow determines that the caller needs technical support, it moves the interaction to the Transfer module and the caller is sent to your technical support queue. You’ve already configured this queue with a Dynamic Scripting workflow based on the checklist you’ve curated. 

Once the interaction is accepted, this workflow is activated and the script tab automatically opens for the user. You configured this auto-open setting to remove the manual step of clicking to open it, thereby making this process more efficient.

Now that the customer is connected with a member of your support team and the script tab is open, the queue user is ready to proceed with executing the script experience.

The experience starts with the queue user reviewing and using the first script, which you created with a Dynamic Scripting module (see below for how to set up). The module includes a script prompt explaining that the customer has a technical support issue. Use this script to diagnose the issue by using this script to speak/type back the troubleshooting question(s) provided in the script. Input the customer’s response into the collection form, and click the continue button to advance to the next, appropriate script. 

So, the queue user starts the experience by reading the script directions. When the user reaches the “SAY” line in the script, which is a troubleshooting question: “Is the device plugged in?”, they speak the question to the customer and wait for the customer’s response. Below the script is a drop-down menu with the options of “Yes” or “No”.  The customer answers “No”, so the queue user selects this option from the menu and clicks Continue. Edify reviews the collected response of “No” and moves to the next, appropriate script. 

The next Dynamic Scripting module includes a script that advises the queue user to ask the customer to plug the device into a power source and report back which, if any, of the device indicator lights are illuminated. The user waits for the customer to execute the request and report back an answer. Depending on the indicator lights reported, the workflow continues to branch out to the next troubleshooting questions. This process continues until the script reaches an End Module. This issue is now resolved.

This workflow is configured so the Dynamic Scripting module asks one question at a time and based on the outcome then follows the applicable option pathway to the next module. 

Visual breakdown

Exterior structure

This is the exterior view of the Dynamic Scripting module. This module shares the same settings as the other modules. 

However, notice that there isn’t an exit port. Similar to the Say+Intent module, the routing possibilities are automatically generated based on the configurations created under the Options tab. 

Reference the Overview: Workflow module article to take a deeper dive into the basic components of a module.

Interior structure

The Dynamic Scripting module has three key areas:

Script

Once a queue user has accepted an interaction in a queue that uses a dynamic script, they are ready to use the script tab to execute the scripted experience. 

Form

Once the queue user reads the scripted text, they wait for the customer’s response and complete the form with the collected data. Use the Form workspace to create the question form that the queue user completes when collecting the customer’s response. You can add one or more input fields in a single form.

Options

After the queue user inputs the customer’s response into the form and submits it, routing logic is used to determine which script to display next. The routing logic is configured in the Options workspace. 

Use the Options workspace to create the logic for Edify to use to determine which step to present next. This is where you define what each value from all the form fields built on the Form workspace means. For example, when the queue user completes the Begin Troubleshooting form and inputs a customer answer of “Yes”, what script should Hammond present next? If the user selects “No” - what happens? In the below example, the module is configured to see “Yes” as a routing option for the form. So, when a queue user completes the form with an answer of “Yes”, Hammond moves down the routing path for “Yes” and onto the next Dynamic Scripting module, which includes the next script for the user to use.

Therefore, here is where you identify which value(s) from the Form workspace populate as Option module routes extending from this Dynamic Scripting  module and also what logic is used for that route.