by Glen Taylor
Soon after my arrival in the Conversant development organization in 1987, there was a bit of a crisis. A relatively new entry into the IVR field, Syntellect, was capturing market share with its “voice robot” application scripting tool. I no longer remember the marketing name, but it was effective. Conversant at that time had to be “programmed” in the TAS language. Although my engineering colleagues felt it was simple enough to create a voice script with TAS, doing so was much less than obvious unless you were already a decent programmer. Thus, we embarked on our quest for the holy grail.
We began a development activity to create a “high level” scripting tool that would be so easy and intuitive that the “knowledge worker” could program his or her own application flows. The “knowledge worker” was assumed to be someone involved with the contact center. This might be a telecom technician or contact center supervisor who understood what calls were arriving at a particular number (DNIS) and what should be done with those calls. Using our new tool named ScriptBuilder, this knowledge worker would “merely” describe the flow of the call using a text “outline” and the tool would turn that script into the Conversant voice application. Nothing to it.
Exactly what a “knowledge worker” needed to know and how that should be supported in ScriptBuilder was open to debate. My good friend and colleague, Steve Riederer and I, were the two systems engineers / human factors specialists charged with designing the features and interface of ScriptBuilder. Steve and I had some serious discussions and conceptual disagreements. Steve’s position was that we shouldn’t assume that the person using ScriptBuilder would be a trained programmer but only someone who understood the basics of how a call should flow. I took the position that we were really creating a tool that professional IVR developers would be using and therefore should adopt all of the programming conventions needed to make it a “complete” high level language for Conversant. The result was a compromise. Steve, who was primary on the basic design of the ScriptBuilder textual interface, agreed to include sufficient programming constructs to make the “language” complete, but omitted a number of the constructs that I’d proposed. I would be primary for the portion of the tool that captured IBM 3270 “green screens” and allowed them to be defined and used within the application.
With several decades of hindsight, I feel that my view of the place of ScriptBuilder in the evolution of Conversant may have been a bit more correct, but the tool proved remarkably useful. What did not happen was the holy grail. Few customer “knowledge workers,” individuals with no previous programming background but knowledge of their contact center, picked up the tool, created their own Conversant voice applications, and supported them. ScriptBuilder became the main tool of every professional IVR development shop that supported the Conversant ecosystem. The customer “knowledge workers” who did become fluent in ScriptBuilder taught themselves or were taught how to program in ScriptBuilder. It was fundamentally a programming tool, and its users had to think like programmers.
Having remained directly in the IVR business now for nearly forty years, I’ve had the opportunity to watch this “search for the holy grail” go on year after year, decade after decade. We in the Conversant organization took a second swing at it with the Voice@Work tool. This replaced the character-oriented user interface (CHUI) that was required of ScriptBuilder given the platform of the time with a graphics-oriented user interface (GUI). This moved IVR application creation off the Conversant platform itself and onto a Windows desktop. All subsequent scripting tools would continue to be visual GUI tools. When the underlying scripting formalism moved from proprietary languages such as TAS to an open standard such as VoiceXML, Avaya first sourced a graphical tool from a UK company and then created its own tool, DialogDesigner. Without fail, the big marketing message for DialogDesigner was “so simple you can build your own applications.” Avaya sales people would proudly demonstrate to a customer in a fifteen-minute presentation how easy it was to build an entire VoiceXML application from scratch. I was never very comfortable doing these because I knew the “little white lie” behind it, but a number of my sales colleagues were quite skilled at these demonstrations. Yes, it was easy to build a very simple application with no error handling in a few minutes. However, production quality IVR applications are much more complex with many error paths that must be handled. DialogDesigner was a nice set of pre-built tools inserted into the Eclipse Java integrated development environment (IDE). All of the professional development organizations that built serious applications for the Avaya IVR platform, by then the Voice Portal platform, used it. But it wasn’t really for the “knowledge worker.”
The holy grail, the idea that anyone can have any application that they need simply by “describing” what it should do, has moved beyond this narrow IVR world. Anyone who has heard of “conversational AI” may be familiar with tools such as Google DialogFlow. DialogFlow is, in fact, an IVR flow tool although it began as a way to script text chat interactions but can be easily converted to voice flows. The tool itself is as difficult to “program” as most of the tools I’ve mentioned although it has some basic features that are quite an enhancement over earlier methods of building “speech enabled” flows. The space of conversational AI tools has blossomed with dozens of offerings.
The evolution of software more generally has begun to talk of no code (NOCO) and low code (LOCO) applications. The user “simply assembles” his or her application by putting together pre-built capabilities with little or no programming “glue” (LOCO-NOCO). The emergence of AI large language models (LLMs) has made this seem eminent. A modified version of something like ChatGPT will just take the knowledge worker’s description and build the application. Voila, the holy grail achieved.
For an old fossil who’s lived through the Cretaceous to the Carboniferous ages of IVR, achieving the holy grail doesn’t seem possible. I have no doubt that we’ve reached a point where a knowledge worker can give an AI generation tool a description of the “desired flow,” but I’m not certain the result will be the holy grail. Fundamentally, a description must be sufficiently precise to achieve the desired result. It must also take into account all of the error paths that are most likely to occur and how those should be handled. It will need some elegant way to handle the errors that were not described. Finally, it will need to be tested to ensure that all of these aspects are correctly represented and work as intended. Fundamentally, that’s “programming & testing” an application. AI tools may make that easier and easier, but I still believe that a human, thinking like a programmer, will be the final check.
