AT&T CONVERSANT

VARnish Can Crack

Written by

amdpschinke76

in

,

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.

Comments

One response to “VARnish Can Crack”

  1. glentaylor47 Avatar
    glentaylor47

    Dave’s story introduces an important part of the overall “Conversant story.” Although we did typically refer to these 3rd party companies as VARs early in CONVERSANT, later nomenclature was primarily ISVs – Independent Software Vendors. The two terms are distinct with significant overlap. VARs typically were AT&T “resellers” who directly sold AT&T services and products to their own customers. Some had in-house development & technical resources that made them suitable development partners that could support AT&T sales teams. However, the primary sales dynamic that would emerge would be AT&T sales people would find and “close” the deals, but AT&T didn’t have the professional services capabilities (in sufficient quantity) to support all of the sales that were desired. It was necessary for AT&T sales people to bring along a technology partner. These were companies that specialized in software development and delivery – Independent Software Vendors.

    The ISV didn’t have to have a direct sales relationship with the end customer before being engaged. The AT&T sales team had the relationship. They had to identify the opportunity and then engage the resources needed to develop a solution and “sell” it to the customer. Most AT&T sales teams had to have a VERY broad knowledge that covered many different AT&T products and services. Consequently, they were seldom that familiar with the individual products in great technical depth. CONVERSANT, like all IVR products, was a particular technical challenge due to the complexity of the sale that Dave mentions. AT&T would actually develop “sales specialists” who were deeply trained on the complexities of IVR sales that would augment the direct sales teams, but there still had to be the resources who would take the job to completion after the sales team’s work was done.

    The ISVs typically filled that last need. Most ISVs had resources that would engage with the sales team during the solution discovery and sales process, write the Scope of Work that would accompany the product quote, and develop a “wholesale” price that AT&T would mark-up and include in the final order. Then the ISV’s technical staff would project manage, develop, test, and deliver the solution. This process would develop into a well executed ISV Program starting in the early 1990s and continuing to the present day supporting the current Avaya IVR products. By the mid-1990s, the number of ISVs “officially” supported ranged from 10-12. A number of them were formed in Columbus, some from Conversant staff that left and formed their own companies as well as other entrepreneurs usually with some connection to AT&T that chose to work with the Conversant product. As Dave mentions, the ISV companies were scattered geographically from the East Coast to the Midwest to the West Coast.

    Dave’s story also touches on another topic that would come up over and over through the following decades. This was the status of “foreign” items incorporated into the Conversant platform. As Dave points out, adding non-AT&T (or later Lucent/Avaya) hardware was problematic. Fortunately, it was very seldom at issue. The addition of other software packages to the Conversant’s Unix operating system would be the more frequent issue. Could you or couldn’t you? That would always be an “interesting” question.

    On the one hand, AT&T/Lucent/Avaya always wanted to control the configuration. In some sense, it was responsible for ensuring that the platform “worked” as advertised. Customers expected to be told what their purchase could do and then hold AT&T/Lucent/Avaya responsible for it. If the customer alters the platform, the company was placed in a awkward position. It couldn’t guarantee things that it didn’t know about. In fact, it was difficult enough to tell customers what the platform could and couldn’t do even when there was no alien introduction. How the customer wrote the voice applications, what features were used on calls (ASR? local database activity? TTS? etc.) all affected the system’s performance. The number of simultaneous calls the system had to handle mixed with the complexity of the applications was difficult to specify. Add to that completely unknown hardware and software and all bets were off.

    However, the customer purchased the platform. The customer owned it. You can’t sell someone a car and then prohibit them from driving it down certain streets or hanging fuzzy dice from the rear view mirror. You might advise against these, but the customer owns it. The difficulty comes from how much responsibility you have once a customer insists on making modifications. Eventually AT&T/Lucent/Avaya would adopt something called “permissive use.” The company would permit a customer to add to or modify the platform provided that they understood that doing so might affect the performance. If things worked then fine, but if they subsequently encountered any problem the company wouldn’t immediately agree to fix the problem. First, it would troubleshoot and try to determine the cause. If it suspected that the customer’s modification was involved in ANY way, the customer had to remove the modification. If that didn’t fix the issue, then the company would continue to troubleshoot and resolve. If the troubleshooting and resolution could be accomplished with the modification in place, then fine. That sounds reasonable in theory, but in practice a customer that modified the platform was asking for more trouble since every routine hiccup would cause a painful back & forth over the alien addition.

    Reply

Leave a Reply

More posts

Discover more from AT&T CONVERSANT

Subscribe now to keep reading and get access to the full archive.

Continue reading