tutorial

Tutorial

Plum Fuse is an interactive voice response (IVR) call-flow builder. Fuse employs a visual drag-and-drop interface that enables users to easily layout and connect the basic components of an IVR application. This tutorial will walk you through the tasks of building and deploying your first IVR application. This example demonstrates how Fuse collects and verifies user inputs, as well as how to use call-flow principles like branching logic, variables, and data integration.

Building Your First Application

To create a new application, visit the 'Applications' page and click the button. Enter a name for your application and select the default language. Then, click the button to launch the application editor.

Editor

The call-flow editor is the primary workspace in Plum Fuse. This is where users assemble the components that comprise the call-flow of their IVR application.

The editor toolbar provides users with quick access to several aspects of the Fuse tool.


  • 1. Help: Click this button to initiate a guided tour of the application editor.
  • 2. Version: Hover over the button to display the version you are currently working on. Click the button to display a list of all versions of the application.
  • 3. Pages: For clarity and ease of use, many times it makes sense to create a new page for each component of your voice application call-flow. The page tabs allow you to quickly switch between these different sections. Click on the plus ( ) button to add a page, or click on the gear icon in the upper corner of the page tab to rearrange, rename, or delete a page.
  • 4. Application Name: The name of the application is displayed in the middle of the toolbar. To update or change the name of an application click on the application name to convert it to an editable text field.
  • 5. Modules: All of the available Fuse modules are available in this menu. The menu has a built-in search function and can be pinned to the workspace desktop in each page for quicker access. To add a module to the workspace simply click on it or drag it from the Modules menu onto the workspace.
  • 6. Editor: This button opens the workspace/pages for a given application.
  • 7. Settings: Use this page to access the application settings menu. Here users can change global default behaviors for an application such as timeouts and error handling.
  • 8. Audio Manager: Use this page to access the audio manager. Here users can upload audio files for any static prompts in an application.
  • 9. Save: Click the button to save a minor revision of an application, or click on the arrow for a drop-down menu with advanced save options, such as revision type (major/minor), name, and number.


Call-flow

Launching the application editor takes users to the call-flow tab by default. The gray hashed area below the editor toolbar is the primary workspace for a given tab. Users build their call-flow in this area, adding modules and connecting them together with paths.

Modules contain a standard set of components:


  • 1. Receptor: The triangle at the top of a module is the receptor. To connect two modules, click on the transmitter of one module and drag that link to the receptor of another module. Users can also click on the receptor and drag the module around the workspace.
  • 2. Icon: The icon indicates the module type. An icon with an inverted gray background indicates that the module is in 'private' mode. Users can click on the icon and drag the module around the workspace.
  • 3. Name: Click on the title of the module to change it. Note: for greater clarity in reporting it is helpful to change the name of the module to something that describes what the module does within the application.
  • 4. Options: Modules that have additional user options display the options menu where users can access and adjust those settings.
  • 5. Delete: Removes the module from the workspace.
  • 6. Body: This is the where users customize the module behavior.
  • 7. Transmitter: The circle at the bottom of a module is the transmitter. Click on the transmitter and drag the cursor across the screen to display a path line. Drag this path line to the receptor of another module on the same page to connect them. To remove a link between two modules, click on the transmitter again. For modules with multiple transmitters located on the side of the module (instead of the bottom), double-click on any transmitter to switch it to the opposite side.

Start Building An Application


