Category: Impact

Top level for main projects and accomplishments related to the Conversant.

  • My Time with Conversant

    by Todd Mason

    I joined the Conversant project in 1986.  I had recently turned 30 years old with a growing family of four.  I left Motorola, where I was selling data entry and word processing systems.  I got the Conversant job through a headhunter, which was a first for me.  Chris Farrar was the hiring manager.  My interpretation of the role was to offload the Product Marketing from Bell Labs personnel, who had much better things to do than sell stuff.  It was a great concept, but it took time to fully remove the Bell Labs staff from the game, plus some of them kinda liked it.

    Chris hired Brad Menard (RIP), Diane Parks, and myself for this sales role.  We shared a window office at the front of the building.  We all smoked (you could back then).  It wasn’t pretty.  We had our own little airport smoking lounge.  We had a division of “territory”, with Diane and I in the Commercial space, aligned with traditional AT&T sales branches across the country.  Brad had the Network side: AT&T subsidiaries, telcos, Bell companies, etc.  Marketing material consisted of a couple of glossy handouts describing the T1 board and the “rack” they resided in.  It was a technical specifications sheet, not marketing material that your typical phone salesperson could use in conversations with clients.  This is not a criticism, more the state of infancy the product life cycle was in.  “Skunk Works”

    We traveled a lot in the beginning, dragging quite a few with us at times.  The role in the beginning was twofold.  Chase anything of reasonable interest, and while you are there, educate the sales force.  We did branch educational training everywhere we went.  That demanded materials, different from tech specs, i.e. applications white papers, cost benefit analysis, customer testimonials.  We created a training binder over time and eventually a class to train Branch Specialists at our facility.

    We had a couple of early wins, Bank of America, and Voter Research & Surveys.  These two clients became great references for us as the product evolved.  As the product demand grew, and the Branches grew comfortable, our roles evolved.  Chris moved on, and we got aligned with Branch Sales regions for a bit.  Some of our folks moved into these Branch Specialist roles: Ken Searles, & Denny Mahle.  I came back into an OR&M (Offer Realization and Management) role in 95ish, leaving in 1996 to manage the VRU team at AT&T Universal Card, which got consumed by Citi a year later.

    I made great friends during my time with the “project”.  A few that I talk with frequently still.  We ran hard those 10 years, traveled to San Francisco 18 times one calendar year.  Every trip involved a branch presentation, numerous sales calls, and many conventions of sorts.  It was a busy time.  I didn’t call out many at all by name in this babble.  There were too many names and faces that ran hard right along with us, for me to list here.  We all did what was needed, from administrative to the Lab and shop floor.  I must admit that I smiled a lot as I looked at the pictorial directories.

    Only because it is expected, I will share a few of my favorite memories:

    • Bill Hagler attending our Halloween party in my home wearing goggles, snorkel, flippers and a speedo
    • Me going back to my hotel room after a long day and reviewing my voicemail on the bed, which included a Doug Brown message that I never heard the end of
    • Gifting Gary Seacrest an inflatable sheep at either his retirement or birthday party, which included reading the back of the box
    • and there are many others.

    This has been fun.

     
     
  • 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.

  • “For faster service, press 1”

    by Glen Taylor

    We all experience them; those annoying announcements at the beginning of many calls answered by some form of technology.  Perhaps the most common today is the obviously false announcement to “Please pay attention as our menu options have recently changed.”  Those of us in the IVR community know that menu options SELDOM change.  But, do you recall the “For faster service, press 1” announcement.  Younger readers may have never heard it, but during the 1990s and 2000s, this was a common occurrence.  Although not all of the announcements may have a good reason behind them, this announcement did.

    Before explaining why you were encouraged to place this announcement at the start of an IVR answered call, a little background is necessary.  The use of this message, or the lack thereof led to an interesting detective story.  But, before it will make sense, some background is required. Again, the younger reader may find all of this alien since modern telephony has passed this by more than a decade or so ago.  When Bell invented the telephone, the devices were simply “electrical” devices.  A phone was at one end of a pair of copper wires and a “central office” was at the other.  As technology advanced, the “central office” end became a switching system and it might have been a telephone company’s central office switch or a company’s private branch exchange (PBX).  When a caller lifted the phone’s handset to “dial,” this closed an electrical switch.  The handset sat in a cradle and depressed a switch (the “switch hook”) which “opened” the electrical circuit.  When the handset was lifted, spring lifted the switch hook and the electrical circuit became “closed.” This completed the electrical circuit, and the central office or PBX switch end recognized this by putting dial tone on the line.  The caller then “signaled” the switch the number that was being called by sending a string of encoded numbers.  The only means of “signaling” was to effectively hang up and lift the receiver a number of times in rapid succession.  This would generate a string of on-off pulses in the phone connection.  Since people can’t reliably do this signaling manually, the rotary dial was invented.  When the caller “dialed” a number such as the number 4, the dial would turn the phone connection off and on rapidly four times.  This “decadic” or “dial pulse” method was standard for decades.

    As technology progressed and electronic technology became inexpensive enough to incorporate into telephone sets, a signaling system based on audible tones was invented.  Each of the phone digits was represented by a pair of very precise tones emitted for a prescribed duration.  Because there were two tones of different frequencies for each digit, the scheme was called dual-tone multifrequency or DTMF. However, it was more colloquially known as touch tones because you “touched” a button on the telephone corresponding to the digit and the “tone” was produced. 

    The invention of DTMF made possible a number of new things, but it was initially more expensive on the phone company end as well as in the telephones themselves.  Since the phone company, primarily AT&T as the Bell System, owned the switches and the telephones, it bore the cost of replacing older switches and phones with newer ones that worked with DTMF.  DTMF phone service was priced higher than dial pulse service.  The costs rapidly came down and even reversed – it cost the phone company more to provide dial pulse service than touch tone service – but the price difference remained.  Phones became more sophisticated.  Rotary dials disappeared in favor of phones that only had the push buttons that were the hallmark of touch tone service.  Ironically, most phones had to have a setting to indicate whether pushing the number 4 would send the DTMF signal for 4 or the four decadic dial pulses for four.  Many people now owned their own phones (another major change for AT&T) but they might still be paying for dial pulse service (recall, it cost less) even though their phone was capable of both.

    Dial pulse signaling only worked reliably between the phone and the switch it was connected to.  Yes, someone on a completed call could “press a digit” and dial pulses would be generated, but only the switch directly connected to that phone was capable of responding to the digit.  Once a call was completed, the switch would ignore dial pulses.  They were simply “noisy interruptions” to the connected voice path.  Only when the caller “hung up” long enough would the switch decide that the call was finished.  If a caller pulsed digits during a call, clicking might be heard by the party on the other end but no reliable signaling passed from the caller to the listener.  If the caller pressed a touch tone digit during a call, the listener at the other end would get a clear DTMF signal.  The human ear can’t reliably interpret DTMF digits, but an IVR application can.  Thus, most IVR applications in the 1980s onward played recorded messages to a caller and prompted the caller to send DTMF digits in return.  This made for a powerful and reliable form of interaction.

    Let’s return to that “For faster service, press 1” announcement.  In the 1990s and early 2000s, there was a substantial mixture of consumer phone users having dial pulse service and touch tone service.  Most would have phones that actually had buttons to send digits, but their phone would have been “set” to either generate dial pulses or generate DTMF digits.  When a caller reached an IVR application, the application would typically play some prompt like “Please enter your account number,” and the caller would (hopefully) faithfully push the buttons corresponding to the account number.  At this point, one of two things would happen.  If the phone sent touch tones, the application could proceed appropriately.  If the phone sent dial pulses, the IVR would “hear” some form of clicking but it would not be able to reliably detect what digits were intended.  The result was usually an impasse that could only be resolved by transferring the caller to an agent who could conduct the transaction through a conversation.

    Since the IVR platforms of that day required touch tone input (reliable automatic speech recognition was emerging but it would not be accurate enough for a while and it was significantly more expensive to use), some means was needed to quickly screen out dial pulse callers and send them to agents.  There was no need to “waste time” (either the caller’s or the IVR’s) trying to interact with a dial pulse caller.  Better to send them immediately to an agent.  Thus, the “For faster service, press 1” announcement was born.  This became the recommended initial prompt for essentially all IVR applications of the time.  Dial pulse callers might send a “click” but the IVR would receive no DTMF digit.  It would recognize this condition as a caller who didn’t respond or a dial pulse caller and immediately initiate a transfer.  It usually didn’t really require a digit 1, any digit would do but 1 was the “cleanest” dial pulse digit.

    Unintended Consequences of Not Using the “For faster …” Announcement

    Since Conversant was a programmable device and the applications it ran were up to the user, and specifically the people who created the user’s applications, Conversant could not force the use of a particular announcement.  However, it was a strong recommendation.

    I became involved as a “subject matter expert” when AT&T’s legal team was preparing its brief in defense of a potential lawsuit.  Our customer, Citibank, had deployed Conversant equipment in its credit card division and card holders could call into Conversant applications to do various self-service tasks.  Initially, Citibank took our recommendation.  Each call began with the “For faster service, press 1” prompt with dial pulse callers shunted to agents immediately.  If the caller responded with a DTMF digit, the application proceeded to ask the caller to dial in his or her credit card number.  The rest of the application proceeded from that point. 

    Citibank received a high volume of calls.  The cost of servicing these calls, even with an IVR application, was higher the longer the calls lasted (number of calls times the duration of a call times the cost per unit of time equals the total handling cost.  This could be a big number.)  Citibank decided that it could reduce its costs significantly by merely skipping that initial prompt.  After all, it takes a few seconds to play the prompt, for the caller to hear, and for the caller to respond.  Why waste all that time on an interaction that didn’t advance the purpose of the call?  Why not just immediately ask for the account number?  That’s what Citibank did.  They eliminated that initial prompt. 

    Citibank’s credit cards were Mastercards.  All Mastercards begin with the digit 5 followed by a fixed set of digits that identifies the bank, in this case Citibank.  The rest of the 14 or so digits represent the individual card holder.  It turned out that Citibank had many customers living in a suburb of Chicago.  The central office switch serving this community was an older 1A ESS switch so all or nearly all of the customers in that community still used dial pulse service.  Once Citibank eliminated the screening prompt and prompted directly for the card number, all of the callers from that community would pulse “5 – digit – digit – etc.” corresponding to their card numbers.  Every one of those cards had exactly the same first 8 digits.  This had an unintended consequence that got Citibank sued.

    It turned out that the 1A ESS serving this community worked fine with dial pulses used to initiate calls.  That’s to be expected.  However, if a caller began to pulse digits DURING a call, the switch sees that as the caller rapidly hanging up and then going “off hook” repeatedly.  In most cases, the switch would ignore a few temporary interruptions in a call and keep it connected.  In this case, the switch interpreted the digit “5” as the caller hanging up.  Worse still, once that 5 digit was done, the caller was back “off hook” as if he or she wished to place a new phone call.  The central office switch then applied dial tone and received the next seven dial pulse digits as a new phone call.  It so happened that those seven digits corresponded to the phone number of an actual telephone subscriber.  The woman who owned that phone number was not amused to receive dozens of calls a day and at all hours of the night from Citibank card callers who were trying to access Citibank’s automated IVR system.  She sued Citibank!

    Citibank’s response was to have its legal team try to add AT&T to the suit and make us the “responsible” party since it was “AT&T’s IVR equipment” that was failing.  Needless to say, the detective work required to figure out what was happening (that I just described) was an “interesting” exercise.  Our lawyers pointed out to Citibank and the court that we had recommended they use that “screening” question.  When they had, it worked as expected and this problem did not and would not occur.  By ignoring our advice and unilaterally removing the prompt, they had brought this upon themselves.  It was, admittedly, a strange edge condition of how the phone network worked, but AT&T was not to blame either via its Conversant product or its former local telco’s regulated telephone services (in that Chicago suburb). 

    My involvement was done at that point.  I don’t know whether Citibank settled with the litigant and whether they went back to using the initial prompt, although I suspect that both happened.