Custom 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.

The "RS" is the variable name assigned to the record in the first section of VBScript. "Weekstart" is the name of one of the columns (or to say it a different way, one of the fields) in the syllabus table. This reference to the database is replaced at the server with the actual value from the database, so that what Tellme sees is:

The first text in the database is sample data

If you open up the syllabus table using Access, you'll see that the first record contains "sample data" as the entry for the "weekstart" field.

What remains to be done now is to have one VoiceXML page get the desired assignment number (corresponding to the record index field in my Access table) and then pass that to an ASP page that uses that number to perform a search along the lines of the one we just looked at. This is essentially no different than any other web page that, say, submits a form to an ASP page. The call from the first page looks like this:

ASP has built-in mechanisms for parsing out parameters that are passed in using this kind of call.

Though I was able to cobble together a rudimentary first pass at my own IVR application fairly quickly (it took about a day to get past the initial pratfalls), that's not to say that putting together a full-fledged voiceXML application is something that any casual web master will want to try on their own. It took a fair bit of debugging know-how and a thorough grounding in the workings of server-side programming to keep from getting totally lost when calling the Tellme developer 800 number resulted in an announcement that an error had occurred and the party was over.

For the intrepid, Tellme does provide reasonably good debugging tools, including a real-time log of system events, errors, and variable values shown onscreen as you're making a call to the test network.

Almost everyone we talked to about IVR mentioned that speech recognition had finally arrived. There was general agreement about which companies had made it arrive, too: Nuance (Menlo Park, CA - 650-847-0000, www.nuance.com) and SpeechWorks International (Boston, MA - 617-428-4444, www.speechworks.com).

Why has the accuracy of speech recognition gotten so much better? It's a combination of two trends that have reached critical mass, according to Steve Ehrlich, vice president of marketing at Nuance. First, the cost of ample processing on "decent open systems" has dropped to the point where CPU-intensive recognition algorithms are affordable even in smaller applications.

The second trend has to do with getting better with practice. Says Ehrlich: "Getting that first recognition system up and running required a great amount of hand tuning of the statistical models behind the speech recognition. But once you get people calling into the system, you can start logging the calls, and those calls are then used to train the models so they can keep getting better and better. As more systems get deployed, the accuracy of the systems just gets better and better."

Ehrlich says most systems these days have better than ninety percent accuracy in their first attempt to recognize a phrase. There's still work to do, however, in creating statistical models that deal with noisy environments. Key target users of speech recognition, after all, are cell phone users, who often have imperfect connections and lots of background noise.

Ken Waln, director of architecture at Edify (Santa Clara, CA - 408-982-2000, www.edify.com), believes that while mobile users have a growing need for the relatively "mass media" data that voice portals will provide, he thinks good voice recognition also leads in another direction - lending support for increasingly complicated transactions being carried out in what might be called "traditional" IVR systems. Users don't want to try and find a retail item like a sweater by dialing through a dozen touchtone menus, but a system that allows them to simply ask for a red sweater may see some use.

Not only is speech recognition friendlier to customers, but it may be more secure. Waln points to the application Edify rolled out for Home Shopping Network last year (see Muraskin File, last month's issue), in which user identities are verified by asking callers to say their phone number. The simultaneous speech recognition and voice verification platform was provided by Nuance. "It's a milestone in that it's the first time I can think of that an IVR system has been used to do something that a human operator really couldn't do."

Ehrlich agrees: "You'll see a tremendous growth in the use of voice authentication technology over the next couple of years. A lot of our brokerage clients take thousands of calls every day just from people who've forgotten their PIN number and need it reset." At Home Shopping Network, he points out, they've done away with PIN numbers completely.

Not everybody thinks we're going to see personal, desktop IVR any time soon. But if personal IVR does invade our lives, it'll be either because DSPs are built onto motherboards (a distinct possibility in the wake of Intel's acquisition of Dialogic), or because DSP capabilities housed in unPBX servers are shared with desktops remotely across the network.

This second possibility is potentially a lot cheaper and will embrace existing desktop hardware. Programming it will embrace the kind of component architectures that have been deployed throughout the software industry over the last several years. Since so many telephony servers are built on NT and so many desktops are Windows based, the likely component architecture would seem to be the one created and espoused by Microsoft - COM.

COM (for Component Object Model) is Microsoft's answer to the question of how to reuse code. Part of the reuse scenario has been periodically recycling and slightly repackaging COM itself, such that it has appeared over time as OLE, ActiveX, and COM+, each adding to what the technology can do but each essentially building atop the same old COM.

There are, we hasten to add, other approaches to code reuse. The system that stands most directly as the alternative to COM is CORBA (Common Object Request Broker Architecture). CORBA is an open standard with industry-wide support; COM belongs to Microsoft but, by virtue of the predominance of Windows desktops, is more widely distributed. We'll discuss COM here, but the same general principles apply to CORBA.

So what does the "same old COM" do for us? Basically, it allows one program to use the subroutines of another program by directly calling the subroutine as if it were a subroutine built into the first program. This means that programs don't have to incorporate the code for functions they'll obtain via COM objects, leading to smaller main application code size and more efficient use of memory (because many applications can use the same copy of a COM object in memory).