IVR Deconstructed

How can a business or organization provide information on its web site to those who do not have internet access?  Through IVR and the use of web based programming languages like VoiceXML.

IVR is the perfect technology to provide access to a web site’s information over the phone.  Whether the site provides critical business records, customer account info, or product updates, VoiceXML can be used to leverage a web site or application’s existing business logic to emulate functionality over the phone.

Developers can access Plum’s free developer site and support community to learn VoiceXML for free.  Here is a link to sign up for an account: VoiceXML Development

Yesterday, I enjoyed an IVR moment in my life as I had received an outbound IVR call from Gamestop reminding me that a video game I had pre-ordered was available at “midnight on Tuesday, March 9th” and that I could complete my payment at “10:00 pm on Monday, March 8th”.

The brilliance of this IVR technology amazes me. For a video game store, there’s no more need for having a human employee call hundreds of pre-order customers to remind them to pick up a game. Instead, you can just queue up a list of phone numbers for your outbound IVR system to call and be done with it.

However, I had a couple of thoughts as I listened to this IVR recording on my phone.

1) Why not have an option to allow your customers to make their payment by phone?

IVR applications can allow callers to make payment by check or by credit card without the intervention of a live call representative. By doing this, you can save time for people who go to pick up their game as they wouldn’t have to wait in line for other people who are paying (and you all know how annoying it is to wait for credit card users to pay for small ticket items).

2) List a number of new games that are coming out soon and allow the user to choose which games they want to pre-order.

At the end of the recorded message, there could be one final IVR prompt that states: “Hey, just wanted to let you know that we have the following games available for you to pre-order. If you would like to pre-order Game#1, press 1. If you would like to pre-order Game#2, press 2. Otherwise, you can press 9 to end this call or hang up your phone.”

Just another random thought on how IVR is being used to make our lives better (one video game at a time).

So, how about that final season of Lost so far? It’s been a pretty wacky roller-coaster ride with the 2 alternate timelines going back and forth for the main characters. But how great would it be if the characters on the show had IVR?

Let’s first look at Jack, who before the latest episode, was having some communication issues with his son (they just weren’t talking to each other). Now, if he had an IVR system that outbound called him say 4 times a day to remind him, “Hey Jack! How bout calling your son once in awhile to let him know you care?”, then perhaps they would’ve had a better relationship from the start.

Or how bout Jin? Early on, we see him having problems with Customs at the airport for having a briefcase with a large amount of cash inside. Later, we see Sayid find a taped up Jin inside of a freezer, possibly as a result for not delivering that cash to Keamy and his henchmen. Now, if Jin was able to use an IVR application to handle his money transaction via phone, he probably wouldn’t be in this mess. Even better, an application could be designed for him so he could listen to Korean text-to-speech and would allow for Korean speech recognition.

Just a few random thoughts on how IVR can be used to improve the lives of the characters of Lost while watching the show.

Elections are fast approaching and there’s no better, cost-effective way to poll constituents over the phone than to use Plum’s outbound IVR survey platform.  Plum’s survey platform has the ability to place calls to an unlimited number of voters to collect real-time data that’s both reliable and actionable.  IVR surveys can be configured in mere minutes and instantly deployed via Plum’s Hosted IVR service. Sophisticated analysis tools and visualizations help you sift through hundreds, thousands, or millions of responses to identify hidden trends, patterns, and behaviors.

For more information, or to sign up for a free demo account, please visit: http://www.plumvoice.com/plumsurvey

Just wanted to get some tips out there to IVR developers who are designing applications and have to factor in noisy environments.

1) Set specific local properties for when you are prompting the user for an input.

So, if you had a <field> where you are prompting the user to say their name, you may want to set specific values for properties that work with speech recognition such as: sensitivity, incompletetimeout, and confidencelevel

2) Set a low sensitivity value if you believe background noise (i.e. city traffic, construction noise) will be a factor in your IVR application.

Setting a low sensitivity will help capture inputs when the caller is in a noisy environment. Typically, a value of 0.3 or 0.4 should suffice in this situation.

<property name=”sensitivity” value=”0.4″/>

3) Increasing the incompletetimeout value within your <field>.

Setting a higher incompletetimeout value will give your caller more time to input a response before the speech recognizer recognizes the IVR response. This particularly helps when the caller is saying a long string of digits and pauses in between saying digits.

<property name=”incompletetimeout” value=”3s”/>

4) Setting prompt bargein=”false”

By setting prompt bargein=”false” within your application, you can prevent the caller from accidentally barging in with an incorrect input by coughing or with a loud background noise.

<prompt bargein=”false”>
Please say your nine digit social security number.
</prompt>

Hope these tips help you with designing your IVR application.

Over the past several months we’ve talked to a number of companies who are looking to replace IVR systems that have reached end-of-life or are no longer supported.  Most of these companies are looking for solutions that support open standards like VoiceXML (VXML) or web-based tools that remove the complexity of programming an IVR application.  The good news is Plum offers a variety of deployment models (both onsite or hosted) that remove the complexities and expense of working with legacy IVR or PBX vendors.

For more information about Plum’s onsite IVR systems click here: IVR Systems
For more information about Plum’s hosted IVR solutions click here: Hosted IVR

A couple of times on the forum I see a post from an IVR developer mentioning why a transfer isn’t working. The developer mentions that when they transfer to local numbers, the transfer works just fine. However, when attempting to do a transfer to an 800 number, they are unable to connect.

Ah, there’s the problem. The IVR developer is most likely attempting to do a transfer from an 800 number to another 800 number.