All workspaces contain a 'Start' ( ) module when created. Whether an application accepts inbound or makes outbound calls, the 'Start' ( ) module on the first page remains the entry point to the call-flow. Click anywhere on the 'Start' ( ) module and drag it to change its location in the workspace.

  • To begin building an application, add a Prompt ( ) module and connect it to the 'Start' ( ) module. To add a module, click on the button in the toolbar to open the modules toolbox. Next, expand the 'Call-flow' section and locate the 'Prompt' ( ) module. To add the module to the workspace either click on it or click and drag the module to place it in a specific location in your workspace.
  • Next, drag the 'Start' ( ) and 'Prompt' ( ) modules to the desired place in the workspace.
  • Then click and drag the transmitter from the 'Start' ( ) module and drop it on the 'Prompt' ( ) module's receptor. This creates a path, connecting the two modules.
  • Change the name of the 'Prompt' ( ) module in the title bar and then type “Hello, World!” into the main text box.
  • Next, locate the 'Exit' ( ) module from the list of modules and add it to the workspace.
  • Drag the transmitter from the 'Prompt' ( ) module to the receiver of the ( ) module to connect them and complete the call-flow.
  • At this point, go ahead and save the application by clicking the button in the main editor toolbar. This creates a new revision of your application. Users can verify this by looking at the 'Revisions' ( ) menu in the main toolbar. Click on the drop-down arrow on the button for more granular control over how Fuse saves application revisions. The default save behvior can be set to either a major or a minor revision and to add the current date to the title.

Settings

After saving the application, click on the 'Settings' ( ) icon in the main editor toolbar. The Application Settings tab provides a range of options that enable users to change the global default settings for the modules in their application(s).

  • Language Settings: In this section, users can set or change the default language for their application. This is also where users select the Text-to-Speech (TTS) engine that will power prompts that use dynamic variables or don't have pre-recorded audio. Select the desired TTS voice from the drop-down menu. Note: Not all TTS languages will have multiple voice options.
  • User Input Settings: This section allows users to change their application's behavior when collecting end-user input. For example, it is possible to create custom messages when an end-user fails to provide a response or enters an invalid response (i.e. a 'no match'). Users can set the timeout duration for end-user actions as well (e.g. DTMF, Speech). These values are in seconds and can range from 1 to XX. The default setting for initial input timeout is 5 seconds, and for final DTMF and speech input the default is 3 seconds. Users can set the number of times end-users will be re-prompted when an error occurs and can set a custom audio message for each re-prompt if desired. Enter the text to be spoken in the field(s) of the 'Say' column. If an end-user exhausts all of their input attempts, you can choose what action your application will take next. The available options are–Keep Reprompting, Hang Up, Jump To, and Transfer To. If Jump To or Transfer To are selected, a new drop-down menu appears immediately to the right where users can set a default destination. The 'Shortcuts' option works in the same way as the Jump To or Transfer To settings.
  • Connection Settings: This section lets users adjust webservice and call transfer behaviors. This includes timeouts (in seconds, 1 to XXX) and custom audio.
  • Post-Call Webservice: This section lets users ensure that when a call is complete, that the Fuse application always sends specific data from the application to a webservice. Note: Users must create their own webservice to use this functionality.

See the Settings section for more detailed information on this menu.


Audio Manager

Clicking over to the Audio Manager page and one of the first things to notice is that the editor toolbar is slightly different. Here users have a separate tab for each language used in their application. To add a language click the ( ) icon.

Note that this menu provides a list of all the audio prompts in the application. This is replicated for each active language. The list contains default prompts that users did not type. For example, the error handling prompts from the User Input Settings menu (“I'm sorry, I didn't get that,” and “I'm sorry I still didn't get that”) are included here. To change the text for those prompts, go to the Settings page, update the text, and Save your work.

There are also some built-in prompts that Fuse creates automatically. The dashboard ( ) icon in the left 'Type' column designates built-in prompts. Users can edit built-in prompts directly on the Audio Manager page by clicking on the text in the 'Phrase' column to make the text editable. Note: Only built-in prompts can be directly edited this way in the Audio Manager menu.

By default, all the prompts in the list will be read using machine generated text-to-speech (TTS). Users can customize their TTS on the Settings page. Users also have the option of uploading audio files that will play instead of TTS. To do so, click on the upload ( ) icon.

Plum recommends uploading audio files for all static prompts because well-recorded audio is easier for end-users to understand, which results in fewer input errors, quicker calls, and better customer experience. Plum Fuse accepts most common audio files formats (see the audio manager for more details).

