Category: Product

Top level for anything related to the CONVERSANT product and product line

  • Necessity is the Mother of …

    by Dave Schinke

    A first IVR customer was successful, and the Conversant Model 80 IVR product was being marketed to different customers.  A time came when there were several “big” customers, and the number of manufactured machines needed to increase to about 30 to satisfy these sales. Soon, the Western Electric factory engineers were finding that when a cabinet was constructed, it was taking 3 or 4 days to “qualify” a cabinet:  test it, clear any discovered faults, and make it ready to be shipped.

    “We are getting killed on test time.  Is there anything Bell Labs could do to help us with the problem?”   This phrase and question began to circulate in the Dept. and Bob Perdue, my current supervisor, shared the query with a number of us. I’m sure the “hardware” development people were engaged, and what could the “software” folks possibly do to affect the problem? 

    Let me pause the narrative and describe in more detail some of the physical features of the Model 80 equipment cabinet. 

    • The circuit boards were multi-layer “printed” circuit boards, maybe 10” wide by 14” long. They generally had factory level electrical tests that could assure that the individual board was good when manufactured.  Also, the firmware on the board usually had internal self-diagnostics that would operate on each power-up and determine the board was operational, or set a software error condition for replacement.
    • The circuit boards slid into vertical slots on a shelf with guide rails, front retaining clips, and a rear connector would engage with a double row of plated steel pins that were embedded in a “backplane” board.  Each pin went through the board and also protruded out the rear of the “backplane.”  Imagine looking at rows of shiny “porcupine” quills sticking out from front and rear.
    • The interconnection wiring on the rear of the backplane was done with “wire-wrapping” tools that stripped an end of wire, wrapped it on a rear pin, then manually pulled the wire to the desired pin, and stripped, wrapped and cut the other end.  This was a manual, human operation and subject to error.  Further, a “bent” pin on the front side could fail to engage the inserted circuit board, producing another fault.

    The Model 80 software could interact with circuit boards, run internal diagnostics, etc, and fairly quickly locate circuit boards that had internal faults.  But this “backplane” needed visual inspection, which is a tedious process dealing with the “porcupine” mass of pins. And the backplane carried the audible voice signal for 48 channels.

    There is an old saying “Necessity is the Mother of Invention”.  We all kind of scratched around with the problem, but there was no immediately obvious solution that would reduce the testing time.

    “Hey, Roy”, I said as I plunked myself down in a chair in Roy Grubbe’s office.

    “I want a machine that will test itself” referring to the Model 80 machine. 

    “We can make tones, and we can hear tones.  Is there a way to test the voice paths of the machine using its own abilities?”  was my basic query to a fellow staffer.

    Roy wasn’t immediately dismissive of this, as many of the things I proposed had previously been.  Roy thought if we could put a “loop back” cable on the cabinet rear phone connector, we could use a tone generator of one shelf to send tones into the detection circuits of the other shelf. We started examining the wiring diagrams to figure out what voice channels could be covered, if any would be missed, etc.  Each Model 80 had two active shelves of equipment to service 48 phone lines.  Each active shelf had two standard 48 pin telephone connectors. (note: two wires made up a standard phone line.)   By some quirk of the circuit pack arrangement that I have forgotten, we needed two sets of cables to join 2 top connectors to 2 bottom connectors.  One pair of cables joined the connectors in a “parallel” arrangement, and the other joined in a “crossed” arrangement.  We did come out with a tentative wiring diagram for the cables that would provide full coverage of the voice paths inside the machine.

    Roy started thinking about the test software that would run tests, locate problems and print out errors to point to the backplane locations with faults.  Roy was a remarkable developer.  He worked as quickly as he thought.  It all just flowed into executable code. I explained to our Western Electric engineer what we were trying to do, but that we didn’t have the resources to make the cables. He immediately said, “Just get me the diagrams, and I will have the wiring shop make them quick like a bunny.”  And he did get them made quickly.

    This idea of a self-testing machine had become a physical reality. Roy’s software worked and was debugged in rapid fashion.  I started working on the factory floor for several days with the Western Electric test people to get the tests working in practice, get their feedback, and to be the go-between to Roy for software needs, fixes, etc.   I don’t remember how quickly the test procedure stabilized, but it wasn’t very long. 

    The self-testing software reduced the time to qualify a machine from several days to less than one day, and significantly boosted the Model 80 production rate.

    Author’s footnote:  This story was constructed without the use of Artificial Intelligence, just my fingers on a keyboard.  All errors and omissions are mine and mine alone.

  • The Evolution of CONVERSANT

    – from venture startup to core contact center product by Glen Taylor

    I’m not the best person to tell this story.  I came in during a period of transition and was not a key player in the evolution, although I was affected by the winds of change.  However, as I began to build this website, I became interested in understanding the story:  how did the Conversant venture come to be and how did it evolve into a successful product in the AT&T, Lucent, and finally Avaya contact center portfolio.  The following is what I learned.

    In 1982, AT&T had settled an antitrust lawsuit with the US Department of Justice.  AT&T had agreed to sweeping organizational change – the “breakup of the Bell System” – in exchange for some relief that it felt would propel the company forward.  In the 1950s, AT&T had agreed in another antitrust decision to refrain from competing in the computer business.  The result of that agreement was that some incredibly significant computer science innovations, for example the Unix operating system and the C programming language, could not be directly sold by AT&T.  Yes, they were the basis of much of the innovation and development done by AT&T Bell Labs, but they were “hidden” within AT&T’s products and services – the secret sauce.  Since AT&T could not “sell” computers, UNIX and its tools, or the C programming language, they were made available to the academic community for the price of a computer tape and the labor to copy it.  Ironically, by seeding the academic institutions that trained the next generation of computer scientists with this powerful software, it would change the computer business in fundamental ways making Unix and its derivative Linux the dominant operating system.  This “freely available” OS would ultimately displace the commercial offerings of IBM, Honeywell, Burroughs, Data General, Digital Equipment Corporation, and other major computer vendors most of whom no longer exist.  It also initiated the concept of openly sharing significant software source code and is therefore arguably the genesis of the “open source” movement so important today.  However, I digress.

    One of the benefits that AT&T got from the 1982 agreement was the ability to compete directly in the computer business.  It also was no longer just a regulated monopoly.  Oh, it retained its monopoly business, but it could own and operate unregulated subsidiaries.  Hence, the creation of American Bell in July 1982.  The winds of change were beyond gale force on the monopoly telecom business, but AT&T was trying to meet that challenge by becoming more of a competitive, unregulated entity.  In the spirit of that time, someone within AT&T hit upon the idea of creating an internal venture funding unit.  Some of the boundless creativity of the Bell Labs community could be tapped to develop novel products.  Individuals with good ideas could apply for this internal funding and create an “intrapreneurship” – an “internal venture.”  A small business, effectively a startup, was carved out of an existing organization.  The employees remained in their current titled positions within (primarily) Bell Labs or another AT&T entity, but they had a different role getting the venture’s product created and ready for market.  If their effort was successful, AT&T would either find a place in its portfolio to sell the product or it would spin off the venture and retain an equity stake in the business. 

    When I arrived at the AT&T Consumer Products Bell Labs unit in Indianapolis in 1983, there was an existing internal venture that would be successfully spun off in another one to two years.  In late 1985 or early 1986, I became one of about fifteen Bell Labs personnel that began another internal venture.  It wasn’t related to IVR, and it didn’t make it out the door.  However, the reason it failed to launch wasn’t technical.  By 1986, AT&T was undergoing serious reorganization at headquarters.  The winds had shifted direction.  The people involved with venture funding realized that their time was over, and they left AT&T.  Venture funding dried up and all of the ventures, including the one I was involved with, were left to wither and die or fend for themselves.  That was, in part, the reason I joined a cadre of Bell Labs MTS who transferred from Indy to Columbus the first working day of January 1987.

    As mentioned elsewhere, Dean Hester supervised a group in Tony Cuilwik’s department.  Dean’s group was responsible for developing the #2 Service Evaluation System, an operations support system administratively within AT&T Network Systems and designed to do quality sampling of long-distance calls.  Dean’s group contained several individuals that I would recognize as “key players” and “originals” when I joined the Conversant organization in January 1987, but the original work took place around 1983 or 1984.  One of Dean’s top Member of Technical Staff (MTS) was Bob Perdue.  Bob had done an internship in Larry Rabiner’s research organization in Murray Hill, NJ, on signal processing and speech recognition.  The #2 SES was already using some fairly sophisticated signal processing to recognize various telephone call conditions based on the sampled auditory information.  Adding speech recognition capability was a next step, but was something more possible?  One Saturday morning, Dean called Bob with an idea.  Could they build a voice response system that would allow people to interact with it over the telephone?

    Dean was apparently successful convincing Tony, his department head, that he had a good idea.  Dean’s group would embark on something affectionately called a “skunk works” within Bell Labs.  Although they were still supported by their parent organization, they were building something unrelated to their parent organization’s charter but with management approval.  This activity would be called Speech Processing Products.  There was another bright, energetic Bell Labs department head with an entrepreneurial spirit, Kendra VanderMeulen.  How Dean and Kendra began to work together, I have not been able to determine, but they were a perfect pair to move the venture forward.  They effectively became a separate Labs organization with Kendra promoted to be Director (President of the venture) and Dean as R&D Department Head.  Two additional key individuals, Sandra Oliver-Sterbenz and Harry McHugh, would be enlisted to be the head of operations and the head of sales & marketing, respectively.  Kendra would name the unit AT&T Conversant Systems.  The effort moved forward successfully creating the initial product, the Conversant 1 Model 80.  There was significant effort to find some early customers, get trials done, and begin to roll out the product.  That first product was declared “generally available” in November 1985. 

    Conversant was beginning to show promise as a very functional programmable voice response system, what we would come to call interactive voice response or IVR.  There were other IVR systems commercially available, but this was AT&T’s own, organically created product using internal AT&T manufactured components and intellectual property.  However, the path to success was not straightforward.  Conversant Systems was carved out of a group reporting up to AT&T Network Systems, the portion of Bell Labs that supported the AT&T long distance telephone business, the part that would remain regulated.  It was manufacturing a product in the Columbus Works Western Electric facility, but Western Electric didn’t sell to the general public.  There was a market for this technology within the AT&T network, but to be commercially successful as an IVR product, Conversant would need to become widely sold to other enterprises.  The mis-alignment between these factors was problematic while Conversant was being venture funded, but it would become much more problematic when that funding source disappeared.  By the end of 1986, the Conversant Systems’ management and staff were looking for customers wherever they could find them.  It was probably unclear how much longer the Network Systems organization and Western Electric would be willing to “lend” personnel to a project that wasn’t a clear fit.

    Anyone who worked in Bell Labs during the 1970s and 1980s will probably acknowledge the “not invented here” attitude.  A term that usually meant “you may have a good idea, but I can do it better.”  Bell Labs was large and the Bell System larger.  Every component of AT&T and the operating telephone companies, who were now “customers” of AT&T, had needs that could be traced back to some organization within Bell Labs whose job was to support them with products, procedures, etc.  This distributed structure led to considerable duplication of effort.  Even if two organizations recognized that they were each tasked with doing effectively the same thing, they couldn’t easily pool resources and consolidate.  They answered to different corporate management with different goals and timelines.  Add to this the fact that the very bright people who populated Bell Labs and its management had comparably strong personalities and large egos.  All of this led to competition and various forms of in fighting.  Such was the case with Conversant.

    One of the first successful applications of the Conversant product was in the guise of an Outbound Call Management (OCM) system, an out dialing platform used for debt collection.  American Express was a key target customer as were some AT&T business units.  OCM was technically “owned” by an organization in NJ, but was effectively the Conversant Model 80 scripted to do out dialing.  That would create a political tension between NJ and Columbus.  As a result, the NJ organization decided it could build its own platform and do it better.  A group in Middletown, NJ, was creating a voice card they called the Voice Power board that would fit in a PC.  The group who “owned” OCM was planning to use that Voice Power card to create a platform they called the Voice Information System.  There was significant political tension between Columbus and NJ over this.  Kendra and Dean were politically skillful and within a year, the Voice Power card had been transferred to Columbus and Conversant had “absorbed” the Voice Information System effort changing its name to Conversant VIS. 

    Shortly after I arrived in Columbus, my supervisor, Sarbmeet Kanwal, and I would travel to Denver to meet with the voice messaging Audix organization and to NJ to meet with Bell Labs systems engineers supporting AT&T Long Lines Consumer Communications Services (CCS).  At the same time, others in our organization were working diligently to secure a deal with an American Express – AT&T joint venture located in Omaha, NE, First Data Resources – Interactive Technology.  Yes, these were “sales” activities heavily involving the Bell Labs team.  Conversant needed sales and it needed funding support. 

    I would end up being interned to that NJ systems engineering group I’d first visited in early 1987.   I would successfully “sell” them and their CCS customer a Conversant-based architecture for the store & forward messaging service CCS wanted to offer its long-distance customers.  That was the Call Delivery Service project that would become the trademarked AT&T VoiceMark Messaging offer.  This initial deployment of Conversant with CCS would lead to opportunities with Long Lines Business Communications Services (BCS).  BCS had an offering for its largest customers called the Software Defined Network (SDN).  SDN used the public telephone network to effectively provide large enterprises was a private telephone network.   A feature of SDN was Network Remote Access (NRA) whereby the enterprise could issue a special calling card to its employees.  With the card’s authorization code, long distance calls could be charged to the enterprise’s SDN account.  But, BCS had a problem with SDN NRA.  Users could not conveniently make multiple calls in a single interaction which was very inconvenient.  I proposed an architecture that placed Conversant in the middle of these calls enabling it to give callers sequence calling.  This SDN NRA Sequence Dialing project positioned Conversant in the middle of the AT&T long distance network.  We demonstrated that using Conversant we could rapidly develop a network feature that would have required years of development within the Network Systems core network elements. 

    Later, I would also be deeply involved in the application of Conversant technology to AT&T operator services, a project known as Voice Recognition Call Processing that was reputed to have saved AT&T hundreds of millions of dollars annually.  All of these projects are documented elsewhere, but they brought in not only significant CONVERSANT sales but “work for others” funding from the parent AT&T organizations that paid for our efforts in Columbus.

    Although Kendra and Dean had success navigating the political waters, creating a product that would be an industry leading IVR, their hold on the product was slipping probably as early as 1988 or 1989.  It was becoming increasingly clear that the future success of Conversant could not depend on internal funding and internal AT&T applications alone.  It needed to be sold to enterprises and it needed to fit into their contact center infrastructure.  That meant that the product needed to move from Network Systems to Business Communications Systems (not to be confused with Long Lines BCS division). 

    Starting in the mid-1980s and following a timeline similar to the one outlined here, Business Communications Systems (soon to be called Global Business Communications Systems or GBCS) had grown up.  As a regulated entity, AT&T owned the telephone network and the switching systems that directed network traffic.  Large enterprises, however, had enough internal telephone stations that they justified purchasing and operating their own small switches, the private branch exchanges or PBXes.  As call volumes into businesses grew, so did a structure for dealing with those calls, the call center.  A PBX would include automatic call distributor or ACD software that directed calls to different functional groups answered by separate pools of agents.  In order to give some sophistication to the distribution of calls, the PBX ACDs had developed the ability to play simple messages, collect a touch tone digit, and based on the caller’s input, direct the call appropriately.  Although these ACDs could do this simple call routing, call flow configuration was awkward and limited.  To provide more sophisticated interactions with callers, an IVR platform was required. 

    By the mid-1980s, AT&T’s two flagship PBXes, the larger System 85 and the smaller System 75 were “competing” with each other.  System 75 development was primarily in NJ with System 85 development primarily in Denver.  Each platform and each development group had unique strengths and features.  The resolution of that competition would be a joining of forces and the declaration of a new combined switching platform, the Definity series.  Initially, that was just a renaming.  Definity G1 was just a System 75 renamed, and Definity G2 was just a System 85.  It would take some time before the actually merged Definity G3 emerged.  GBCS was the AT&T corporate entity that provided product management direction to this line of products and was incorporating related technologies used in the call center.  Those would include reporting with the Call Management System or CMS, voice messaging with the Audix system, and eventually IVR with the Conversant system.  However, our story hasn’t gotten there yet.

    By 1989, the political pushing and shoving to realign Conversant, wresting it from Network Systems and aligning it with GBCS, was taking place at higher corporate levels.  The concept of Conversant as an “internal venture” was effectively at an end.  It would be a supported call center product, but not as a small separate business unit lodged somewhere in the larger corporate structure.  The business aspects of the Conversant venture – product management, marketing, sales, manufacturing, and support – would all be realigned.  The GBCS product management organization, primarily located in NJ, would become Multimedia Messaging and Response – a combination of voice messaging with interactive voice response.  Marketing would move to the corporate level.  Sales would become the province of the AT&T GBCS sales teams who sold the Definity switches, the Contact Center Elite ACD software, the CMS reporting product, the Audix voice messaging product, and now the Conversant IVR product.  Manufacturing would remain partly in Columbus, but much would be moved to the Denver Works.  Support for the product would migrate to the GBCS support organization located in the Denver area.  The realignment within Bell Labs would be to combine the Audix development department in Denver with the Conversant development department in Columbus under Dean Hester’s then Bell Labs director, Charlie Del Riesgo.  There would be more evolution after this point but the movement from a Bell Labs “skunk works,” to successful “internal venture,” to GBCS call center product was effectively over.  Before Charlie became the Conversant Bell Labs director, Kendra had departed becoming the director of a different Network Systems Lab in Columbus.  Dean would soon move to take a different department in Network Systems.  Conversant would be a GBCS island within the Columbus Network Systems Bell Labs location.  In Feb. 1991, Charlie Del Riesgo retired from Bell Labs and moved to Cincinnati Bell Information Systems in Cincinnati.  Kendra and a number of other managers and MTS would ultimately follow, but that’s another story.

  • TSM:  An Origin Story

    by David Schinke

    I joined the Columbus laboratory in 1979, by transfer within AT&T.  Dick Machol was the Dept. head and my supervisor was Dean Hester. During an interview I was shown the west-side lab with DEC VAX 11-780 computers, washing machine sized disk storage units, and terminals arrayed on several tables in a glass separated space. Such was the state of computing in 1979.  Remote terminals in a person’s office came later.  Our assignment was No. 2 SES (Service Evaluation System) that was computerizing the human task of evaluating the completion of calls on a random basis. The regulated monopoly communications service company, AT&T, was very concerned about providing good service and voice quality to customers.  (How quaint?) I learned “C-code” and completed an AT&T sponsored set of in-house Computer Science courses.  Memory is dim, but I think the No. 2 SES system consisted of task-designed hardware in a tall cabinet and possibly also a VAX computer.  The hardware could attach to analog phone lines (maybe also T1?), listen to the sounds on the line, interpret sounds like RING, BUSY, REORDER, completion, and presence of voice, then cut-off within a time limit.  Completion statistics were compiled and reported to the operating telephone company.

    In the early 1980’s, significant legal change came to the Bell System.  The operating telephone companies were separated from AT&T who kept the provision of long-distance services.  A little-noticed side effect of this court order was that AT&T was no longer required to offer its patents and ideas to the public at a fair rate, and could generally enter unregulated markets if it chose to do that.  Well, we had hardware that could interact with analog and digital phone lines and, using Digital Signal Processing, “listen to” tones etc. on the line.  It could play out pre-recorded speech files.   How about Interactive Voice Response as an unregulated market that could be entered?  Customers could place a call, a computer could speak recorded phrases to them, they could select things by pressing Touch-tones and hear strung-together recorded voice responses with the desired information.

    Jumping forward, our department developed the “Model 80” IVR system.  The cabinet was taller than I was, and weighed several hundred pounds with redundant power supplies, etc. The software was written in “C language” and ran on a UNIX operating system.   A single cabinet could handle up to 48 voice lines, either analog [tip-ring in the nomenclature of the day]  or digital [T1, @ 1.544 mbits/sec with an equivalent 24 voice lines].  It also had an external data interface to interact with and to provide/obtain information from our purchasing customer. This entire cabinet could run ONE, SINGLE voice response “script” (the sequence of customer inputs and speech outputs) on any or all of the incoming lines. Memory is dim, but I think we programmed the voice response transaction in “C”.  

    Is there a way to provide more than one “IVR service script” on this hardware?  Then our purchasing customer could group a subset of the phone lines for one service, and have another service applied to another group.  The digital T1 interface provided the “called number,” which is the destination number called from the phone network. This number could be used to decide which “service script” to provide to a caller.  Noodling around with this idea, the concept of a “State Machine” seemed like a possible way to deal with these multiple service scripts.  A state machine could keep track of which script was started on an incoming line, and where it was in the script [its state].  I went to the lab one afternoon to talk with Roy Grubbe and Cliff Perkins about what information came up from the hardware.  After some discussion we agreed that all the incoming hardware interrupts contained enough information to “drive” a Transaction State Machine, and that it did seem “possible” to construct such a thing in software.  Toward the end of the conversation Roy Grubbe slapped both hands down on his thighs and said “Lets Do It!”

    Realizing that this was more work than could be done on a “Friday afternoon,” Roy and I went to our supervisor, Dean Hester, with the idea.  After some discussion he said “Write me a memo about what you want to do so I can allocate some resources.”  I wrote a memo with Roy Grubbe as a co-author called “Transaction State Machine.”   Mainly the advantages of running multiple things, but not very detailed in HOW it would be accomplished. Well, Dean let us get to work with Cliff Perkins to produce a “reduction to practice” of the concepts and make a demonstration system.

    Roy Grubbe and Cliff Perkins wrote the state machine software to interface with the Model 80 hardware. I started working on a way to script the transaction. We thought about an assembly style language that had a few commands and control statements.  After all, an IVR transaction is just answering the phone, “talking,” “getting some digits,” maybe interacting with a “back-end” on-site customer data base, and hanging up.   How hard could it be?  How many commands do you really need to run an IVR?  Do you really need the idea of a subroutine? [YES]  Cliff wrote a compiler to take the “pidgin assembly language” script into a file that would run on the TSM.  This was called TAS [Transaction ASsembler].

    With apologies for hazy or enthusiastic memory, I think it took about a month or 6 weeks to get to a demonstration of two phone calls with different speech databases and sequences running independently on the same machine. We asked Dean Hester into the lab to dial up on two different phone lines and do the interaction with each.  Afterwards, he smiled and said “Very good.  Where do we go from here?”. 

    This is the TSM origin story as I remember it. It grew in complexity and features, but retained the “channelized” idea and was able to support the needs of the product for a number of years.