What's Right for your Voice Apps, Coding or Drag & Drop?

Know Your Options

When you’re driving in the car you can opt for any number of routes to get from point A to point B. The most direct path or the scenic route both have their advantages. Regardless of which one you choose, as long as you arrive at your destination it doesn’t matter which course you drive.

The same is true of application development. Some companies have the resources to do things a certain way and others don’t. This isn’t to suggest that one way is better than the other; they’re just different.

In the spirit of education and clarity, we’re going to walk through two different approaches to building a simple voice application using two of our own platforms, Plum DEV and Plum Fuse.

The DEV platform allows users to build applications using VoiceXML, an open standard programming language similar to HTML. Plum Fuse is a rapid application development platform that has an intuitive, visual drag-and-drop graphical user interface (GUI).

Understanding how these technologies work goes a long way toward finding a solution to meet your specific needs, how to leverage a platform as a service (PaaS), and determining what resources are necessary to build an IVR application.

To keep things simple and concise in the following example we’ll look at how to create a basic auto-attendant application. Once the application answers the call the main menu starts with a simple prompt that gives callers four options. These consist of talking to support, sales, or customer service, or to get more information about the company.

Phase 1: Main Menu

The backbone of the application is the main menu. It’s the first thing callers hear after the IVR picks up a call.

DEV

For developers with HTML or XML coding experience, putting together the main menu in VoiceXML is pretty straightforward. First, designate and identify the menu <menu id=“MainMenu”> and how that menu will behave <property name=“bargein” value= “false”/>. This <property> tag indicates that users will be unable to “barge in” or interrupt the prompt. (1)

In other words, if you called and pressed or said “1” before the prompt finished, the application would not recognize your selection. You would have to wait until the prompt finished to make your selection. Changing the value to “true” would enable barge in functionality.

Now you may be wondering how the automatic speech recognition (ASR) works here. Well the <menu> tag takes care of that in this example, automatically incorporating ASR into the menu. There are multiple ways to initiate ASR, but this default method most closely represents how Fuse works.

The second step is to create the options. These are denoted with a <choice> tag. The “Support” choice looks like this: <choice dtmf=“1” next=“support”>Support</choice>. (2) The DTMF component relates to actual key selections on your device. The prompt instructed callers to press 1 or say “support” for support. This line of code assigns the input “1” to the support menu. The “next” function simply directs the application where to go after the number 1 is selected. In this case its to the support submenu.

Because there are four total selections, the above code can be copied and changed to reflect each choice.

Fuse

Building the same menu in Fuse is even easier. When you first open Fuse all you have is a blank workspace and a Start module. To get started, add a Menu module to the workspace from the modules menu. (1)

Enter the text for your main menu prompt in the module’s textbox. Then, simply click the circle node on the bottom of the Start module and the triangle node at the top of the Menu module to connect the two elements. Remember that the connections between modules denote the path a call follows based on caller input.

Our menu provides four options so click the + sign in the module until you have four input rows.(2) You’ll link these to their corresponding components later, but just add them for now, and select the desired number and verbal inputs for each option.

To turn ASR on in Fuse, click on the module settings and select the box next to “Enable Speech Input.” You’ll know that ASR is enabled because a green microphone icon will appear in the upper right-hand corner of the module’s text box.

Phase 2: Error Handling

What if someone says something that doesn’t align with the assigned choices in the menu? It’s a good idea to give callers a few chances in case they press a wrong key or the ASR doesn’t understand them.

DEV

In DEV there are two different tags you can use for error correction. They are <noinput> and <nomatch>. The first, <noinput>, covers the ASR if the caller didn’t say anything or if the caller didn’t press anything. (1) The second, <nomatch>, corrects for erroneous key inputs, or invalid speech inputs. (2) For example, if someone presses or says “6” when it’s not a menu option that’s a “nomatch” error.

Notice at the end of both of these sections of code, before closing the tag there is an additional <reprompt/> command. This tells the application to go back to the main menu prompt and start the process over again.

The default setting in DEV for how many times the application re-prompts callers is three. See the discussion about the <catch> tag below if you want to change this default.

Fuse

First off, it’s helpful to know that you can set default, global error handling messages in the Application Settings menu. But, if you want to have custom error handling for a specific section (or sections) of your application, this is how you’d do it.

To set up custom error handling, go to the Menu module’s settings and select the option to “Show Custom Errors.” This automatically adds “No Input” and “No Match” to the bottom of the module. Click the gray plus button in this section to add as many error options as desired. For this example, we’re using three. (1)

