A voice portal is the interface between a caller and an information source - it's the point of entry for a person using an IVR or speech recognition system. When augmented with VoiceXML, the voice portal can host a much wider variety of information, literally funneling any web-based data from your servers out to callers. (For more on the fundamentals of voice portals, check out the recent CommWeb roundtable, Voice Portals & The Future of IVR.)
It also opens the door to using outsourced services for the VoiceXML resources. Voice portals can either host the application web pages themselves, or they can gather the html pages from remote web servers. CT Labs recently completed a test of four companies that provide these Voice Portal services: BeVocal, HeyAnita, Tellme, and VoiceGenie.
In the test, CT Labs hosted the web pages that contained the application and ran it on each of those companies' voice portal servers remotely. As shown in the figure, CT Labs hosted the application scripts on an in-house Microsoft IIS web server (see Test Setup). The calls were placed into the vendor's Implementation Server which accessed the application VoiceXML pages via an Internet connection. The vendor's servers provided all the resources necessary to play, record, handle dtmf of spoken commands, play out information to callers via prerecorded files or by using text-to-speech.
The goal of the test was to see how easy it would be to create a VoiceXML app from scratch, and get it up and running on each of the four platforms. What they found is perhaps not so different from the experience lots of people have in other app gen areas: they concluded that while basic VoiceXML programming is fairly straightforward, modifying the scripts they'd created to work with each vendor's specific grammars was more time-consuming than they'd expected.
The main reason for this, though, does not lie with the vendors. Rather, it's inherent in the VoiceXML spec itself, which doesn't go so far as to define grammar formats, or even audio file formats. With some of those important choices left to the vendors, the ability to port a specific app from one vendor to another is necessarily limited.
Of the four vendors tested, BeVocal received the best overall score. They received the best scores in the categories of ease of application creation/setup; online documentation/resources; and text-to-speech listening quality.
VoiceGenie beat out Tellme for second place by a very narrow margin. Voice Genie tested out to have extremely quick DTMF command response, and creating the app for them required no changes in the scripts original grammars, which was a plus. Tellme received a perfect score for their response times to voice commands, and had the best online libraries. HeyAnita missed a better score because of the lack of developer resources available on their website, which is scheduled to be remedied soon (February, 2001).
Creating The Code
CT Labs used the VoiceXML Forum's spec, and reports that the test engineer found the concept and structure of the language fairly easy to use. They note that although they mapped out what they considered a simple six-page script, it took their engineer a week to learn and code the app to VoiceXML standards. Therefore, for someone creating a real-world app, with a live database behind it and more complex functions, the amount of time would be greater.
Each vendor tested offers a service to write or help write VoiceXML apps for their customers. And CT Labs suggests in their report that if you are planning on porting an existing app to a new vendor's server, it's advisable to have the vendor representatives look over the code.
The testers also reported that once they had the standard VoiceXML scripts written, they still had difficulty getting the scripts to work successfully using only the vendor's developer resources and the VoiceXML spec document. The main problem was differences in the way the vendors handle grammars, and this required help from each vendor to get right.
The testing regimen included a comparative analysis of the feature set offered by each vendor, and an evaluation of how those features performed in practice.
They created a dial-in application that used as many of the implementation server's features as possible: recorded prompts, DTMF commands, text-to-speech, speech recognition, and so forth. They were designed to exercise up to 12 simultaneous lines on each voice portal server, and use eight different speakers or recorded voice samples, so as to test the speech rec engine's ability to recognize different speakers.
Speed of response was logged and analyzed and factored into the scoring, and 12-line call loads were generated into each vendor's server for as long as three hours to verify consistent load-handling abilities.
For complete details on how the tests were conducted, what the script call-flow looked like, and how each vendor performed in each category, download the full report.
See Product Overview
See Product Review Results Grid
See Performance Tests & Results
See Samples Of Voice XML Script
