Dennis D. McDonald (ddmcd@ddmcd.com) consults from Alexandria Virginia. His services include writing & research, proposal development, and project management.

Things to Consider Before Changing a Voice Response System

by Dennis D. McDonald, Ph.D. 

Click or tap the above image to download a .pdf version of this article.Summary

This paper discusses key issues that management should consider when redesigning an automated voice response system that employs automatic speech recognition (ASR) technology in support of customer service. These include (1) the need to manage the language used for all customer facing systems, (2) the need to anticipate the “ripple effects” changing the voice response system will have on other company systems, and (3) the need to carefully balance the role played by voice response systems with the frequent desire of customers to speak with a human operator.

Introduction

I was recently part of a team that helped a client work through proposed changes to its customer service department’s telephone voice response system menus. The client, an energy utility, wants to improve how customers interact by phone with the company. Their goals include:

  1. Continue to encourage phone based self service.
  2. Appropriately identify the calls that must be transferred to a live customer service representative.
  3. Improve overall customer satisfaction with phone based customer service.

The client’s voice response system, already in operation for over two years, emphasizes voice responses as opposed to keypad data entry. Most of the time the caller hears phrases such as, “If you’re calling about A or B, say A or B.” Saying “A” or “B” then takes the caller to another menu with choices more specific to the reason to the call. (In this example “A” and “B” represent individual words or phrases spoken by a prerecorded voice.)

The system works by hearing and translating the words spoken by the caller in response to carefully designed and organized voice prompts. Explicit telephone keypad press instructions (such as “If your answer is ‘yes,’ say ‘yes’ or press 1”) are minimized, even though the system can make keypad data entry available when required. Mention of the telephone keypad is usually made explicit during a call when it is necessary to input a number such as an account number or a phone number. Spoken numbers can also be used to enter numbers.

Prior to the workshop my team members, Mark Camack and Peter Brandt of Market Strategies, Inc., had prepared a detailed analysis of the company’s existing menu system. Most of our time during the workshop was then devoted to discussing the existing menu and a series of proposed changes for making the menus simpler, clearer, and less error prone. I was there to provide feedback in situations where IT system or software application resources would be impacted by proposed menu changes.

Cost and Time

As with many things, “error” in a call handling situation tends to increase time, frustration, and cost, and perhaps even exacerbate a life-threatening situation:

If the caller’s words are misinterpreted by the system’s recognition software, that increases call time and caller frustration as the automated system tries to interpret responses.

If the automated system doesn’t provide the necessary options to solve the caller’s problem during the automated portion of the call, or if the caller’s speaking voice is not interpreted correctly (say, because there is too much background noise for the software to screen out) the caller will transfer out to a live operator, which might require the caller to be put on hold till an operator is available.

Based on such considerations there is always pressure to make the initial menus as clear, precise, orderly, and understandable as possible to optimize the system from a company point of view and the caller’s as well. Most of our time in the workshop was devoted to discussing the specifics of how to accomplish this.

A Balancing Act

Most people who call 800 numbers probably don’t know (or care) about the complex network of applications, software, hardware, and databases that sit behind such voice response systems. Nor is the “ripple effect” of making a change in one part of a system readily apparent on other parts of the system.

Shaving a few seconds off a call, on the average, doesn’t seem like much. When you multiple a few seconds times the millions of calls an active system gets during a year, though, you’re talking about some serious impacts on call volume as well as on system capacity requirements.

Also, if you can increase the percentage and number of transactions that are completed through the automated transactions without having to involve a live human operator, you can save some really serious money, since trained human operators are much more expensive than software.

What seems to hold true for all kinds of organizations is the desire to balance the efficiency of automated “self service” call handling with the “personalized touch” of a live human at the other end of the phone. A practical consideration is that automated calls are, generally speaking, less expensive to handle than calls that require human involvement. Automated calls also have the potential for being resolved faster than human-handled calls, especially if the human-handled call is put into a “queue” requiring the caller to wait for the “…next available operator.”

In recent years, many companies have added voice response to customer service call menus that were previously only keypad based. Some people automatically prefer to talk with a live human, even for simple transactions like a billing or payment inquiry. Others are satisfied – and some even prefer – basic calls to be handled quickly and efficiently by automated systems.

What you end up doing is designing systems and processes that carefully balance several factors. Through the ease of use of your voice response system, you try to maximize the number of people who elect self service and automated call handling; a well designed voice response system can help make that happen. As a part of this strategy you may use both subtle and not-so-subtle methods to discourage callers from immediately “opting out” for a live human operator. This in itself is a balancing act since, while you may want a caller to use the automated response system, you have to allow an opt-out even if you don’t make its availability immediately obvious.

At the same time, for those people who absolutely must have human support, you have to make that available, even though as a system operator you know that, nine times out of ten, the more people who opt for a human call taker, the more likely it is that they will experience a delay because they are put into a queue. And delays introduce frustration and, maybe, a reduction in user satisfaction.

In the call center world, queues are a Bad Thing. Nobody wants to wait. In fact, in some call centers, buzzers go off and lights flash when queue wait times climb too high.

