Category: Product

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

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

  • “I made a mistake.”

    by Dave Schinke

    It was around the period of time that  a design for the first Model 80 IVR system had been settled on. I was at my desk  and Jim Walls came to me with a stack of 11” x 17” drawings. They were circuit designs for circuit boards, backplane wiring for the cabinet, physical slot arrangement for each circuit board, power supplies, etc.  Jim Walls, a good friend, was a circuit designer with deep knowledge of  Bell System equipment, and long experience in the company.

    “I need your signature so we can release these to manufacture,” Jim said.

    “Why me? Shouldn’t the hardware group supervisors sign off?” I answered.

    “Oh sure, they have signed off, but we need someone from the software side,” Jim replied.

    Well, the Good Book says something along the lines of “Trust the hardware guys as you would trust yourself.”   After briefly glancing at the drawings, I signed off on the package to be released to manufacture.

    Time passes as those drawings become reality, and the first Model 80 is ready to be delivered to Bell Labs from Western Electric.  Circuit boards were made at a facility in North Carolina, and the cabinet, power supplies, backplane wiring, and final assembly were done at the Columbus factory.

    Since I was going to be a person doing the customer installation, my supervisor asked me to “Check it out and see if it’s ready to go.”  Two strong men with some heavy-duty moving dollies brought it to the lab, and pushed it on a couple of planks up the step(s) of the raised floor. I set to work “Checking it out.”  I have forgotten all that may have been done but it probably included: loading software on the processor. The circuit cards probably had self-diagnostics at start up.  The speech database needed to be loaded and a test call  IVR transaction needed to be executed.

    Finally, I got to the point of making a phone call into the unit.  The call was answered, but no audible sound output, NADA.  Don’t remember all that I did from the software side to see what might be wrong. Checked connectors and looked at the rear backplane to see if anything obvious was loose. Just couldn’t find anything that was wrong.  Well, it was Friday afternoon, and I had to meet my carpool so I went home very frustrated and puzzled about the situation.

    On Sunday I told my spouse that I needed to go to the lab in the afternoon because we had a problem with something not working, and I needed to find out what it was.

    I pulled out the stack of equipment drawings thinking I could trace the voice path through the system and maybe find something.  How I did it physically is lost to my memory, but I could have done that with a tone generator or a touch tone held down on the phone while I used an oscilloscope to trace the audible signal through the system wiring. I worked from pin to pin on the backplane following the signal, and found that the signal died going from one board to another.  Looking at the drawings for the two circuit packs involved, I found a mistake in the backplane wiring connection.   The signal output side of one board was wired to the ground side of the next board instead of the signal input side. This same type of miss connection occurred at 4 places, two on the upper equipment shelf, and two on the lower shelf.  I had found the problem of “no sound”.

    First thing Monday morning, I took the stack of drawings and walked across the corridor from our lab to the Western Electric manufacturing engineers’ bull pen.

    As I walked-in I said: “I made a mistake.”

    Several responded “Well, that’s unusual.  Normally Bell Labs tells us what we did wrong!”

    I said “I signed off on these drawings, and I will take responsibility for a mistake.”

    After a bit of joshing, I sat down with the engineer that was handling this product.  We looked at the drawings and agreed that the 4 places that I had isolated appeared to be wrong, and should be corrected.   I asked, very nicely, if someone could come to the lab and fix the machine I was testing to see if it solved the problem.  They agreed, and after lunch, the engineer and a technician came with tools to work on the wire-wrapped connection backplane.  I had disconnected the power to the machine, so they went zip-zip, zip-zip and fixed the wiring in a short time.  I thanked them and said I would test the fix and let them know if it worked.

    When they left, I connected the power, fired up the machine, made a phone call and it  worked.   We had sound!  Made a phone call on every line to make sure, and IT WAS FIXED.

    A take-away from this story is what can be accomplished in a large organization if a person is patient, persistent, avoids placing blame, and works cooperatively with others toward a solution.

  • Memories of CVIS

    by Michael Womeldorph

    Quick CVIS background:  I started w/ Bell Labs CVIS in 1989 as a member of the Tier 4 Support team.  The support team was arguably the folks closest to the customers and use cases as we supported most trials and live systems.  A couple years later, AT&T relocated me to Denver to help bring up the domestic technical assistance center (TAC) then later the international support team (ITAC) for CVIS and Contact Center solutions.  I personally enjoyed the international support the most as I got to travel globally on AT&T’s expense and learned a ton about how our solutions were viewed/used in far off places (I ended up in international roles for the next 20 years).  So just a couple quick international stories about introducing CVIS into other cultures.

    Speech Recognition in the UK:   We started introducing CVIS speech rec after our solution in the US was working fairly flawlessly (e.g., recognition at 90%+).  The UK seemed like a good market for us, since we had the English version working well.  When we first started testing in the lab the accuracy was pretty good (around 85% or so) so we ended up doing a live trial.  After starting the live trial, the initial results were quite bad (less than 50% accuracy).  It was puzzling as to why the live trial was so poor, but since the system captured and saved the input from the customers, we pulled them down and started listening to the inputs.  Funnily enough, upon hearing the inputs, it was clear what the problem was; when prompted to ‘say “one” for X, “two” for Y’ etc.,  the Brits where swearing at the prompts (e.g., ‘*&%#, “one”).  In general, our British friends are much more comfortable swearing in everyday conversations than we are (I learned this first-hand a few years later as I took a 2 year assignment in the UK).  At any rate, our genius R&D team came up with the perfect solution; they built speech models for the most commonly used swear words, and changed the script to disregard any of the swear words and to look for the next word.   The accuracy of the trial immediately moved up to the +80% range!  

    Spanish Text-to-Speech and Voice Prompts:  When we developed the initial systems into Spanish, someone from the design team and I reached our to our team in Mexico to demonstrate the solutions and see if we could start lining up some trials.  We got to the office in Mexico City, set up the demo system, and got some of the key staff in the office together for a demonstration.  The reaction was immediately and universally both  heartening and disheartening:  “That’s really cool!  But you can never sell that here”.   When we asked the obvious ‘why?’, they explained to us that the demo solution used Castilian Spanish, which would never be acceptable in Latin America.  Kind of like us trying to use a NYC or southern accent in the rest of the US (Audrey Audix had a beautiful Ohio accent that is acceptable throughout the US).  So our key learning from the trip was that for Latin America, we needed to use voice talent from Colombia, which is acceptable throughout the region, and definitely not Castilian (which would be like trying to use BBC English in Macon Georgia)…