VoiceXML Developer Series: A Tour Through VoiceXML, Part IX
In all of the examples thus far, we have collected input but stopped short of submitting the form fields to a back end script. In this edition of the VoiceXML Developer, we will complete our pizza ordering application by accepting the order, logging the transaction in an Access database, and playing an order confirmation for the user. We will also utilize many of the techniques that we have learned over the course of this tutorial to create a high quality voice application.
It's time to put all of the skills you've learned to use. We are going to start by designing a dialog flow. Then we will develop an application architecture and data model based upon the dialog flow. From the dialog flow, we will develop our VoiceXML forms and add the back-end scripting capability that will allow the system to recognize and create customer records as well as add a pizza order to a table in an Access database. We will be using PerlScript for Active Server Pages to perform SQL queries. We could have also used PHP, Cold Fusion, or JSP as well, but I'm most familiar with Perl and prefer its text processing capabilities, which come in handy when we're parsing text representations of user utterances.
Creating a dialog flow
I used Microsoft Viso to create a dialog flow that contains all of the prompts, decision trees, and processing instructions that are required for this application. I've split the whole diagram into two separate pieces. The first piece contains the flow for getting the customer's phone number and address. The flow starts by playing a greeting and is followed by a prompt asking the user for their phone number. The system confirms the number by speaking the number back and asking the customer to confirm that the number that was recognized as the number they uttered. If it's not, the system will prompt the customer for their phone number again until the customer confirms that the correct phone number was recognized.
When the customer does confirm that we have the correct number, we submit the VoiceXML form to a back-end ASP script, which uses we uses the phone number as a key to look up the customer's record in the Access database. If the number doesn't exist, we create one and prompt the user for their address. Their address is recorded as a .wav file and submitted to another ASP script, which saves the file and associates it with the customer's record.
If the customer has previously used the system to place an order and they provide the same phone number, the database will ask the user to confirm the address or provide a new one. If the customer confirms the address, we move on to the next dialog flow, which takes the customer's order. If the customer does not confirm the address, the system prompts the user to record their address, and the resulting .wav file is saved and associated with their customer record.
Now we have confirmed a valid phone number and address, we move to the second part of the dialog flow, which prompts the customer for their pizza order. Notice that our prompt is, "May I take your order please." This is a rather open ended question. We need to be ready to handle many different utterances that the user might provide. If the range of utterances is too wide to cover, we may need to provide a more specific prompt that provides the options that the customer can select from. The slots (or form fields) that we need to fill to place a pizza order are the pizza size, the pizza type, and the pizza toppings. Because this will be a mixed initiative dialog, the customer could fill all of the slots with a single utterance like, "I would like a small hand tossed pizza with pepperoni and mushrooms". On the other hand, they might just say, "I'd like a small pepperoni pizza". So we need to be able to handle cases where the customer does not fill all of the slots by providing directed prompts for those fields that were not filled. In the last example utterance, we would want to prompt the customer for a pizza type.
Once all of the slots have been filled, we want to play the order back to the customer and have them confirm the order. If the customer says "Yes", then we thank them for the order, record the order in the Access database, and end the call. If the customer says "No", we need to go back and prompt them for their order again until we get it right.
And that's our dialog flow. It a good idea to map it out on paper or in some kind of a dialog flow so that you or your customer can review the call flow to ensure that it will satisfy the business and customer needs fully.
Page 1 of 2