Part 2 of this Series on Telephony and IVR Explores Some Alternatives for Building Computer-Telephone Applications.
Did you know that the first computer-telephone integration (CTI) device is as old as the telephone itself, and not at all a recent invention. It was (and is) called the "teenager." The teenager is really a telephone with hair that can deliver messages at a rate of a million words per minute, and has a computer-like memory for trivia such as who appeared on every MTV program, and when, since the beginning of the network. All I know is that my own interest in CTI came about while watching, with utter amazement, my 13-year-old, slouched on a sofa, carry on two simultaneous conversations over two telephone lines without apparently missing a beat. Between my own CTI work and the teenager, I find that six telephone lines in the house is not enough.
In the first article of this series ("Computer Telephony and Interactive Voice Response," November 1995, page 72), I introduced you to computer telephony (CT) and interactive voice response (IVR). In that article, I gave you some guidelines on IVR script writing and discussed how you could get your first IVR application up and running on a shoestring budget. The Computerfone device I described had three major advantages: low price, transportability, and ease of installation. The last two advantages result from the fact that the device is an external unit that simply plugs into a computer's RS232 port.
Alas, in IVR, as in life, nothing is perfect. If your system requires multiple lines and you don't want to be bothered with programming to the bare metal, you would probably want to look elsewhere. In this article, I discuss some alternative options.
The IRS project is called TeleFile, and it is designed "to make the tax filing process easier and more efficient." Uh-huh. For this large project, the IRS chose the VPS/sp line from Periphonics Corp. VPS/sp is a RISC-based system hosted on a Sun SPARC machine that can support more than 120 digital or analog telephone lines. To complement this hardware, Periphonics offers a visual application development tool for designing and creating IVR applications. The tool, called PeriProducer, lets users build applications by connecting iconized building blocks. The building blocks include not just the bread-and-butter functions of an IVR application such as "Answer the phone with a greeting" and "Get caller data" (touch-tone or voice), but also extended functions such as "Send fax" or "Receive fax." Thus, with this tool, developing an IVR application with integrated fax-on-demand is almost a no-brainer.
Just to give you a flavor for some of the IVR applications developed by government and large businesses using the VPS/sp line, the California Department of Motor Vehicles has a system in place to handle motorists' inquiries around the clock, and also to enable motorists to schedule appointments. The system probably got its most severe shakedown the day a white Bronco was seen leading a parade of police cars down the Hollywood Freeway.
One of the best examples of IVR's ability to improve service and cut costs is the system operated by the Army Emergency Relief (AER). Soldiers who are transferring from one installation to another must first clear any debt with the AER headquarters in Virginia. As I understand it, there are approximately 20,000 soldiers in transit around the world at any given time. In the past, considering the volume and the 11 time zones involved, an installation that could not reach headquarters tended simply to clear and release soldiers even though these soldiers may have had outstanding debts. But this isn't the case anymore. The VPS/sp IVR application speeded up the clearing process with its 24-hour availability, and it reduced the problem of outstanding AER accounts substantially.
But what if your organization or client does not have the budget of the AER or IRS? You may not be able to play in the VPS/sp league, but you're not out of the IVR market altogether if you talk either Microsoft FoxPro or Visual Basic. Read on.
FoxPro aficionados have waited a long time for the opportunity to play in the IVR game. Therefore, they were dancing in the streets the day Voysys Corp. released the VoysAccess toolkit (VTK). The toolkit allows a reasonably accomplished FoxPro for Windows developer to design and implement an IVR application in a matter of hours. VTK consists of a two-line telephone interface board made by industry-leading Dialogic Corp. (Parsippany, NJ), IVR development software in the form of a FoxPro/Windows API library, a set of pre-recorded voice prompts, and voysSmith, a voice prompt editor.
Once you get past the installation, you're home free. The installation's level of difficulty increases in inverse proportion to your experience in mounting interface boards, as well as to old-fashioned luck. The board requires: 1) a hardware interrupt (default IRQ3); 2) a shared memory address (default D000H) used for communication between the board and the software; and 3) a software interrupt (default 62H). The first two pieces require that you change jumpers on the board if you can't live with the default values.
I used IRQ 5 (typically used by LPT2) because my machines already have IRQ 3 and 4, taken by a mouse and modem, respectively. The installation software does not help you figure out which IRQs are taken; instead, you are asked to run the MSD (Microsoft Diagnostics program) utility to get that information. Windows 95 (a.k.a. Macintosh 1988), where were you when I needed you? If you are using an expanded memory manager such as EMM386 or Quarterdeck's QEMM, you'll need to exclude 200H bytes of memory beginning with your chosen shared-memory address.
The install program adds a line to your autoexec.bat file, invoking the batch file Voysload.bat. You must run the latter before you can use the VTK. It loads a memory resident module that grabs a whopping 150KB of memory. You must also run the VoysAccess Server (click on the icon or make it part of your Windows startup) before you can run the VTK. The memory resident module and the Server are required before you can "talk" to the voice board, even at runtime.
You may be surprised to learn that the VTK has only eight functions. The truth is, you don't even need all of those functions to develop fairly elaborate IVR applications. Thus, it's a small wonder that you can get going in a matter of hours. Basically, there are two kinds of IVR applications: one that people dial in to call, and one that dials out to call people. Most applications I have seen are of the first type. In such applications, the program flow is predictable, consisting of the following basic steps:
I wrote the system for a manager of a department full of consultants who work off-site. The consultants are very good at what they do, but are practically braindead when it comes to time reporting. The department has just instituted a policy that requires employees to report time spent on projects at the end of each day. Employees call in from anywhere in the country to update the Time and Attendance database.
You can view sample code on the DBMS Web site (http://www.dbmsmag.com/ivr.html). The code is also available in our CompuServe forum library 13. This sample shows code fragments from the system related to IVR. (I left out processing details and error-trapping code to keep the discussion focused on VTK functions.) I started out by requesting the department secretary, who has a professional-quality voice, to record the system's various prompt files. The PC I used did not have a sound card, so, instead of VoysSmith, I used the telephone and the VoysAccess Recorder program (written in FoxPro) to record the prompts.
The sample code is heavily commented, so you should not have any problem following it. I do want to point out two superb facilities in VoysAccess and FoxPro that make IVR application development with the VTK relatively painless: the VSpeak( ) function and FoxPro's memo field facility. The toolkit's VSpeak( ) function is number-smart; that is, it can speak numbers properly in context. It can speak numbers normally (123 is "one hundred twenty-three"), numbers as digits (123 is "one, two, three"), numbers as days of the week (1 is "Sunday"), or numbers as money (12.34 is "twelve dollars and thirty-four cents"). To take advantage of this facility, you precede the number with the appropriate number "speak mode," such as DIGITS, DAY, or DOLLARS.
In many other IVR "languages," you would have a disk cluttered with voice files if the application allows callers to leave voice messages. In FoxPro, you can store voice messages in memo fields instead of individual disk files; FoxPro memo fields can store binary data as well as text. If the application supports multiple lines and runs on a network, you can avoid file-contention problems by not recording directly into the table's memo field. In the sample code, I dance around the problem by recording into a cursor (a temporary table, for all you brain surgeons who are not into databases).
You should consider carefully whether there is an overriding business benefit to allowing callers to leave messages. Messages require more attention and they can use a lot of space, so you should impose a maximum recording time. Incidentally, the VTK uses voice files with the .vox extension. These voice files are not the same as .wav files and are more space-efficient.
I should mention that Voysys now also has a Visual Basic version of the VTK that comes bundled with a visual rapid application development tool. Visual Basic is the language of choice for many PC-based IVR development packages.
A nice touch for systems that dial out is the ability to include a voice file of the respondent's name as part of the database record. I'm still experimenting with some text-to-speech commercial offerings and hope to have one to recommend soon.
IVR still has other drawbacks. Unless we reinvent the telephone keypad, people will always have problems dealing with alphabetic input. I think IVR will gain much wider acceptance once we have reliable and inexpensive voice recognition software, so we don't have to rely exclusively on touch-tone for caller input. People like to remind me that this day is already here and offer the telephone company's directory assistance service as proof.
In my hometown of Washington, D.C., for example, you can speak the name of a Washington metropolitan city, and the directory assistance IVR application recognizes it. But you know what? That's not high-tech; au contraire, it is the ultimate in low-tech. There is a real person listening to that conversation and punching the correct button. So why doesn't the person just answer the phone and give out the requested number? Because the telephone company learned very quickly that every city has its share of lonely hearts just dying to talk to a real person, even if it happens to be a directory assistance operator. How boring!