To test out this functionality, download this audio sample to your computer and upload it for the “Hello, World!” prompt. (link to WAV file) After successfully uploading the file, the “Hello, World!” prompt displays new action ( ) icons. Users now have the option to upload a replacement file, as well as Play ( ), Download ( ), or Delete ( ) the current audio file. Click to finalize any uploaded prompts.

See the Audio Manager section for more detailed information on this menu.

Deployment

Deploying An Application

After designing a call-flow, adjusting settings, and uploading audio prompts, the application is ready to be deployed to a phone number. First, click on the Deployments link at the top of the screen. Next, click on the yellow button. This brings up a form that provides a drop-down menu with all of a user's applications in it. Select the application to be deployed. Next, select the version of the application to deploy. The default setting is the most recent revision. Finally, select the phone number(s) to deploy the application to from the provided 'Deploy to' list. Note: all Fuse accounts receive one test phone number by default when they are setup.

Managing Deployments

At this point, the application appears on the list of active deployments. Users have several management options ( ) after deploying an application.

  • Edit ( ) : This allows users to edit the deployment settings. Use this option to pick a different application revision or to update the phone number(s) the application is deployed too. This is helpful if more phone numbers have been added to the user account since the app was initially deployed.
  • Outbound Queue ( ) : Use this to view the outbound queue for the deployed application.
  • Delete ( ) : Use this option to completely delete the application deployment.

It is common to have multiple deployments for the same application. Typically one deployment is for a specific production revision that is deployed to your production phone number. Staging a new revision for QA testing often warrants its own deployment. Finally, a deployment for active development enables users to test the latest application revisions.

Testing

For initial application development, Plum recommends saving a test deployment to the 'latest' revision. This ensures that the most recent version of the application always runs when testers call the test phone numbers. There is no need to edit the deployment settings after each application revision if 'latest' is selected in the deployment form.

After deploying your application, try calling the phone number associated with it. Users should hear a prompt that says “Hello, World!” and then disconnects.

See the Deployments section for more detailed information.

Logs

Click on the Logs link at the top of the page to access all available logs for a user's application(s). Fuse automatically generates two different documents for calls to or from an application: detailed logs and call detail records. By default, Fuse retains these documents for 5 days and 1 year, respectively.

Use the detailed logs to discover the precise events that occurred on an individual call. These include end-user input, prompts, branching logic, and debugging webservice integrations.

There should be a log file for the recent test call made to the basic application. Click on the item in the list on the 'Logs' page. This brings up a short log detailing when the call took place. Whenever a caller encounters a prompt in their call the log displays the text of that prompt along with a link to listen to the audio file the caller heard.

Detailed logs and call detail records are helpful when building complex applications because they allow users to easily trace the call-flow and to debug webservice integrations. Fuse lets users download individual call logs and export call detail records for a specific time frame.

Consult the Logs section for more details.

Building A Complex Application

Having covered the basics of Fuse, now it's time to focus on more complex applications. This means, for example, an application that collects caller account data, queries a webservice for authentication, presents the caller with a menu of options, and provides the caller with details about their account.

Create a new application in the manner detailed above. In the new application workspace, add a Prompt ( ) module, name the module, type a welcome message, and connect the 'Start' ( ) module to the new welcome prompt.


Collecting Caller Input

Caller input refers to either Speech or Touch-Tone (DTMF) input provided by the caller. Only the modules listed in the Input section of the Modules menu actively listen for caller input.

Most input modules allow users to control the type of caller input to be collected. However, not all types of input are compatible with DTMF input. These include the modules Name ( ), Address ( ), and Record ( ).

Conversely, the Language ( ) module, which allows callers to switch to a different language, is DTMF only because it is not possible to recognize speech input in multiple languages at the same time.

Continuing with the sample complex application, it is necessary to collect the caller's account ID. To facilitate this need, add a Digits ( ) input module to the workspace and connect it to the welcome prompt. Because this module collects the caller's account ID, change the title to “accountID” and then type prompt text that asks the caller to enter their account ID.


