AT&T CONVERSANT

Category: History

  • The Early Days of the Conversant Venture

    by John Moosmiller

    I joined Bell Labs in October, 1983 (a year after Chemical Abstracts graciously funded my Masters in CIS). I think the “official” internal venture approval came a few months later. The public venture launch was in San Francisco in September, 1985. Almost immediately when I joined in 1983, I was assigned by Dean Hester to find trial sites for speech recognition transactions that could work robustly over limited bandwidth telephony networks. Bob Perdue will recall the focus on keyword recognition and the use of error-correcting catalog code numbers.
     
    I cold-called Fortune 100 R&D executives and found that doors opened in many cases by merely saying I was in a Bell Labs research project that would revolutionize the human-computer interface using computational linguistics and natural language processing.*  Some of the most memorable trips Dean and I made in early 1984 or thereabouts were to LLBean (then only one store and factory in Freeport, ME), a phone-in, drive through grocery store start-up in Los Angeles, and Fidelity Investments in Boston that ultimately did lead to a successful trial. It was exciting and exhausting to be prospecting for customers before we had a marketing organization.
     
    Dean was tightly wound and by nature an introvert, but he had a vision and could intellectually override his nature to achieve his ends. On long airplane rides, he would unwind by listening to the BBC RADIO dramatization of the Lord of the Rings (1981) on his Sony Walkman.**
     
    * The late Gene Rissanen and Bob Perdue got US Patent #5003574A for a “voice capture system” that had these possible applications. 
     
    ** That BBC LOTR adaptation was quite good with Ian Holm as Frodo, Michael Hordern as Gandalf, and Bill Nighy as Sam Gamgee.

  • VARnish Can Crack

    by Dave Schinke

    V – A – R were three letters that stood for “Value Added Reseller.”  Conversant IVR products were not “invisibly buried in the Network” but were “high touch” products that end customers had to have programmed to suit their individual needs.   To sell an IVR product, you had to know the customer’s needs, what information they wanted to provide to their callers, and how to interact with their databases.  Then, it was necessary to plan the automated dialog, record speech phrases, write a script for the machine to “speak,” interface with the customer’s database for information to “speak,” and determine when they would like a caller transferred to a live agent.  All of these things had to be integrated, installed on the customer premises, and made to operate to the customer’s satisfaction. 

    The Marketing part of Conversant decided to expand the reach of our IVR products by partnering with small companies distributed around the country that were “close to the customer,” that would be able to handle this work, and AT&T would sell the equipment, but have minimal involvement with fulfilling the end-customer’s needs.  In the early days of developing the group of VARs, Marketing would have one of us from the “software” side travel with a Marketing person to meet with a prospective VAR.  We could discuss both the business and technical issues and make some judgments about how they would fit into our general plan.

    One early VAR I visited with Marketing was located in Massachusetts.  They weren’t in downtown Boston, but likely on the “technology ring” around Boston.  I have forgotten the name, but maybe “Hager Telecom”?  He had several capable programmers, an ability to install and support equipment, and even a small “sound-proof” booth for recording speech.   Looking back, he was probably already selling IVR products produced by other companies.  I think this company was added to the VAR group, and my involvement ended. 

    Time passed, this business model worked, and the group of VARs significantly added to the growth of Conversant. I did not have any more personal involvement with the above company, so what follows may or may not be true, but “It makes a good story”.

    Conversant had a proprietary data bus that could move digitized voice signals from card to card within the system.  There was talk “around the coffee pot” that a VAR had a person “reverse engineer” this data bus protocol and was trying to connect a card that the VAR had developed to the “inside” of our systems. The purpose of this card is lost in the mist of my memory.  I’m sure our hardware people told the VAR that “YES, this data bus is the property of AT&T and AT&T wants to control the hardware environment” and “NO, we don’t want to have third-party cards inside the Conversant System.”   Marketing probably told this VAR the same thing: “YES, this is ours” and “NO, we don’t want yours in the box.”

    But this VAR was persistent in pursuit of his vision of “What a neat system it would be if only….”.  One day “talk around the coffee pot” was that this VAR was coming to Columbus to have a face-to-face conversation with Kendra VanderMeulen, who was at the apex of our development and marketing organizations.  Kendra was no “shrinking violet” and had successfully guided the growth and expansion of Conversant.  The meeting was held.  I’m sure Kendra said some version of the above “YES and NO” statements already transmitted to the VAR.  What more was said or how it was said, I don’t know. But this VAR was persistent in pursuit of his vision of “What a neat system it would be if only….”.    One day “talk around the coffee pot” said that LAWYERS had become involved on both the AT&T side and the VAR side.  The topic of this VAR became very quiet in “talk around the coffee pot”.   How it all played out, I don’t know, but I observe that we never did have a card AT&T didn’t make connected to the voice data bus in the Conversant equipment.  End of Story.

  • Monday Night Football – Initial Installation

    by David Schinke

    The Monday Night Football IVR application was going to be BIG.   The customer, First Data Resources-Interactive Technologies or FDRIT, wanted to use a TV advertisement during the half-time of an NFL Monday Night Football game to stimulate people to call in.  Callers could answer a question and potentially win a prize.  I was not involved in the development of the application, or part of the Marketing/Sales process.  My participation came at the point of installing the first tranche of equipment on a customer site in Omaha, Nebraska.   But more about that a bit later.

    “How many phone lines do you need to service incoming phone calls?”  This was a question that Conversant IVR products faced throughout their existence.  AT&T had worked this problem of “traffic engineering” for a long time, mostly based on how to provision network switching, transmission and customer premises PBX equipment. How many lines you need depends on the duration of a call, e.g. how much time, on average, this type of call takes to complete. It also depends on when the calls arrive at the destination equipment.  Much of traffic engineering assumes random arrival times for calls following a Poisson distribution.  There is a mathematical formula developed by a Danish telecom engineer named Erlang that computes the number of required ports based on two input quantities, total volume of calls expressed in a unit called Erlangs and the acceptable percentage of calls to be turned away (“busy signal”) when that maximum load is reached.  This Erlang B formula is his primary accomplishment in this area.   

    In early customer applications, we sort of looked at some AT&T graphs, took a SWAG  (an acronym for something unprintable in polite company) at the call durations, and offered the customer our best guess-timates.  Follow-up with the customer’s real experience helped to answer the question but customers always wanted to know ahead of time.  I am not a traffic engineer, and Dave Shain (one of our systems engineers) upbraided me for providing guess-timates to a marketing person.  Dave Shain brought valuable traffic engineering expertise to Conversant.

    The Monday Night Football IVR application was going to be BIG.  AT&T was going to have to provide a substantial number of T1 digital trunks from the central office that served our customer.   The final configuration would be about one hundred Conversant 3 “boxes” each supporting four T1 connections.  This is just short of 1,000 telephone connections!  It was decided to begin on the customer site with a small amount of equipment, some connected to the customer’s PBX, some connected directly to a small number of T1 trunks.  We would also connect the “back-end” to the customer’s computer and verify that connection.

    At this juncture, I had a reputation within the Dept. as “good with the customer” and “good with managing an installation”.  So, a “hardware” person and I (a “software” person) went to Omaha to install the first tranche of equipment.  I do not remember the line configuration, but I had some lines connected through their PBX and some direct T1 trunking.   We did the usual drill of unboxing, arranging, mounting, and connecting equipment, starting up, loading software, checking-out hardware etc.   Now it was time to “place a call,” which we did with a desk phone and “onesies” to each cabinet of equipment.

    It was almost lunchtime, but this application would call for a heavy call load.  How to be sure that the Conversants and the network trunks could handle it?  Well, let’s just use one machine to test another.  I had enough lines to load a T1 incoming trunk so I set up outgoing calls on 24 lines, and could place one incoming T1 trunk in service.  Maybe two T1 trunks at a time for a total of 48 calls out and 48 calls coming in; I don’t remember.  We “blasted” the network for about a half-hour to 45 min and verified end-to-end load capacity on all the equipment.

    About 1:30 p.m. a customer technician we were working with came in and asked “Did you guys do anything in the last hour?”

    “Yes,” I answered, explaining that we wanted to verify end-to-end performance for each trunk.

    “That explains why people were having trouble making calls and getting incoming calls over lunch hour!” he said.

    Through negligence, I had overloaded the customer’s PBX equipment and disrupted their phone service for the better part of an hour.   I was very apologetic, stating that, “ It doesn’t have to be done again, and we are surely very sorry for the disruption.” The customer was somewhat understanding, although it did get mentioned to our management with no serious repercussions.

    On a personal note, when it came time for the second and larger tranche of equipment to be installed, I asked to be relieved of the task of managing the installation.  Perhaps I felt badly about disruption of customer service, perhaps I was simply tired of the travel, hotels, being away from family.  I don’t clearly remember the reasons.  Management agreed, enlisted Larry Whitacre for the task, and I didn’t do this type of work again until the voice messaging service application was installed in Jacksonville, FL.