US phone companies do not allow transfers to another 800 number from calls that came in on an 800 number. Let’s think about this for a moment.

Let’s say Person A makes a long distance call using a toll-free number to be transferred to another toll-free number. The call hits Phone Company A’s toll-free line and Phone Company A then forwards the call onto Phone Company B’s toll-free line. The problem here is: Who shoulders the cost of when Phone Company A is forwarding on to Phone Company B?

Because of this issue of which phone company takes the burden of this cost, the US phone system has declared 800 to 800 transferring as being not possible.

To get around this, there is the possibility of doing 800 to 800 forwarding. This process involves an 800 number first forwarding to a local number and that local number then forwarding on to an 800 number.

For IVR developers that want to implement this within their code,  please contact your sales representative about this process.

Plum Voice is now accepting requests for beta testers of our new web-based graphical IVR development toolkit called SynApps.  Those with experience developing applications in VoiceXML or IVR GUIs would be preferable.  If you are interested in becoming a beta tester for SynApps, please send an e-mail to synappsbeta@plumgroup.com

Every once in awhile, I see an IVR developer on the forum mention the possibility of building an alphanumeric IVR grammar that will allow users to spell out letters and numbers over the phone.

My response to that is this: Have you ever tried to spell out information to someone over the phone?

For example:

Person A: Hi! Welcome to the Bank of Money. How can I help you today?

Person B: Hi there. I’m having a problem with my account.

Person A: Sure. I can help you with that. Can I have you spell out your first name?

Person B: Valerie. V-a-l-e-r-i-e.

Person A: I’m sorry, I missed some of that. Was it V as in Victor? Or B as in Banana?

Person B: V as in Victor.

Person A: Last name?

Person B: Munn. M-u-n-n.

Person A: M as in Mary. U as in Umbrella. M as in Mary. M as in Mary?

Person B: No. M as in Mary. U as in Umbrella. N as in Nancy. N as in Nancy.

Person A: Ah ok. Sorry for the misunderstanding, ma’am.

…
…
…

You get the point. The problem is that even humans have trouble understanding spelling from other humans over the phone as there can be constant mix-ups between m’s and n’s, b’s and v’s, and f’s and s’s. Also, add to that the possibility of a person having a thick accent while spelling out words.

So, if humans have difficulty spelling out words, you can expect that an IVR speech recognition engine would have a problem capturing a spelling grammar. One possible solution is to implement an IVR grammar that uses the military phonetic alphabet to try to capture these spelling grammars.

For example, some IVR code to demonstrate:

<rule id=”alpha” scope=”private”>
<one-of>
<item>A<tag>SWI_literal=”A”</tag></item>
<item>A as in alpha<tag>SWI_literal=”A”</tag></item>
</one-of>
</rule>

However, even this solution would be difficult as an IVR developer shouldn’t expect general users to know of the military alphabet.

Another useful feature that root documents offer IVR developers is the ability to transition from a leaf document back to the root document. This ability allows you to send information back to your root document that has been updated through your leaf documents.

The following IVR example demonstrates how you can do this:

root.vxml (root document):

<?xml version=”1.0″?>
<vxml version=”2.0″>
<var name=”foo”/>
<form>
<block>
<prompt bargein=”false”>
The value leaf is set to <value expr=”leaf”/>.
</prompt>
</block>
</form>
</vxml>

Page1.vxml (leaf document):

<?xml version=”1.0″?>
<vxml version=”2.0″ application=”root.vxml”>
<form>
<block>
<assign name=”foo” expr=”‘bar’”/>
<goto next=”Page2.vxml” maxage=”0″ maxstale=”0″/>
</block>
</form>
</vxml>

Page2.vxml (leaf document):

<?xml version=”1.0″?>
<vxml version=”2.0″ application=”root.vxml”>
<var name=”leaf”/>
<form>
<block>
<assign name=”leaf” expr=”‘rab’”/>
<prompt bargein=”false”>
The value foo is set to <value expr=”foo”/>
</prompt>
<goto next=”root.vxml” maxage=”0″ maxstale=”0″/>
</block>
</form>
</vxml>

From this IVR example, when the application, Page1.vxml, is started, it accesses the variable, “foo”, from the root document, root.vxml, and assigns it the value of string, “bar”. Page1.vxml then transitions to Page2.vxml, which creates a new variable, “leaf”, and assigns it the value of string, “rab”. Page2.vxml then returns the prompt, “The value of foo is set to bar.” After the prompt, Page2.vxml transitions to the root document, root.vxml, which references the variable, “leaf”, from Page2.vxml and returns the prompt, “The value leaf is set to rab.” Thus, it is possible for root documents to reference variables from leaf documents as long as the leaf documents reference the root document.

This ends our discussion on the benefits of using root documents within your VoiceXML IVR code. One thing to keep in mind is that you must reference the root document in each of your leaf documents so that your leaf documents can continue to reference the same content. So, if your root document is entitled rootdocument.vxml, then you must reference the name of this root document in the following way for each of your leaf documents:

<vxml version=”2.0″ application=”rootdocument.vxml”>

If your IVR application reaches a leaf document that no longer references the root document, then the root context becomes destroyed. To clarify this point, think of an example where you have initially declared a variable within your root document and when this variable gets updated in a leaf document, the value is preserved through referencing the root document. If an IVR developer, however, forgets to  reference the root document within a leaf document, then the values that get preserved for the variables throughout the leaf document become lost at that point in the application.