AVIxD tackled the concepts of adaptation, customization, and personalization in its 2009 workshop. The three articles produced as part of that workshop go into further depth on some specifics of what is discussed here.

Callers expect personalization, so do it
In 2009, we were still somewhat worried about how people would react if we started customizing their interaction. Would they know how we knew it was them (generally ANI)? Would they have Big Brother kinds of concerns?

At that point, the findings were that while young people were used to sharing everything with everyone in the digital age, older people were more concerned about privacy and companies knowing too much about them. As of this writing in 2015, the vast majority of people now fall into the previous category.

We are used to using apps on our phones and websites with cookies, where companies know exactly who we are and provide an experience that is tailored to us. IVRs should do the same. People know companies have huge amounts of data and are frustrated when they don't use it. If you purchase a new service from a company and call in immediately thereafter, they should know that's why you're calling. And they definitely shouldn't be advertising the exact same service to you.

It doesn't hurt to tell them you found their account or information by the phone number they're calling from
Per the Big Brother conversation above, most people now know that's how you're finding their information, but it doesn't hurt to let them know as long as you do it as compactly as possible. It does reassure the minority who are still concerned about it. As an added bonus, since it's often at the very beginning of the call, it provides a nice transition into asking for other pieces of information and facilitates turn-taking.

If they weren't found by ANI, offer to save the phone number they called from
To streamline future calls, when the caller comes into the application with an ANI that fails to match against known customer profiles, consider offering the caller the chance to store the number to his profile after task completion if 1) the caller successfully self-identified and authenticated, and 2) the CRM system is able to accept additional numbers. See also Offering to Save ANI.

Positive first impressions are an important step on the way to building trust with a customer.

A great way to do this is to offer a customized experience. Show customers that you know why they’re calling, and use that knowledge to streamline their caller experience. Use their ANI (the incoming phone number), their past behavior, company-wide issues, account status, customer type, anything you have. ANI, together with caller history, can be a great way of building trust.

For example, if a caller has placed an order with a retailer and they call the IVR, the IVR might first offer “Are you calling about the order you placed yesterday for <#> <item(s)>?” before playing a more general menu.

Think of customization in terms of accounts, not people
That sounds insensitive, but it's more accurate. In the example above, the driving issue is not the fact that Joe Hernandez is calling, it's that he placed an order yesterday, i.e., the account status.

This type of customization is sometimes called situational awareness. Know what's going on with the customer, and adapt accordingly. A couple more examples to illustrate the idea; the first is awareness about the customer, and the second about the company:

• A customer calls an airline. She can be identified through her ANI, and you see that there is a reservation that leaves on date A and returns on date B. Today is between A and B. It's extremely likely she's calling about this particular trip. She doesn't want to purchase miles. She doesn't want to make a new reservation. Don't give her a standard main menu.
• A newspaper carrier experiences some kind of delay. Someone calls in who is on that route. It's a pretty safe bet he's wondering where his paper is this morning. Let him know about the delay before you even ask about the reason for his call. You may save him the trouble of going any further in the system.

Balance offering what you think the caller needs with letting them control the interaction
This is sometimes easier said than done. When providing proactive information or questions, look at the certainty that your offer is actually what the caller wants. Is it a 50/50 chance you know why they're calling? Or maybe it's much more certain. This should influence whether and how you present the proactive question. In any case, callers need to be able to bypass whatever you're offering them and continue on in the application. Don't lead them down the path you think they need with no way to escape.

Offer applicable options
Let's look at travel and newspapers again. If it's six weeks before the identified trip, then there's no need to feature “how to check in” prominently in the menus, or maybe at all. Similarly, if the trip was in the past, then making a change to it isn't applicable. For our newspaper situation, if the caller has recently terminated their subscription, restarting it might be a good menu option. Or if today is in the middle of a vacation hold, then modifying that hold would be applicable.

Don't speak the caller's name unless it's absolutely necessary
A topic that sometimes comes up in connection with personalization is whether the application should speak the caller's name. Companies who view their IVR applications as extensions of customer service may express a desire to use customer names as they do when scripting interactions between customers and call center agents. Given that in the United States alone there are more than 2,000,000 reasonably common surnames and 100,000 reasonably common first names (Spiegel, 2003a), it's difficult to create and maintain recordings of names. Text-to-speech (TTS) production of names is an alternative, but there are several known difficulties associated with this strategy (Damper & Soonklang; Henton, 2003; Spiegel, 2003a, 2003b), including:

• Uncommon patterns of English letter sequences
• Names with letter sequences borrowed from other languages which are rare or nonexistent in standard English
• Names that have the same spelling but different pronunciations (e.g., Koch)
• Names that include symbols or punctuation (accents, umlauts) that are not part of standard English

We know of no research on the impacts of mispronouncing a caller's name, but it's hard to imagine that mispronunciations could do anything other than damage the relationship between an enterprise and a customer, making this a risky approach to creating a positive first impression. Estimates of the pronunciation accuracy of proper names produced by general (untuned) TTS engines range from about 50% (Henton, 2003) to 60-70% (Damper & Soonklang]) to 70-80% ([[references#spiegel2003b|Speigel, 2003b). After 15 years of research dedicated to improving proper name pronunciation via TTS, Spiegel (2003a, 2003b) reported a tuned system that achieved 99% correct pronunciation for common names and 92-94% for uncommon names, demonstrating that this problem, although very difficult, can be solved. The implications for VUI designers are:

• Unless an application absolutely requires it, avoid designs that address the caller by name.
• If you must address callers by name and do not want their names mispronounced, be prepared to make a substantial investment in this part of the design (either doing the work yourself or purchasing the design from a vendor).

Damper, R. I., & Soonklang, T. (2007). Subjective evaluation of techniques for proper name pronunciation. IEEE Transactions on Audio, Speech, and Language Processing, 15(8), 2213-2221.

Henton, C. (2003). The name game: Pronunciation puzzles for TTS. Speech Technology, 8(5), 32-35.

Spiegel, M. F. (2003a). Proper name pronunciations for speech technology applications. International Journal of Speech Technology, 6, 419-427.

Spiegel, M. F. (2003b). The difficulties with names: Overcoming barriers to personal voice services. Speech Technology, 8(3), 12-15.