-->
  • March 17, 2011
  • By Leonard Klie, Editor, CRM magazine and SmartCustomerService.com

IVR Personalization: Strike the Right Balance

Article Featured Image

The value in deploying an interactive voice response (IVR) system is its ability to service customers without the need for a live person. While that’s generally regarded as an advantage in speed, cost efficiency, and resource allocation, the downside is that these automated interactions are impersonal. While IVRs could never replace the emotional support and friendly demeanor of a live operator, they can be made more personal—that is, they can better identify with callers—with a few tweaks to the script and some properly placed caller identifiers. That sounds easy enough, but when it comes to personalizing an IVR, most companies don’t know Jack.

They assume a good way to create a unique interaction with each customer is to greet him by name at the outset of the conversation. After all, it’s easy to do. A simple automatic number identification (ANI), or caller ID system, can tell them who’s calling long before an operator or automated system ever answers the phone. Throw in a basic speech synthesis command and the IVR can add the name to its basic greeting.

But when it comes to personalization and IVR construction, designers of all sorts agree that having an IVR greet a person by name at the beginning of an interaction is a bad idea. For starters, it can scare some customers away.

Mark Stallings, a voice user interface (VUI) solutions architect at Integrated Voice Solutions, recalls a system for a credit card company that offered this greeting: Hi, Mark. How can I help you today? “It totally freaked out the customers,” he says. “It’s disconcerting if I’ve never called you before and you already know my name.”

Jenni McKienzie, a VUI designer at online travel portal Travelocity, agrees: “If you think the company is coming up with your name and information out of nowhere, you may get weirded out.”

The dangers of greeting a caller by name early on play out in other ways as well. For starters, caller ID by itself only provides the name of the person to whom the phone number is registered, not necessarily the name of the person on the other end of the phone. A spouse, child, parent, or houseguest could just as easily be using a landline phone in someone’s home. Or, since most business transactions take place during the workday, a caller is likely to be dialing into an IVR from his work phone; the call is likely to be routed through a switchboard, which would only confound an ANI system.

In a worst-case scenario, a company that assumes the identity of the caller based on the ANI data could inadvertently reveal someone’s personal information to an unauthorized recipient, which would have serious repercussions for both the account holder and the company.
Caller ID data linked to a cell phone or wireless device is more reliable because the user is more likely to be the registered owner, but even that’s not a guarantee.

Another problem with using names is that speech synthesis could mangle the pronunciation; the consequences of that happening outweigh the benefits of a small level of personalization. “It’s nice when [the name] is pronounced right, and some people might not mind when [the system] gets it wrong, but others could have real issues with that,” says Sondra Ahlen, principal consultant and owner of SAVIC, a VUI design firm.

With a name, system designers also could run into difficulties based on what some customers prefer to be called. While John Smith might not mind being called by his first name during a transaction, or might prefer it, John Doe might want to be called Mr. Doe and would see the use of his first name as inappropriate. The latter is more common with older callers, VUI design experts say.

And while that isn’t an issue with male callers, systems cannot tell immediately whether the woman on the other end of the call is married (Mrs.), single (Miss), or would prefer the more generic Ms.

But, despite all the reasons against it, some companies might still insist on greeting callers by name. In those cases, verifying names that have been pulled from caller ID is recommended. A simple statement could suffice, such as the following: I see you are calling from <phone number>. This number is registered to <name>. Is this the person to whom I’m speaking?

Ahlen, on the other hand, suggests saving the caller’s name and not using it until after he has logged into his account. “If I’m just throwing it out there, it can be very strange, but after I’ve logged into my account, it’s definitely appropriate to acknowledge who I am,” she says. “Especially if I’m going through some kind of voice security [to verify my identity], using my name is appropriate to let me know that I have logged in successfully.”

Stallings takes it one step further, saying voice biometrics could enable the ultimate in personalization. “Deep personalization can’t really happen until I know it’s you,” he says. “If I can do a biometric enrollment and immediately identify you without a doubt, I can do so much. I can provide relevant information up front and know that it’s going to the right person.”