Variables

It is important to understand that modules automatically create variables in Fuse based on the name of the module. In the screenshot above, the module asks the caller to provide their account ID and Fuse stores the resulting input in a variable named “accountID”.


Options

Each Fuse module has a unique set of options that controls how that module behaves. To customize module behavior, click on the gear ( ) icon to open the options menu for that module.

Returning to the sample complex application, the Digits ( ) input module has the following editable options:


  1. Barge-In: Allows the caller interrupt the prompt with input, advancing the call-flow before the prompt finishes. Note: When barge-in is enabled the top line of the text box changes from a solid line to a dashed line.
  2. Enabled Speech Input: By default, this module only allows DTMF tones. Toggling this option enable speech input.
  3. Min / Max Digits: This determines the rules for acceptable input length. For example, if account numbers are 7 digits long, setting both the Min and Max to 7 forces users to enter 7 digits. Any input that contains additional or fewer digits will trigger a 'No Match' error.
  4. Private: This setting controls whether Fuse logs caller interactions with this module. By default, logging is turned on.
  5. Show Custom Errors: This allows users to provide custom No Match/No Input paths for the module. If this option is disabled, then the application uses the default No Match/No Input rules defined on the Settings tab for the application.

Try adjusting each of these settings. Notice that each change causes a small visible change to the module. This is done so users can quickly identify which options are enabled without opening the options menu. For the current sample application, leave all of the module options on their default settings, i.e. barge-in enabled and all other settings disabled.


Error Handling

Input modules have the ability to trigger No Match and No Input errors based on the caller's behavior.

By default, input modules utilize the global settings which play a generic prompt (e.g., “I'm sorry I didn't get that”) and then repeats the current module. If the caller produces three errors, in any combination of No Match or No Input, Fuse's default setting is to then disconnect the call.

To override these behaviors, enable the 'Show Custom Errors' option. This adds two new transmitters at the bottom of the module as well as icons that allow users to add or remove additional No Match/No Input transmitters.

For example, the default global settings produce the following behavior for all input modules.

Variables & Branching

When adding a module to the workspace, users will notice that the default title of the module is “varX”, where X is a number. The module title functions as a variable within Fuse. This occurs automatically and Fuse stores the results from that module, under that variable name, for later use.

Users can create and define new variables using the Set Variables ( ) and Evaluate JS ( ) modules, too.

Users can add any variable to any field that has a button. This functionality is available in individual modules as well as global application settings.

All prompt fields have a button in the bottom right corner. This allows users to insert dynamic variable values and mix those with static prompt text.

Modules and fields that require data value(s) also have a button. This is most evident when branching based on a value or when passing data to a webservice or application.

Fuse automatically globally scopes all variables within an application and variables are accessible from any page. Jumping to a new application creates a new scope with a new set of variables.


WYSIWYG Prompts

When creating prompts in a Fuse module, the text entered into a text box is presented to end-users exactly as written, so what users see if what they get. Fuse allows users to combine static text with dynamic values by inserting variables into the prompt field using the button.

To add a variable, place the cursor at the appropriate place in the text box and click the button. This generates a new window that allows users to define a variable name. Some modules allow users to define specific variable types as well. Available variable types include:

  • Acronym
  • Address
  • Currency
  • Date
  • Time
Use Case

Verifying end-user input presents a common use case for mixing static prompts with dynamic variables. One way to accomplish this is to use the Yes/No ( ) module to add a variable to the confirmation prompt. Assuming that the end-user's account ID was collected earlier in the call-flow and is already an available variable, the 'Yes/No' ( ) module allows end-users to verify that information. If there is an error, the 'Yes/No' ( ) module can then re-route the end-user to the correct module to re-enter the correct information.


Branching

