Table of Contents

What Not to Include at the Beginning

Skip everything at the beginning of the call except a welcome message
Long messages aren’t effective at the start of a call and can even be detrimental. Save instructions for 'just-in-time' help.

Balentine (2007) in his essay “Identifying Bad Practices” addresses several of the types of messages that commonly appear early in IVR calls but which the VUI design community generally considers to be poor design practice. Following is a list and discussion of up-front messaging practices to avoid.

Web Deflection Messages

Rather than viewing their IVRs as valuable tools for providing customer service, some enterprises seem to want to get callers to abandon the IVR and switch to the Internet due to its lower cost per transaction (Rolandi, 2005, 2007a). As Balentine (2007) points out, however, to achieve the goal of getting callers to hang up and use the Web instead, you must accomplish 4 sub-goals:

  1. Remind the caller that an enterprise Website exists.
  2. Get the caller to believe that the Web experience will be superior to the IVR.
  3. Get the caller to know the right Web address.
  4. Get the caller to hang up the phone and use the Web instead.

However:

In conclusion, when presented early on in a call, Web deflection messages are usually perceived as time wasters and are more likely to irritate than inform callers, which itself has adverse effects on usability, corporate image, and the cost per call. “For all those callers who don't need or can't use the website address, the company spends an extra 6 cents in telephone charges on every call. After 40 million calls per year, that begins to add up” ((Kotelly, 2006, p. 62). Web-related messages may have a place in IVR design, for example in after-hours messaging, but not in the standard call introduction.

Sales Pitches

Listening to a sales pitch is rarely if ever part of a caller's goal. Sales pitches may have a role in an application, for example, as part of an up-sell or cross-sell option after a caller has finished a task, but not in the introduction. “Poorly placed advertisements that inappropriately take up the caller's time or offer directions that are unlikely to be followed, are a hit against the brand – unless the brand stands for slow, thoughtless service. This behavior frustrates the caller and wastes money” (Kotelly, 2006, p. 62).

Prompts for Touchtone versus Speech

Some callers generally prefer touchtone (DTMF) to speech, so it can be tempting to offer this modality choice early in the call. Attwater (2008) found that callers care more about receiving effective and usable service than they do about the modality of interaction. Balentine (2007) pointed out that prompting the caller to choose upfront between DTMF and speech forces all callers (most of whom don't actually care) to listen to the prompt and either make a choice or wait for a timeout. All this just to serve the minority who have a strong preference, delaying the caller's first task-oriented interaction.

For these reasons, it's better to assume that speech interaction will work, only switching to DTMF if there is sufficient evidence of caller difficulty with speech. If speech turns out not to be working for most callers, then the organisation should make the necessary changes to get it to work; e.g. testing recognition accuracy, tuning grammars, adjusting prompt wording, usability testing, etc.

'Your Call is Important to Us'

Balentine (2007, p. 363) noted: “The enterprise that values a customer's call will service the call quickly. It is counterproductive to waste precious time on declaring value when the declaration itself defeats the value.” Rolandi (2005, p. 22) stated: “The practice is widespread, but the absurdity of the situation should be obvious if one adopts the perspective of the caller.” The general consensus in the VUI design community is that this type of message wastes time at best and, at worst, is also annoying.

'Please Listen Carefully as Our Options Have Changed'

Among expert callers (those who call back frequently), those who might benefit from hearing this type of message have a tendency to barge in and key in or speak ahead of the menu (given their familiarity with IVR) and end up skipping over the message completely, unless it's forced. Forcing experts to listen to such a message can, however, greatly annoy them due to the way it slows them down on every call until the message goes away. Infrequent callers (novices and non-experts) who are not familiar with the IVR application have nothing to gain from this type of message, so it's a pure time-waster for them. Thus, the message often fails to serve the target caller population but also penalizes all other callers at the same time. In addition, many callers who hear this type of message don't necessarily believe it, because such messages have a way of outstaying their usefulness (assuming they were ever useful) after the change has become ancient history.

If an organisation is required to include this type of message, avoid telling callers to listen 'carefully', and consider dating the message (e.g. “Please note that our options changed on May fifth.”). Finally, after it's been deployed for some period of time - consistent with the expected frequency of use - get rid of the message, preferably through a programmed setting.

'You Can Interrupt Me at Any Time'

For most callers, it isn't necessary to tell them that they can interrupt the IVR application. Callers have a natural tendency to interpret silence as a turntaking cue and will interrupt the IVR when it pauses. Heins et al. (1997) conducted an experiment in which some participants received an explicit instruction about the barge-in capability of the application and others did not. There was no difference in the actual barge-in behavior of the two groups, with both groups having a tendency to barge in during pauses in system speech. So, this type of message is completely superfluous.

'This Call May Be Monitored or Recorded'

Don’t play a “Calls may be monitored or recorded” message in the introduction, unless:

If it’s only the caller-agent interaction that is recorded, only play the monitoring message at the point of transfer, so that the people who self-serve (and never get past the IVR) don’t have to hear it at all.

If you have to have it upfront, consider doing it before the greeting (spoken softly and quickly, like the “fine print” in a radio advertisement). This prevents it from interrupting the natural flow of the interaction.

Turn the message on and off, if monitoring is intermittent (manually, if necessary; ideally, automatically, as a function of the recording control settings).

If including this type of message, make it reasonably concise. The following, for instance, all say the same thing as the many much longer versions that are out there:

The only thing that longer versions accomplish is to waste callers' time and the enterprise's money (see the topic Getting the Caller Engaged).

List of Commands

For IVR applications that include 'universal' (also known as 'global') commands, don’t provide a long list - or even a short one - of universal commands during a call's introduction. These lists fall squarely in the category of stuff callers don’t listen to or remember. In usability testing such a system, the interviewer asked participants what the commands were that they could say. Very few could remember any at all and nobody was observed using them during the test. We know of no published research on this topic, but logical analysis suggests that no matter how concise you might make this type of message, it will delay the caller from hearing the initial prompt, thus delaying immediate engagement. Instead, present these commands only when callers are more likely to actually need them (e.g. in help messages or in menus offered at task completion points).

See also the section: Commands

What to Do When the Client Insists

Make the messages as concise as possible
If the client absolutely insists that one of the above-mentioned types of message be included in their IVR, then try to make them as brief, concise, and unobtrusive as possible.

Play the message only once per ANI
Most of the above types of message are only really relevant once. So a solution would be to have the client set up a table with the ANIs that each of the messages is played to. The table should be checked every time before playing a message. If a message is played, the corresponding ANI number should be added to the table. You may even want to offer to have an expiration date on the ANI table, so that each ANI gets removed every so often, such as every 30 days. The goal is to avoid playing these types of messages, but if you must, try to impinge on the customer experience as little as possible.

References

Attwater, D. (2008). Speech and touch-tone in harmony [PowerPoint Slides]. Paper presented at SpeechTek 2008. New York, NY: SpeechTek.

Balentine, B. (2007). It’s better to be a good machine than a bad person. Annapolis, MD: ICMI Press.

Heins, R., Franzke, M., Durian, M., & Bayya, A. (1997). Turn-taking as a design principle for barge-in in spoken language systems. International Journal of Speech Technology, 2, 155-164.

Kotelly, B. (2006). Six tips for better branding. In W. Meisel (Ed.), VUI Visions: Expert Views on Effective Voice User Interface Design (pp. 61-64). Victoria, Canada: TMA Associates.

Rolandi, W. (2005). The impotence of being earnest. Speech Technology, 10(1), 22.

Rolandi, W. (2007a). Aligning customer and company goals through VUI. Speech Technology, 12(2), 6.