IVR Deconstructed

There has been a couple of times on the developer forum where I’ve seen users put builtin and inline grammars all within the same field of their IVR code. A common misconception that users don’t seem to understand is that when you use a built-in grammar within the VoiceXML, you’re secretly telling your field specifically how you want you callers to input the data.

For example, when you add this into your IVR code:

<field name=”phone” type=”digits?length=10″>

this built-in grammar, digits?length=10, allows for the user to only enter 10 digits either by voice or by DTMF (phone keypad entries).

However, if you were to add this inline grammar right underneath that line of code:

<grammar mode=”dtmf” type=”application/x-jsgf”>(1|2|3|4|5|6|7|8|9|0)+ </grammar>

this VoiceXML grammar allows for the user to enter multiple digits (with no restriction on the number of digits that can be entered) by DTMF only.

So, if you’re the IVR platform, what do you do? You have two different VoiceXML grammars giving you different instructions on how to capture data from the user. Because of this, inconsistent behavior can occur for your phone application.

To avoid this hazard, you should use either a stand-alone built-in grammar or a stand-alone inline grammar.

Just for your knowledge, this specific example was based on a user who was looking to only capture 10 digits, but by DTMF only. To resolve this, we can do:

<grammar src=”builtin:dtmf/digits?length=10″/>

This grammar allows only up to 10 digits and this portion, builtin:dtmf, only allows for DTMF only.

Hope this helps you developers out there who may have some questions on implementing VoiceXML grammars.

Have you ever tried experimenting with the different TTS (Text-to-Speech) engines (AT&T Natural Voices, Cepstral, Nuance Realspeak) and finding that each engine behaves differently with your IVR (Interactive Voice Response) code?

Well, that’s because each engine DOES behave differently!

Let’s take a look at a specific IVR example using a Spanish TTS voice for each of the different TTS engines.

For AT&T Natural Voices:

<?xml version=”1.0″ encoding=”latin-1″?>
<vxml version=”2.0″>
<form>
<block>
<prompt>
<voice name=”rosa”>
Hola. Su sombrero es muy grande.
</voice>
</prompt>
</block>
</form>
</vxml>

For Cepstral:

<?xml version=”1.0″ encoding=”latin-1″?>
<vxml version=”2.0″>
<form>
<block>
<prompt>
<voice name=”Marta”>
Hola. Su sombrero es muy grande.
</voice>
</prompt>
</block>
</form>
</vxml>

For Nuance Realspeak:

<?xml version=”1.0″ encoding=”latin-1″?>
<vxml version=”2.0″>
<form>
<block>
<prompt>
<speak xml:lang=”es-MX”><voice name=”Paulina” gender=”female”>
Hola. Su sombrero es muy grande.
</voice></speak>
</prompt>
</block>
</form>
</vxml>

One of these things is DEFINITELY not like the other. Nuance Realspeak has to be implemented in this manner in order to get consistent behavior for this prompt. However, AT&T Natural Voices and Cepstral do not need these extra tags.

So, the next time you’re implementing your IVR code and using a foreign language TTS voice, please be mindful of these inconsistencies that exist amongst the different TTS engines.

Plum’s professional services group has developed hundreds of IVR applications for customers in industries such as health care, insurance, travel, manufacturing, and financial services. Questions about how the IVR call flow will interact with existing database systems and business logic invariably come up during the course of our discussions with clients. As such, we’ve put together the following analogy to help illustrate how IVR works.

A VoiceXML IVR application operates like your traditional web application. However, instead of a web browser (like Firefox or Internet Explorer) presenting an HTML-based web page generated by a web server that, in turn, asks for data from a database, a VoiceXML IVR application plays a VoiceXML-based dialog generated by a web server that also asks for data from a database.

Think of it like ordering food at a restaurant. You are presented with a menu of choices by the waiter. After perusing the menu, you settle on a few choices and you communicate them to your waiter. Your waiter takes your order but he or she does not actually cook it all up. Your waiter submits your order to the cook who then grabs various ingredients from the refrigerator and processes the ingredients into a fine set of dishes. The waiter then picks up your dishes, brings them to your table, and serves them to you.

Now instead of a menu, waiter, cook, and refrigerator, we have an IVR server, a call flow application server, a business logic server, and a database. The call flow app server tells the IVR what to say and what to collect from the caller. For instance, the call flow app server might instruct the IVR to ask for an ID number. The caller enters the ID number over the phone and the IVR delivers this number to the call flow app server. The call flow app server, however, does not know what data is associated with this ID number so it has to ask the business logic server for this data. The business logic server knows how to extract this data from the database based on the ID number. Let’s say it’s an account balance. This value is determined by the business logic server and is relayed to the call flow app server. The call flow app server then builds a VoiceXML script that will instruct the IVR server to state your current account balance.

We refer to this as the VoiceXML IVR four-tier architecture. Plum Voice built the IVR platform (tier one) from the ground up and we specialize in writing custom call flow application server code (tier two). Most of our customers provide tiers three and four on their own as they already own a web server and database that suit those two roles respectively. In general, it makes more sense for our customers to write the business logic server code as they have the most knowledge of how their business processes work and how their business data is structured.

Staying connected to customers is no longer a goal in business, it’s a necessity.  Well deployed IVR systems are now commonplace in businesses as a method to better serve the client with advantages that include:

• More precise call routing
• Automated account inquiries
• Time and task reporting
• Customer satisfaction surveys
• Automated ordering and invoice tracking
• Outbound alerts

And that’s just the beginning.  Above and beyond the service advantages provided to your customers, an IVR system can save you money by streamlining processes, automating services and providing information to your client base or employees 24×7.  When you look further and see reliability metrics and scalability potential you can see why so many of today’s successful businesses consider their IVR system one of their most valuable “employees”.

To find out more about what IVR and a properly executed IVR system can do for your business, contact the professionals at Plum Voice.