IVR Technology Solutions

This section of our technical library presents information and documentation relating to IVR Suppliers 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 Interactive Voice Response?. 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 Jennifer Tomaro, CommWeb

Think about it. Instead of simple telephone-based access to existing database information through a touchtone interface (IVR), the big idea now is to let callers access information found embedded within Web pages.

Any way you slice it, that's a lot of information; that's also a lot of information made available through the most ubiquitous user terminal in the world (the increasingly mobile phone); and that's a lot of information neatly bundled on a standardized world-reaching transport mechanism -- the Internet.

And to make things even more riveting, there are several new plot lines weaved into the original IVR story that should have the CT development/service industry on the edge of its collective seat, including:

• The potential of "hosted" voice-response applications.

  It's an extremely intriguing idea, albeit not a new one. As Chris Bajorek explored in a recent Communications Convergence article titled Voice Portal Solutions: Host Or Buy?", the concept of an enterprise business using an IVR "service bureau", which has been around for years, never really took off.
  
  As Chris wrote:
  
  One of the reasons why was the fact that the controlling database for these applications was almost always dynamic and required a "live" connection between the IVR box and the database server. While virtual network database connections could be established, they fell into the category of "royal pain," were often slow, and thus were rarely used for enterprise IVR. Most opted to buy a local IVR server and park it on the corporate LAN, where database connectivity was relatively easy.
  
  The Voice Web, however, benefits from the world of web servers and web programming which, among other things, provides a relatively high performance and standards-based mechanism for accessing corporate databases across a WAN. Combine this with a web-based, standards-based approach to developing voice applications (see next bullet) and you have the makings of a flexible, host-based voice-application environment.
  
  In other words, instead of buying an expensive, dedicated IVR server (complete with specialized software and hardware) and "parking it on your LAN", service providers can actually provide the specialized hardware/software off site; it then feeds off your website; and you, the end user, (presumably) pay a setup and ongoing fee for the privilege.
  
  Theoretically, this opens up the possibility of users dipping their toes into voice-response's waters; it also might very well lend itself to "disposable" apps, e.g. a one-time order entry/status app that serves a contest for a month or so and then is discarded. Interesting.
  
  

• The emergence of VoiceXML.

  VoiceXML is a special markup language specifically for creating the application at hand: i.e. voice-based dialogs between telephone callers and web content; i.e. turning phones into browsers.
  
  It features functions for the playing of speech prompts using pre-recorded and text-to-speech information, the acceptance of spoken commands (via speech recognition) and touchtone inputs, and the recording of caller audio information.
  
  The VoiceXML Forum produced the initial industry specification of VoiceXML 1.0 in March, 2000. They later handed off the technical evolution of the language to the World Wide Web Consortium's (W3C) Voice Browser Working Group, with the latter working on the release of VoiceXML 2.0 -- due out later this year.
  
  As we see it, there are five significant VoiceXML benefits:
  
  

  • It provides an intrinsic ability to access information stored on or accessed through a corporate web server. Since IVR systems generally require access to one or more corporate databases, any such database connectivity already implemented via a company web server is directly usable in a VoiceXML script. This has the potential to save enormous development time and money and can greatly reduce maintenance costs (one server stone killing two application birds).
    
    
  • Existing web application development tools can be leveraged for development of VoiceXML-based IVR applications. Using such tools and development methodologies also frees up IVR application developers from low-level IVR platforms (have you ever wrestled with C level telephony function calls and APIs) or database access details.
    
    
  • By introducing Web and 'Net development to computer telephony, it should greatly expand the voice-processing market. While researching this feature, Bill Dykas, Manager of Strategic Alliance, IBM and Chairman of the VoiceXML Forum, put this benefit to us bluntly:
    
    "VoiceXML leverages the existing skills of Web developers, thus taking advantage of a large pool of developers. And because it's an open standard, applications can be more portable between platforms. The end result is the expansion of voice applications in the marketplace."
    
    Most also agree that VoiceXML decreases the level of expertise required to create voice applications, thus allowing for more rapid voice application development. To wit: any web server-based scripting language (Perl, ASP, JSP, etc) can be used to create VoiceXML documents dynamically. This allows other web-based programs to auto-generate VoiceXML pages that get executed on the fly.
    
    
  • It creates the definite possibility of application interoperability. As Mr. Dykas alluded to, since VoiceXML is a standard (albeit a youthful, emerging one), you are (in theory) free to change to other VoiceXML-compliant IVR platform vendors without losing development work.
    
    Thus, in our ongoing series of accompanying CT Labs-based functionality and performance tests on VoiceXML server vendors, one of the key "guiding light" questions was how many VoiceXML 1.00 elements are supported by the products or services (there's lots more on things like: which grammar formats are supported, what unique features and/or developer tools are available for the various platforms, etc.)?
    
    In this case, the same "script pages" were used to generate applications across the different vendors platforms, which is something you wouldn't even dream of doing in a multivendor comparison of traditional CT systems.
    
    (One parenthetical question to ask here: What Happens To The ECTF Framework; isn't interoperability one of its key benefits?)
    
    
  • The integration of ASR and TTS resources into voice-processing applications is greatly eased. This is one reason why the ASR/TTS vendors are so hot on the Voice Web and VoiceXML development.

• A series of functionality and performance tests on VoiceXML vendor solutions and services;
  
  
• A roundup of vendor development news;
  
  
• And an accompanying open Voice Web forum, where CommWeb community members can discuss the potential and more immediate possibilities of this application and its technologies.