Management Considerations

As a designer your goal is to make your automated voice response front end so easy to use, so friendly, and so crisp and clear that the caller can’t help but rapidly complete a successful transaction entirely within the automated system. To make sure this happens, you need to do testing (via surveys, focus groups, and one-on-one observations) before you make the system operational.

Based on my own experience with call centers and involvement in several workshops like the one last week, I’ve listed below some ideas about voice response systems in the context of a company’s overall customer relationship strategy. These include:

  1. Give Customers a Choice
  2. Use Consistent Language Across all Customer-facing Media
  3. People Know They’re Talking to a Machine
  4. Manage The Ripple Effects In Advance

1. Give Customers a Choice

You can’t think of voice response systems in isolation, especially if you are dealing with the general public. You have to think about using them in connection with the other methods for customer interaction that already exist – email, human customer service representative, walk-in office, mail, web, you name it. Different groups may prefer different ways of interacting with you. Individuals in different situations (or in different points in one transaction) may prefer one form of interaction over another:

An office worker may prefer to use a telephone’s keypad if she doesn’t want someone in the next cubicle overhearing her account number.

A retiree may prefer to very quickly check an account balance on a retirement fund via the web without having to involve a human, just because it’s more efficient.

It’s all about “customer choice.” Just as a well designed web site provides many different choices for reaching a given page, a well designed company communication strategy will enable the customer to communicate or solve a problem – consistently – via variety of media or channels. It’s up to the company to make sure the choices are coordinated and consistent. This includes the words and phrases used in a voice response system.

2. Use Consistent Language Across all Customer-facing Media

No matter how your customer chooses to communicate with you, you need to provide a common “face” with common language, terminology, and even images. The words you use in a voice response system to refer to your services have to be compatible with what your live reps say, what your bills say when printed, what your web pages say, and what your radio and TV ads present.

This may sound like common sense — and it is — but words don’t manage themselves. You need to consistently manage how language is used across all communication media, no matter what department manages them.

You also need to be aware that when words are embedded within automated systems – as they are with voice recognition systems – they can’t just be ripped out and replaced as you do when using a word processor to make changes to a printed page. Those words in the voice response menu are linked to other words and other actions, and you have to take those one-way and two-way links into account.

The bottom line: words, language, messages, and meaning need to be managed in a way that reflects your company’s business strategy and the technology infrastructure that supports it. This holds true especially when different departments or working groups are responsible for managing a company’s multiple communications channels.

3. People Know They Are Talking To A Machine

We’ve become accustomed when communicating with large companies to a certain degree of personalization, even when we know our communications channels are highly automated. Web pages based on the placing and reading of “cookies” are built in real-time to reflect our stated preferences as recorded during previous visits. We receive mail that reflects our buying habits (and the economic status of our zip code). When we call a company to discuss a bill, to order something, or to handle a problem, we expect to receive a certain amount of personalization, politeness, and professionalism

This doesn’t mean that we should try to disguise the fact that the voice at the other end of the phone is automated. Until we reach a time when perfect natural language systems evolve to a point where callers are unable to distinguish them from the real thing (a live human) it is futile – and potentially annoying – to pretend the recorded voice is real. That means that slang, folksiness, and colloquialisms that detract from a professional and businesslike image should be avoided.

If I’m calling to make sure my electricity isn’t going to be cut off, I don’t want to be sold something while I’m on hold, and I don’t want a cutesy voice at the other end greeting me; I want sincerity, efficiency, and professionalism.

4. Manage the Ripple Effects In Advance

This is a corollary to the need to manage a common language across communications channels. As suggested above, when you change one part of a complex system, you need to know in advance what the ripple effects are going to be. You need to know which systems are impacted by changes and what it will take to implement, test, and introduce these changes into operation.

In our workshop, for example, representatives of the utility’s Outage Management department wanted more information about electricity outrage reports than the automated system was designed to provide. Their solution: route the calls to the call center so live agents could query the caller and provide more information to supplement work orders.

Their idea was to reduce the cost of dispatching unneeded work crews. But this change had to be weighed against (a) upgrading the voice response system to provide more outage details and (b) increasing the call center’s work load.

This is a common problem of tradeoff analysis. In order not to be drowned in numbers through “analysis paralysis,” organizations need to plot out in advance what procedures they will follow to analyze and evaluate potential changes to a voice response system.

An organized and efficient “change management process” will, over time, reduce the time and expense involved in deciding how and when to introduce changes into the automated system and its associated human processes.

Related reading:

Copyright © 2005 by Dennis D. McDonald. Dennis is an independent consultant based in the Washington DC area. He has worked throughout the U.S. and in Europe, Egypt, and China. In addition to consulting company ownership and management his experience includes database publishing and data transformation, integration of large systems, corporate technology strategy, social media adoption, statistical research, and IT cost analysis. His web site is located at www.ddmcd.com and his email address is ddmcd@yahoo.com. (My thanks to Peter Brandt for reviewing an earlier draft of this article.)

Sony Rootkit "Phones Home"? (Smells like ... DIVX?)

Fallout from the Sony BMG "Rootkit" DRM Debacle