Overview: Dynamic Scripting workflow module (Console)

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

Overview

The Dynamic Scripting workflow 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.

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

• Standardized customer service: You want all queue users to follow a specific set of steps (or send the customer through a specific set of steps) for every interaction in order to create consistency and standardization for interactions.

• Contact center supports multiple businesses and/or products: Your call center users support multiple businesses or products, so it’s more effective to provide them with a set of scripts to follow for resolving customer issues instead of, or in addition to, training them on each product.

• New hire training: Use when you have new hires who are not familiar with all of your products, troubleshooting steps, etc. when working through a customer interaction. This can be used on an as needed basis or a queue by queue basis.

• Low volume queue: Use when you have a queue that doesn’t receive many interactions, so users aren’t yet proficient in managing the interactions within the queue.

• Change management: Use when you have a queue that receives questions about new features, products, and/or services to support managing the diversity of interactions.

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

• Form

• Options

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. 

• Auto Open Tab (A): The Auto Open Tab toggle, when enabled, alerts Edify to automatically open the script tab on the queue user’s interaction workspace when a workflow reaches a Dynamic Scripting module. When this setting is disabled, the queue user must manually click on the script tab to display it. 

• Scripting field (B): The scripting text field allows you to create a customized, formatted script that queue users can either speak back to the customer on voice interactions or copy and paste back to the customer on messaging interactions . Notice that this script recognizes variable replacement to create a personalized script for the user to use with the customer. This field is also a rich text editor, so it supports adding video, images, hyperlinks, various text formatting options, and embedding code directly into the script.

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.

• Variable (A): The Variable field allows you to define the name in which the data point is stored as in the system database. This variable can be used for variable replacement later in the workflow once the data is collected from the customer by the queue user. This variable and any additional variables created in this area are listed in the Options workspace when defining the decisions to make based on the selection made. 

• Label (B): The Label field is where you create a label, title, or question that’s associated with the Input Type menu. This is the text that appears above the input field that the queue user reads to better fill out the input form. So, in this example, the user reads “Plugged in?” above a drop-down menu to alert the user that this is where they enter the customer’s response regarding the device being plugged in or not.

• Input Type (C): The Input Type menu is where you select the type of form field that you’re building. The type options within this menu include: ‘Dropdown’, ‘Text’, ‘Text Area’, and ‘Radio’.

  • • Dropdown: The Dropdown option creates a menu for the queue user to select the applicable option from when collecting the customer’s response.

    • Text: The Text option populates a text field to either allow the user to input short answers or to display variables collected earlier on in the workflow. This field supports words, numbers, and variables.

    • Text Area: This option populates a text field to either have users to input paragraph answers or to display variables collected earlier on in the workflow

    • Radio: The Radio option builds a list of clickable  buttons for the queue user to choose from when collecting the customer’s response. 

• Encrypt (D): The Encrypt toggle allows you to add an additional layer of encryption security to the data being collected. 

• Delete (E): The delete button allows you to clear the data input into all of the fields in-line with the corresponding delete button. 

• Label (F): The option label field allows you to provide an identifier for the menu options or radio buttons. The label provided here is the label of the option presented to the queue user managing the customer interaction. The label input here corresponds with the decisions configured in the Options area below. 

• Value (G): The option value field allows you to define a text or numerical value to equate to the option’s label. 

• Default (H): The Default toggle, when enabled, allows you to define which option you want to be automatically selected in the form when the queue user is processing the scripted experience in a customer interaction. You can choose to enable only one or none of the Default toggles; you can’t enable more than one at a time. 

• +Add (I): The +Add button allows you to add another row and create another input field. You can currently add an unlimited amount of rows.

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.

• Label (A): The Label field allows you to identify the option that you want to configure one or more decisions for. This label corresponds to the options listed in the Form workspace, explained in the section above. 

• Delete (B): The delete button allows you to clear the in-line data you have configured. There are delete buttons that correspond with clearing an entire option as well as delete buttons that correspond with clearing only a decision configured within a specific option. 

• Variable (C): The Variable menu is made up of the variables configured in the Form workspace, explained in the section above. The menu options here include all variables that you have built for the module and therefore varies from module to module. 

• Operator (D): The Operator menu is where you define how the module processes the data, or makes a decision,  based on the data input by the queue user. The menu options here are: ‘equals (=)’, ‘greater than (>)’, ‘less than (<)’, ‘greater than or equal to (>=)’, ‘less than or equal to (<=)’, and ‘not equal to (!=)’.

• Value (E): The Value menu is made up of the variable’s options configured in the Form workspace, explained in the section above. The menu options here include all variable’s options that you have built for the module and therefore varies from module to module. 

• +Add (F): The +Add logic button allows you to add additional logic action for the selected variable’s option. Clicking this button adds another line item to the specific option which includes another Variable menu, Operator menu, and Value menu. 

• +Add (G): The +Add option button allows you to create another routing option stemming from the Dynamic Scripting module(Option module). Each option creates a new routing branch from this module and includes it’s own decisions, or logic, corresponding with that selected option. Adding another option here creates a new configurable Label and it’s own corresponding, configurable decision(s).