IVR Applications

This section of our technical library presents information and documentation relating to IVR Development and custom IVR software and products. Business phone systems and toll free answering systems (generally 800 numbers and their equivalent) are very popular for service and sales organizations, allowing customers and prospects to call your organization anywhere in the country. The PACER and WIZARD IVR System is just one of many DSC call center phone system features..

What Is IVR?. An Interactive Voice Response (IVR) processes inbound phone calls, plays recorded messages including information extracted from databases and the internet, and potentially routes calls to either inhouse service agents or transfers the caller to an outside extension.

Contact DSC today. to learn more about our IVR services and IVR application development software.

By Robert Richardson, Computer Telephony

IVR is moving off the premise and into the network. And its front and back-ends are changing - to embrace wireless, the web, and Net development models.

If the desktop IVR decides that it's appropriate for it to take control of the call, similar COM requests are relayed by DCOM such that the call is transferred to a virtual extension. This extension resides within the unPBX. Any necessary IVR processing will occur there, using a DSP on the unPBX, but control will again be via a COM stub residing at the desktop, conveying its requests through DCOM.

Says Hamel: "We already have done some testing on this. The problem is that people don't have the infrastructure to support it yet. Telephone equipment that supports this virtual port concept is either not on the market yet or else is too proprietary, too closed." Nortel's Business Communications Manager, for instance, supports a virtual port interface (and Hamel has tested with it). But although the BCM is NT-based and could theoretically be updated to provide specific DCOM objects that a company like Decisif might need to provide services at the desktop, Hamel says Nortel doesn't allow modifications to the server's software. Hamel predicts more open platforms will emerge, but expects a three- to five-year delay before there is sufficient market penetration for the personal IVR concept to have any hope of taking root.

The Final Mix

The typical kind of convergence we discuss in this industry has to do with data types - in particular, with treating voice as just another data type. But there's another kind of convergence we'd better reckon with as well: the convergence of interface types. We may have started from an industry where the devices at the periphery of the network were all plain, corded handsets, but the brutal simplicity and homogeneity of that interface (dial tones in, recorded messages out) is rapidly being eclipsed by cell phones with multi-line displays (and backspace keys!), Blackberry pagers, PCs with softphones, and phones with built-in Palm OS PDAs.

In the past, IVR has carved out a workable niche using the limited DTMF interface to communicate with back-end computers. Now, of course, users are catching a glimpse and a whisper of better alternatives. We should expect users who expect to talk to applications when that's most appropriate, to pick from WAP-enabled text menus in other cases, and to press the numeric keypad when a simple, numeric answer suffices. Furthermore, users will rightfully demand that applications seamlessly integrate all three interfaces at once, so that a spoken request for a flight from New York to Boise will result in an onscreen menu of possible itineraries, which we might well select with a key press. The architectures for these multi-channel applications will be structured either with components or specialized markup languages, or (most probably) both. The technology for the various pieces needed to support this multi-channel approach are already in place (at least in their first cuts) in the form of WAP and VoiceXML, so creating an architecture for combined application may boil down to a few timely mergers and acquisitions. Perhaps the most radical possibility of all: the architects for these applications may turn out to be just plain web-literate folks.

If you want to dig right in to an XML-based approach to IVR, a relatively painless approach can be found at Tellme.com's web-based Tellme Studio. When I tried it, I decided to see if I could hook into a database I was keeping on a website I maintain for a computer science course I teach. My goal: make it possible for students to phone in for reminders on upcoming due dates and hints on current assignments.

To keep things simple, I decided that the only interface I'd allow was asking the student what assignment number they wanted. If they chose a valid assignment number, I'd find it in a simple Microsoft Access assignment database. The interesting aspects here are the database access, the ability to draw the text-to-speech (TTS) content for the IVR from the same database that feeds the website, and the embedding of the IVR structure within the web pages.

Tellme has made it almost deceptively easy to get started with this sort of thing. All I had to do was jump over to their developer website (studio.tellme.com) and create an account. Once assigned a developer number and pin, I was brought to a screen containing a slew of links to tools and documentation, among them an edit box with a simple "hello, world" application written in voiceXML. (Tellme refers to this as VXML - in time this sort of variation presumably will be normalized.) If I called the studio toll-free number and entered my account numbers, I'd hear whatever bit of application was currently in that window.

To really get going, of course, I had to change the text in the edit box and start creating my own code. Alternately, I could point my account to my own voiceXML page on the web server of my choice. Since eventually I'd need a page running on my server so that I could generate dynamic voiceXML content based on the contents of a database, I decided to go ahead and point to my own page on my own server, which proved straightforward. Unlike other leading-edge web data formats I've experimented with, I didn't have to add the data type to the server configuration, which was refreshing. Tellme's servers seem to be smart enough to deal with files that are delivered without the right MIME type header, but with the right extension and content.

VoiceXML pages are generally designed as if they were traditional HTML forms. The fields in the forms are the inputs you'd like to get from your caller, and the fields are tackled one after the other (unless you programmatically change the processing order, of course.) Whenever you want the system to say something to the user, you simply enclose the words within an tag, like this:

I love the taste of parsley

which will be read using text-to-speech at the appropriate moment. If you don't want the computer voice (which is pretty good, by the way), you can reference pre-recorded .WAV files like this:

I love the taste of parsely

The written text here is only spoken if the .wav file, for some reason, can't be played.

Where Tellme Studio really starts to get interesting, though, is when you start soliciting user input for whatever fields you've put into your form. VoiceXML allows you to pick up either DTMF or spoken input or both. Your job as a developer is to tell it what answers it should expect. (You can't let it pick up any old answer and try to figure out what that text means after the fact.)

A group of allowable answers is called a grammar. You either create a specific grammar for a field or else you can use one or more pre-existing grammars. The Tellme studio thoughtfully provides a set of the grammars you're likely to need over and over again. In my test application, for instance, I need to ask callers to tell me the number of the assignment they want to hear. They'll either say or dial in a number from one to twenty or so (the exact number of assignments will vary from semester to semester).