But that, too, risks losing customers. In this age of computer hacking, fraud, and identity theft, some people are sensitive about having their voiceprints stored somewhere, cautions Deborah Dahl, principal at speech and language consulting firm Conversational Technologies.

Personalize with a Purpose

It’s not just the use of a customer’s name that can be seen as creepy or intrusive. A system that relays too much personal information to a caller before she is ready for it can have her lashing out at Big Brother, looking over her shoulder, and questioning how a computerized system would know intimate details about her before she has had the chance to utter a word.

As such, it’s never a good idea to greet a caller with the following: Hello, Mary. Are you calling about your bill, which is now three days past due? Such a statement might seem like a good idea to the company because it lets Mary know that a payment is due and allows her to take care of it. It might even be good for Mary if she had been calling to make a payment.

However, chances are good that Mary is calling for another reason and would get frustrated if her desired task is put on the backburner while the system handles something unrelated. Even the most well-intentioned businesses would soon learn that when they try to give a customer what they think she needs rather than what she wants or asks for, there is little forgiveness for a system that detours her away from her intended task.

The goal of any personalization should be to better serve the customer in a targeted way that helps him complete his task more quickly and efficiently, says Donna Fluss, founder and president of DMG Consulting and a former VUI designer. She offers this advice: “Never force people to do what they are not comfortable doing. When you take that control out of their hands is when you run into trouble and risk creeping them out.”

Personalization becomes easier and more practical when the customer has built a relationship with a particular company. While it will almost always scare customers who have never dealt with a company before, personalization becomes more accepted—and in some cases expected—when there is some history.

“If you’ve done business with a company before, you can expect it to have information about you,” McKienzie says.

Moreover, as long as it’s not too intrusive, companies today could ask questions in the IVR and store the answers to better serve the customer the next time he calls. “Most people are at the point where they want to tell you about themselves to help create a personal profile,” Stallings says.

But, for personalization to be truly worthwhile, it needs to benefit both the business and the caller. Without a business upside, it would be hard to justify the expense. And if the customer doesn’t achieve a benefit, it could negatively influence his future business dealings with the company. Thus designers often walk a fine line between what’s best for the business and what’s best for its customers.

That line can be broader when simple caller ID data are linked to account data behind the scenes without the caller ever knowing it. Under the right circumstances, the benefits of using caller ID tied to accurate and up-to-date customer records are numerous. With this inexpensive data, systems could customize menu options, route calls to the appropriate departments or agents, anticipate a caller’s needs based on selections she had made during previous calls, target on-hold messaging to her unique tastes or preferences, and even provide her with sales promotions.

My Own Agent

One day, it might even reach the point where a customer would be able to create her own virtual personal customer service representative—a personal butler or concierge—with the type of persona she would like. Ahlen says that such highly personalized systems are possible, but the costs would be difficult to justify. Companies could limit that offering to their most high-value customers or charge a fee for it, she suggests.

More grounded in current business realities, an IVR today can use caller ID and other relevant customer data to infuse an interaction with a level of situational awareness, meaning the company could anticipate the caller’s needs based on events taking place and correctly direct the call or provide necessary information. This often doesn’t even require additional technology or collecting additional data.

One example of that scenario is when an electric company identifies an outage and uses the IVR to relay important information to the customer. The system collects the ANI, pulls up the customer’s account, checks the address, and identifies the caller’s neighborhood as one affected by the outage, all in real time and in a fraction of a second.

The system can answer the call, bypass the main menu, and immediately ask the customer if she is calling about the outage. The power company then can set the customer’s mind at ease and let her know when service will be restored. Not only has the company addressed the caller’s needs but it has also deflected high call volume transfers to live agents during an emergency, which in turn reduces operational costs.

Language of Choice

ANI data also could be used to alter the language, dialect, and accent of an IVR application depending on the geographic region of the country from which the call originates. Companies could store into their CRM systems whether the caller prefers to conduct business in English, Spanish, or another language, and then offer the IVR script in that language. It makes a huge difference, Ahlen says.

“Menu items may need to be different because of cultural differences that shape caller behavior,” she says. “Different attitudes, behaviors, and interests can be tied into a person’s language and culture.”