In Fuse, branching, also called jumping, refers to the routing options a module provides. Oftentimes, an end-user's input influences their path through a call-flow, and Fuse allows users to branch, or re-direct, a call based on a dynamic value. Fuse provides users with multiple ways to create branches within an application.

  • Counter ( ): This module counts how many times an end-user loops through a given section of a call-flow and automatically increases its counter on each loop. Users can set rules for the call-flow based on the current value of the counter.
  • Compare Variable ( ): This module allows users to reference a dynamic value and perform a comparison on it. Users can then re-route end-users to different areas within the application depending on whether that comparison is valid or invalid. For example, it is possible to authenticate an end-user with a REST service and then to route them through the application based on their current account status.

  • Goto Page ( ) : This module allows users to send callers to a new page within the application. Not only can users choose the specific page, they can also select a specific module within that page as the desired landing place. Fuse maintains the application's current application variable scope when making this type of jump.
    • This makes it easier for users to manage their Fuse apps because it is easy to break a call-flow into its component parts, place each section on its own page, and then connect the pages using modules. This approach is also useful if an application uses a specific section in multiple places within a call-flow; users can jump to that sections without the need to re-create it in multiple pages.
  • Goto App ( ) : This module allows users to send callers to a different Fuse application. This is useful for collaborative development where one user owns a small subset of the application's functionality. Jumping to a new application creates a new variable scope, but users can pass variables from the original application into the sub-application, and vice versa. When the new application finishes executing, Fuse assigns the variables from that scope to Goto App module in the original application. These variables are stored as a sub-variable of that module.
  • Menu ( ) : The 'Menu' ( ) module allows users to create a menu of options that branch the call-flow based on the option an end-user selects. The 'Menu' ( ) module automatically creates a dynamic list of prompts that asks end-users to select one of the menu options.
  • Yes/No ( ) : The 'Yes/No' ( ) module restricts end-user inputs to a language specific version of “yes” and “no”.

See the Modules page for more information on these modules and how variables function.

Data Integration

Fuse provides users with several, powerful data integration options. As detailed above, the Goto App ( ) module sends and receives values from other Fuse applications. Using the SOAP ( ) and REST ( ) modules users can access virtually any web service.

REST: The REST ( ) module allows users to specify a dynamic URL that can accept variables in order to access RESTful URLs that require dynamic value(s) in order to reach a specific resource(s). The module also allows users to specify custom HTTP headers using a combination of static text and dynamic variable values. The REST ( ) module also allows users to use any variable value when passing in POST values.

For example, users can use the REST ( ) module to update an account using a REST webservice where an account ID is required in the URL, and POST values are required to update that value.

SOAP:The SOAP ( ) module allows users to specify the WSDL and to access that WSDL's list of methods. After selecting a method, users can use any combination of static text and dynamic variable values to assign the values to be sent to the webservice.


Accessing Return Data

When performing data integration, the values returned to the Fuse application can be accessed as a complex object using Javascript dot notation.

For Goto App ( ), all the variables in the sub-application scope can be accessed as sub-variable of the variable defined by the Goto App ( ) module. For example, assume a Goto App ( ) module named “app_result” runs an application that collects an 'accountID' variable. Users can access the 'accountID' as “app_result.accountID”.

For REST and SOAP services, the value returned by the webservice determines the return structure. For example, assume a REST ( ) module named “rest_result” calls a JSON REST service and returns a complex structure like: {“id”:1234,“name”:“John Doe”,“status”:{“overdue”:false,“balance”:1234.56}. Users can access these values as “result_result.id”, “rest_result.name”, “rest_result.status.overdue”, and “rest_result.status.balance”. This provides users with easy, direct access to these Javascript variables.


Debugging

Sometimes it may not be obvious how the SOAP ( ) and REST ( ) modules will parse and present data. One way to quickly determine this is to call the application and to use either the SOAP or REST modules.

This generates a call log that users can then consult in order to view the full request and its response data. The call log also details the full Javascript object that Fuse created based on the response data.

This lets users see exactly how to access the resulting data structure. It also provides insight as to how to debug any request or response parsing issues in the module.

tutorial.txt · Last modified: 2017/08/22 13:37 by admin