IVR Deconstructed

Throughout Plum’s ten-year history as a hosted and premise-based IVR provider we have worked with a number of organizations to conduct studies for the National Institute of Health (NIH).  Using our IVR technology we’ve carried out programs to collect information about cancer patients’ pain, administered smoking cession programs, and managed a number of varying patient surveys.

Using IVR to collect data from patients is more cost effective than traditional phone interviews and since the patient is not speaking with a person, the automated IVR dialog helps to control for social desirability bias.  In addition, program administrators can place proactive outbound calls to patients, or received calls via an 800 number.  All data collected by Plum’s IVR surveys is available for review in real-time.

For more information about IVR Surveys please visit http://www.plumvoice.com/plumsurvey

Today, we’ll be discussing a little bit about VXML (VoiceXML). To explain the term, VoiceXML:

VoiceXML stands for Voice eXtensible Markup Language. It is a language designed to allow a user to interact with an application through voice recognition software. The language is based off of the W3C’s XML. The language is very similar to HTML and allows for the developers to use various IVR features such as recording, DTMF input, spoken input, TTS output, and recorded audio output. It uses various tags to control the flow of the application. It also allows for built-in error handling as well as various telephony features like call transfer and disconnect.

VoiceXML was originally created by the VoiceXML Forum which was a collaborative effort by Motorola , AT&T, Lucent Technologies, and IBM in 1999. In 2000 the VoiceXML Forum became a program under the IEEE Industry and Standards Organization (IEEE-ISTO). The Forum also offers a conformance test for the W3C VoiceXML 2.0 standard.

A basic VoiceXML application should look like this:

<vxml version=”2.0″>
<form>
<block>
<prompt> Hello world! </prompt>
</block>
</form>
</vxml>

For you IVR developers out there, keep in mind that you can integrate VoiceXML into whatever programming language you’re comfortable with. A couple of times on the forums, I’ve seen some developers who didn’t realize they could integrate VoiceXML into their ASP or PHP for their IVR application. Well, now you know!

TTS, ASR, VXML, IVR…these terms may seem a bit confusing at times, but fear not. I will be explaining one of these terms to you today.

ASR:

ASR stands for Automatic Speech Recognition. It represents a collection of technologies required for an IVR system to listen for specific words and phrases, detect the speech from within an audio sample, analyze the speech relative to what is being listened for, and provide the final text representing what the ASR system believes was uttered.

IVR-specific implementations of ASR do grammar-driven recognition. The ASR engine must be informed of the specific utterances that it is likely to hear. The list of utterances may number in the tens of thousands (with names or cities, for instance) but this list must nonetheless be finite. The grammar formats supported by the Plum Voice IVR Platform are SRGS and JSGF.

Please keep the following in mind for our US IVR production hosting systems:

“For speech recognition, we currently only offer American English speech recogition, Spanish speech recognition, French-Canadian speech recognition for hosting. If you are interested in any other speech recognition languages, please contact your sales representative.”

For our UK IVR production hosting systems:

“For speech recognition, we currently only offer American English speech recogition and British English speech recognition for hosting. If you are interested in any other speech recognition languages, please contact your sales representative.”

Please keep in mind that ASR is not the same thing as TTS (text-to-speech), which will be covered in a future blog post.

When pre-recording audio files for IVR applications, IVR developers should take note of the following:

For file formats, we recommend encoding it as a .wav file with these specifications:

- channels: mono
- sample rate: 8 kHz
- encoding: 16-bit linear PCM headerless

As for recording tips, we recommend:

- a quiet echo-free environment
- a high quality microphone
- high-end recording software
- always record at the rate you will be playing at

Regarding microphones, a USB microphones is going to give you the least amount of interference for computer audio recordings as a headset tends to pick up a lot of sound from the person wearing it (both movement and breath). We recommend using a USB microphone that is either shock mounted or at least has a padded base placed on a solid surface. It is also critical that you try to maintain this audio environment for future recordings so that even audio recorded at different times can be used in the same IVR application.

Regarding the recording software, we recommend using Audacity, which is free, open source software that allows you to record and edit your sounds. You can find it here in this link: http://audacity.sourceforge.net/

As for some pre-processing tips, you want to make sure that the audio levels for the recordings come as close to peaking volume as possible without ever reaching the peak. If you do reach hit peak volume, you will want to rerecord the audio, as normalizing will not fix the IVR issue of digital clipping. For post processing, you should normalize all of your audio recordings. You should normalize all audio files to the same threshold percentage and we usually do a 90% threshold. This level prevents the audio from clipping on certain phones and keeps a consistent volume throughout your recordings.

Hope these tips help you IVR developers out there.

Thinking back on recent events that have occurred for me and my
co-workers during the last few weeks, I’ve come to realize that IVR
would be extremely useful in confirming receipt of packages. One of my
co-workers had attended a lacrosse game a couple of weeks ago, but prior
to attending the game, he had wondered why his tickets hadn’t arrived
yet. So, he called up the ticket seller to check to see if his tickets
had arrived yet. Similarly, I had been expecting a pass to arrive in the
mail for attending a convention and had thought about contacting the
convention providers about my pass (it had come in the mail a couple of
days afterwards though).

Instead of having to go through this process, ticket sellers (or other
businesses) could use IVR to send a notice to customers that their
package has arrived. An IVR application would be written and using our
IVR outbound system, they would be able to make calls to their customers
to confirm that a package has been sent and should have been received.

It sure beats having to track someone done to confirm a shipment. Just
another random thought on how IVR can be used to improve our lives.