The one caveat, though, is that it can be tricky and expensive to offer an IVR dialogue in a number of languages. If the company already has an IVR dialogue in English, it could add another 80 percent to the cost to build another language into it. “You need to look at your ROI. In the case of Spanish in the U.S., there is definitely a population where it will be worth it,” Ahlen advises.

The ANI data can also be used to tailor the script to specific caller segments. This is especially true of health insurance companies, where entirely different menu choices are offered to healthcare providers and patients.

Using the ANI, the insurer can see the call is coming from a doctor’s office and dynamically skip the patient menu entirely. The insurer also could use historical data to see that approximately 85 percent of calls from doctors’ offices are looking to verify a patient’s coverage and ask the provider if the call is related to that issue. If it is, then the caller would be taken to the intended target immediately. If it’s not, it would be easier to get to the other options.

Frequent Caller Benefits

Where personalization really comes into play, though, is in detecting caller behavioral patterns and adjusting the scripts and menus to suit them.

Stallings recalls designing a system for one company whose callers often wanted to check their account balances. By providing that option to callers up front in the menu, the company was able to deflect 40 percent of the calls that were going to agents.

“If the majority of people are calling in repeatedly with the same request, you can provide that information right away,” he says.
The same rule applies with individual caller behavior. “If I’ve asked for the same thing twice before, I should be able to get it the third time without having to ask for it,” Stallings says.

“Don’t give me a two-minute drill about all my options if I always call in for the same thing,” Ahlen adds. “I don’t care so much if I call into my bank and it says my name, but if I call into the bank and do the same thing every time, give me that option up front.”

Doing so is easy. Such information is typically available in most basic CRM systems, and it doesn’t take a lot of coding or recoding to work it into an IVR script. Typically, all that is required is writing the business rules into the IVR dialogue and manipulating the layers to adjust for them.

Where it gets difficult, though, is when there is an exception to the business rules. Systems have a difficult time recovering when the options presented do not match the callers’ needs.

“You can analyze people’s behavior and change the IVR for it, but if it’s not what they want this time, how do you get back to the regular menu? That’s the hard part for some applications,” McKienzie says.

Her solution is simple. She suggests putting in a line that asks the caller if he wants his usual: I see you usually call in for <this reason>. Is that why you’re calling today?

Doing so gives the application a personal touch, letting the caller know that you not only are aware of his history but that you also want to help him get done faster. Simply put, “it keeps them from having to go through an entire menu if they do not have to,” McKienzie says. “People really appreciate that.”

At the very least, doing that could shave a few seconds off the average call handling time, thus leading to a financial savings for the company.

Another layer of personalization is possible for power users—those who call often. That group has often memorized the series of inputs needed to reach a certain spot in the interaction without listening to the prompts and can push keys or utter commands even before the IVR has finished offering choices. Those users would like to speed up the dialogue and spend less time in between prompts.
Conversely, for less-seasoned users, the dialogue could be delivered more slowly, and longer pauses could be inserted between the lines of dialogue.

However, for many, personalization’s real benefit comes when it is applied to marketing efforts. As an example, Fluss cites a customer who calls in to her bank and, based on her past behavior, the bank sees that she now qualifies for a larger line of credit. The bank could add something to the script to to make that offer to the customer. In addition, companies could use demographic data to tailor messages.

Companies pursuing that kind of marketing make broad generalizations about their customers based on age, gender, location, and other factors. “It’s just a part of marketing. You look at demographics and try to sell your products to that demographic,” Dahl says.
As with so many other elements connected to personalization efforts, what can be done and what ought to be done do not always fit into the same shopping cart.

“You assume that people want [that kind of marketing] to happen, and that’s not always the case. People want marketing outreaches a lot less than marketers realize. They generally don’t like it,” Dahl comments. “People object when their personal information is used to annoy them with offers for products they don’t want.”

McKienzie agrees: “People in general get bothered by cross-sells and upsells. I called because I want you to fix something, not because I want to buy something else.”


News Editor Leonard Klie can be reached at lklie@infotoday.com.




CRM Covers
Free
for qualified subscribers
Subscribe Now Current Issue Past Issues
Buyer's Guide Companies Mentioned