Welcome to Plum Fuse. This site is designed to provide Fuse users with the information they need to learn what the different components of Plum Fuse are and how they function.
We recommend watching the videos below, first. This will give users a good general overview of what Fuse is and how it works.
|Overview of Plum Fuse|
| Plum Fuse is a unique and innovative IVR development product.|
It's designed to allow users to use a visual development workspace
to build and manage applications for automated self-service.
This video is an introduction to Plum Fuse. Viewers will learn how
Fuse differs from other IVR products on the market and the benefits Fuse delivers.
|Meet Fuse's Modules|
| Plum Fuse's modules are what sets it apart from the competition.|
These are pre-built tools and features that users can quickly and
easily connect to create power IVR applications.
This video describes each module and provides a brief explanation of its intended use.
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.
If you ever need additional help, please check out our support forum.
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.
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.
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:
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.
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).
See the Settings section for more detailed information on this menu.
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.
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.
At this point, the application appears on the list of active deployments. Users have several management options ( ) after deploying an application.
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.
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.
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.
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.
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.
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”.
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:
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.
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.
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 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.
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:
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.
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.
See the Modules page for more information on these modules and how variables function.
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.
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”.
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 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.