AT&T CONVERSANT

Category: Enterprise

Related to the commercial projects and impacts

  • The Holy Grail

    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.

  • Conversant and Katz

    by Glen Taylor

    To anyone who worked in the contact center and IVR space during the 1990s and 2000s, the name Ronald Katz or the term “Katz patents” probably jumps out like a curse. Katz’ organization Ronald A. Katz Technology Licensing (RAKTL) activities have been described as shark-like or bottom feeders. RAKTL owns a collection of patents that it licenses to companies, primarily large wealthy companies. A substantial group of those patents cover some very basic IVR applications. RAKTL’s actions to sue or threaten suite against companies that fail to license the RAKTL patent portfolio has been likened to legal extortion. What does all this have to do with Conversant? A lot, actually.

    Ron Katz co-founded a company called Telecredit, Inc. that later formed a partnership with American Express as First Data Resources, headquartered in Omaha, NE. In the late 1980s, First Data Resources partnered with AT&T to create, First Data Resources – Interactive Technologies or FDRIT. The “FDRIT Project” would be a large & formative project in the early history of Conversant.

    About a thousand ports of Conversant IVR were installed in Omaha, NE. FDRIT had a contract with the National Football League to hold a real time telephone survey quiz during a Monday Night Football commercial break. Almost the entire Conversant organization in Columbus was mobilized to support the effort. A huge number of racks of Conversant platforms each supporting two T1s or 48 ports were installed in Omaha.

    As this project was underway, Katz became familiar with the Conversant and its applications. How much familiarity he had with IVR platforms prior to his Conversant exposure is unknown to this author, but he promptly developed patent applications for several key IVR applications such as his patent US5128984 submitted contemporaneously with that Conversant project.  This patent describes in its abstract the use of an IVR application reached via an 800 or 900 number service to provide a quiz or survey — exactly what the Monday Night Football project entailed.

    Katz would go on to propose “inventions” which the Conversant team would have to point out weren’t really patent-able since they were already implemented features of the Conversant platform.  In fact, his “IVR application” patent ideas were not novel either.  This led to some friction between Katz and the Conversant team.  Eventually a truce was reached.  Katz would refrain from trying to submit patent applications for the features already in Conversant, and the Conversant team would not actively oppose Katz’ patent applications for “IVR application” concepts.  This led to a smoother trajectory for the project, but may have contributed to later misery within the marketplace.  Most of the Katz patents could probably have been successfully overturned based on existing prior art, but there was no will to engage in that activity as long as Katz wasn’t coming after AT&T and Conversant.

  • Another Use of Callback

    by Glen Taylor

    Gene’s posts have given us an interesting application of “callback” in his International Callback application.  However, a slightly different use of the term callback has been one of the most frequently implemented IVR applications within contact centers.  I have a long history with callback that I’d like to share. 

    Many companies have created a productized version of a callback application, including Avaya professional services.   Probably every ISV has written a custom version at one time or another or sell a callback application product.  In 2000, when I moved from helping to develop the Conversant product to trying to sell it, I was often involved with sales opportunities where the customer wanted “callback” for their contact center.   After a few of these, I was a bit frustrated and wrote a whitepaper with Avaya and Avaya business partner sales teams as my audience.  It was entitled Why Your Customer Doesn’t Need Callback.  It would be ironic that within a few years, I’d be working for Interactive Northwest and deeply involved selling their excellent callback application.  Two things can be true at once.

    My original paper started with the thought that “No one calls a business to get a callback!  They call to get a problem solved.”  That is a true statement, and I’ve never wavered in my commitment to it. What prompted my whitepaper was exposure to countless customers who were woefully understaffed, had foolish contact center designs (skills), or both.  The result for many was that queues filled well before the daily call spikes, callers began to experience longer and longer hold times, and call abandons increased to match.  Their callers were not happy customers.  Obvious to me was that “we” (the telecom sales professionals) needed to help “our customers” understand how to segment their callers better, how they might change their call center design to staff more effectively, and provide them with the best possible voice self-service options.  Get the callers served the first time as quickly as possible.  That was the real reason to implement IVR.

    At that time, I truly believed that callback had no positive value.  It put a small band aid on a bad situation and improved caller satisfaction negligibly.  That changed when a customer showed me the light.  What was most embarrassing was that I am trained in psychology.  My focus has always been directed toward improving customer experience.  My customer stated that he wanted a callback solution to “put his callers in control.”  There it was.  Give callers the option to wait and an estimate of how long and they could choose.  This moves the caller from victim to empowered participant.

    Now I could sell callback and mean it.  Oh, I still counseled customers as to whether they should use callback or not for a particular skill.  I made sure they understood the staffing concerns.  I pointed out when it might actually “solve” their problem or simply “push it out in time.”  I learned that callback is a fairly complex, multifaceted tool.  There are cases where it helps and where it cannot.  Over time, the voice self-service component, which was a major point in the early days of IVR, diminished.  Most self-service is now done via other media.  That’s both partially alleviated and exacerbated the need for appropriate callback.  When a company’s customers call today, they have probably exhausted all other options.  They need to reach someone who can listen, understand their problem, and resolve it.  Even after four decades, IVR and callback applications are important tools.  Skill and thought are necessary to use them most effectively, but their value remains.