Drag two more Prompt modules onto the workspace. Type in the error message for either no match or no input. Here, we’re using,“Your entry was invalid” and “I’m sorry, I didn’t hear you,” respectively. (2)

Now connect the first two No Input nodes to the no input error message, and do the same for the first two No Match nodes, connecting them to the no match error message.

Phase 3: Sub-Menus

At this point, we know the four options that callers will have, but we need to create their corresponding menus, as well as an error page.

DEV

Looking at the DEV code you can see that there are three different functions that these pages have.

The first block, Support, passes callers through to another menu. (1) Sales and Service both include a prompt to inform the caller about what action is taking place. (2) The application then transfers callers to the phone number entered in the module. The Info block simply includes a prompt before ending the call. (3)

Let’s go back and look at the Support sub-menu. In order for a caller to get through to support they have to first enter their customer support number. Note in the <field> tag that the caller must enter eight digits because the minimum and maximum are both set to eight. (1)

Callers are prompted to enter their customer support number. Nested within the <field> tag are <nomatch> and <noinput> tags with associated counters. (2) Notice the <reprompt/> nested within both of those tags as well.

The <catch> tag is the one here that controls the number of attempts. The event=“noinput nomatch” count=“3” modifier says that once the total number of errors reaches three, to prompt the caller and end the call (the <exit/> tag). (3)

When the application records the entered number it is designated as “getNum” as indicated in the <filled> tag. So once eight digits have been entered, the application uses a prompt to repeat the number back to the caller. The <say-as> tag tells the ASR what it will be saying, in this case numerical digits. (4) It also denotes which specific numbers to say by retrieving the value stored in “getNum”.

After confirming the customer support number, the application transfers the caller to customer support in the same way that transfers worked from the main menu to Sales and Service. (5) So that section can be copied, pasted, and updated with the correct number.

Fuse

In Fuse, you’ll want to create new pages (i.e. workspaces) for each sub-menu. Including an error page, that’s five total. This helps to reduce cluttered workspaces. To create a new page, click the “+” button on the left side of the menu bar in the application editor. Name the page when prompted and repeat this process for the other four pages necessary for the application. Notice that these pages appear at the top of the workspace like web browser tabs.

Now head back to the main application page. Find the Jump to Page module in the call-flow section and add five of these modules to the main workspace. On the first Jump to Page module, choose “Support” from the drop-down menu, which will automatically be populated with the pages you created. Connect the node next to “Support” from the main menu to node on the Jump to Page module. (1) Repeat this process for Sales, Customer Service, and Info. (2)

The last Jump to Page module is for error handling. Select the third no match node and the third no input node and connect them to this module. (3)

That’s it for the main menu workflow.

At this point, your main application should look something like this:

Remember with the DEV example that the Customer Service and Sales sub-menus functioned the same way. Click over to the Customer Service page. Add a Transfer module and then type in the prompt text and the phone number for customer service. (1) Drag an Exit module to the workspace. (2) Link the three modules and voila! Finished. Repeat the same process for Sales.

The Info and Error menus have similar call-flows as well. Click over to the Info page and drag a Prompt module onto the workspace. Type in the prompt message. (1) Drag an Exit module to the workspace. (2) Link the three modules together. Repeat the process for the Error page. Now four of the five sub-menus are finished.

The last sub-menu, the one for support, requires callers to input their customer ID number. So drag a Digits module onto the workspace and connect it to the Start module. (1) Type in the prompt that callers will hear. Go to the module’s settings and enter “8” in the “min” and “max” digits fields to account for number length.

Now, just like we added custom error handling tp the main menu, we’re going to add it here. Follow the same process outlined above. (2, 3) Enter all the appropriate text, values, and linked pages, and connect everything together.

The last piece of the call flow is the verification of the customer support number and transferring the call. Drag a Yes/No module onto the workspace. (4)

Link the Digits module to the Yes/No module. Finally, pull in a Transfer module and link it to the Yes/No module. (5)

Type the pre-transfer prompt text into the Transfer module as well as the correct phone number and the entire application is finished.

Final Thoughts

As you can see, when it comes to designing an IVR both coding and drag-and-drop have their advantages. Both approaches also get the job done.

The big question when choosing between platforms is what type of resources are at your disposal? If you’ve got developer talent at the ready, then the coding with DEV is a great option. Or, if you’ve don’t have developers, but still want professional IVR, then Fuse allows you to achieve that.

The preceding example barely scratches the surface of these platforms’ capabilities. Both platforms are free to try, so give one, or both, a whirl and dive into all the powerful features DEV and Fuse offer. Go ahead, build something great!