Although the Conversant product line began as CONVERSANT 1, it would undergo continuous evolution. Platforms carrying the Conversant name became available in late 1985. (see Columbus Dispatch article.) Versions of Conversant would be sold until October 4, 2004, the final End of Sale (the point at which Avaya would no longer sell components for existing systems). Avaya ended support for all Conversant versions through its last R9 version on June 30, 2007. The UCS1000 platform (which had been incorporated into a few other products) itself was supported until Oct. 4, 2008. This amazing product line enjoyed a twenty-two year lifespan.
To understand what made Conversant such a significant force during that period of the telecom industry, it is helpful to know some of the unique aspects and contributions of the product.
Platforms & Circuit Packs
Conversant evolved at a time when telecommunications platforms were hardware based, proprietary designs that were deployed on a customer’s premises. Because Conversant descended from a system designed for the core AT&T network, it would continue to pursue applications within AT&T and the Bell operating companies as it sought widespread acceptance in the commercial marketplace. This would influence the platforms and platform evolution.
The “platform,” the physical configuration and the core computing elements, would evolve, but much of the key engineering work done by the Conversant team lay with the specialized circuit packs that it created.
Part of the success of Conversant was directly attributable to its unique software architecture. Bell Labs had given birth to the C programming language and Unix operating system. It also had a history of devising highly reliable, efficient applications that used their underlying components to maximum effect. These two strands would be interwoven to produce a platform that consistently over its lifetime would wrest as much capacity out of the available hardware as possible.
By the 1980s, all telephone switching platforms were effectively “specialized computing platforms.” However, telephone switches (long distance toll switches, local central office switches, and corporate private branch exchanges) were not general purpose computing devices. A PBX switch and the contact center application that might run on it were preprogrammed “applications.” It was possible to “configure” how incoming calls might be handled but there was little real flexibility. If an enterprise wanted to provide more than simple announcements, wanted to do even simple interaction with the caller, or wanted to satisfy the caller’s request without delivering the call to a person, that required a separate “adjunct” — an IVR platform.
Thus, IVR platforms like Conversant had to be programmable telecommunications devices. That implies that they had to support some form of programming language and application development tools. Conversant’s Transaction Assembler (TAS) was the programming language and ScriptBuilder and Voice@Work would be its development tools.
When the IVR industry embraced a “standard” programming formalism, VoiceXML, Conversant would add support for VoiceXML but the platform hardware wasn’t robust enough to provide the high port density available via the native TAS. Efficient use of VoiceXML would require the next generation of IVR platforms.
The direct precursor to Conversant was the #2 SES project. The need to analyze phone connections, analyze tones, and make determinations led directly to the “call classification analysis” feature of Conversant that was one of its core attributes. Basic tone analysis led directly to interest in more complex analysis — specifically recognition of spoken utterances. Conversant’s engineering team had established relationships with the Bell Labs speech researchers. These relationships would blossom. The researchers produced “interesting” algorithms, but it would be Conversant developers who would refine and efficiently code these algorithms for production use.