IVR Deconstructed

Every once in a while, an IVR developer will encounter the following entry in their call log:

“Error fetching document http://x.x.x.x/somefile.aspx due to Operation timed out with 0 out of -1 bytes received”

This is usually followed up with an exclamation from the developer such as this: “Why is the IVR taking so long to submit a file to my web server?”

Well, typically, an error message such as this indicates not a problem with the IVR server, but a problem with the IVR developer’s web server.

When encountering this issue, here are some general tips to first try:

1) Using a different domain name. Using a domain name tells the IVR to use a currently open socket. By referring to your web server by its IP address, for instance, the IVR will open a new connection to your backend rather than reusing an existing HTTP connection.

2) (if using IIS) Checking the IIS configuration. You might have to change the settings for your IIS configuration to allow for longer persistent connections or, alternatively, no persistent connections at all. A forum poster once mentioned that turning off the Keep-Alives inside IIS helped them resolve this issue. See here for more details.

3) Checking the firewall settings. If you use a firewall between your web server and the Internet, the firewall might be keeping the persistent connection open to the IVR even though IIS has already closed its server-side connection.

4) Setting up a catch error handler for error.badfetch and then doing a resubmission. This would allow you to re-attempt sending data even when the error.badfetch occurs.

Hope this helps you IVR developers out there who’ve encountered this issue.

Talking with some of the other IVR engineers here, we noticed how common it is for developers to use speech recognition in instances where touch tone input would be more appropriate.  This approach to developing IVR applications is sometimes done at the expense of a good caller experience. For example, for one IVR application, I’ve seen a developer ask about having callers use speech recognition for entering account information. Another example is seeing a developer suggest using speech recognition for a multilingual IVR application.  In both cases, touch tone input would have been a more user friendly approach.

In the first example, using speech recognition solely to enter account information is overkill and can be ineffective. If your IVR application asks for a multi-digit number (say a 9-digit social security number), then there is a high chance for <nomatch>es when the caller says their input.

(if the user says their input too slowly)

Computer: Please enter your nine digit social security number.

Human: Nine six five…four two…

Computer: I’m sorry, you entered an incorrect amount of digits. Please enter your nine digit social security number.

This same situation can also occur if the caller says their digits too quickly. If you were to proceed with designing your IVR application in this manner, please see here for tips.

In the second example, if you are designing a multilingual application and aren’t careful about sectioning off your application into different VoiceXML pages, then your IVR application can become cumbersome to navigate.

(Korean caller)

Human (in Korean): I would like a burger.

Computer (in English): I heard chicken. Is this correct? Say yes to confirm or no to place your order again.

You see the point. Multilingual IVR applications without the option of touch tone input would be extremely difficult for callers to use.

So, in general, IVR developers should not restrict their IVR application to using speech recognition only, but also allow for touch tone input.

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