Overview: Dynamic Scripting workflow module

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

This article explains the function of a Dynamic Scripting module in workflows, as well as how to configure one, in Edify Console.

In this article

Overview

Each Dynamic Scripting module gives you access to creating one script experience, which includes:

  • Crafting the script that queue users read.

  • Building the collection form that the users use to input the customer’s response to the prompt.

  • Configuring the routing logic that Edify uses to display the appropriate script to use next with the customer.

So, you can use one or several connected Dynamic Scripting modules to build the experience that queue users go through in the script tab of an interaction in the Edify app. This is based on the number of decision points in the script.

Common use cases for the Dynamic Scripting module

Below are some common uses cases for using Dynamic Scripting modules:

  • 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.

How it works

The Dynamic Scripting module enables Hammond to populate a script tab on the queue user’s interaction workspace. This tab contains the customized script for the user to work from while on a live interaction with a customer.

Scripts can be as simple as a text field with one option outcome; or, you can create a specific data collection form that triggers specific options. Either configuration ultimately routes the interaction further through the workflow based on the form’s input.

Common use cases for the Dynamic Scripting module

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. From these calls, you have cultivated a list of common issues and thus created a technical support checklist. This checklist branches to various resolutions based on a variety of factors. To create an efficient user-customer engagement for troubleshooting these interactions, you decide to convert this checklist into a scripted experience for the queue users.

This is what that experience looks like. When the customer calls your company, they first reach the inbound workflow experience, which starts with a Time Control module to determine if it’s received during staffed hours. Hammond proceeds through a series of modules like the Say+Intent module to collect the customer’s information and needs. Once Hammond determines that the caller needs technical support, he 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 have curated. Once the interaction is accepted by a user, 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 structure in Workflows 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: 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: 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: 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: 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: 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: The Encrypt toggle allows you to add an additional layer of encryption security to the data being collected.

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

  • Label: The 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: The Value field allows you to define a text or numerical value to equate to the option’s label.

  • Default: 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: 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, Hammond reviews the form information to decide on which script to display next. The next appropriate script is determined based on the routing logic configured in the Options workspace.

Use the Options workspace to create the logic for Edify to use to determine which script 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: 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: The delete button (trash icon) 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: 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: 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: 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: The +Add logic button (located inside the Decision boxes) 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: The +Add option button at the bottom of the Options area 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).