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.

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:

• Given that it's the 21st Century, callers already know that most - if not all - enterprises have Websites. They don't need a reminder.
• The caller has chosen the phone as the preferred channel of communication for a reason. If the caller believed the Web would provide a better channel, they would be on the Web instead of the phone.
• If you don't spell out the URL, there is a risk that callers who try to use it will not be successful. For many companies, this probably isn't a issue, but for companies with several possible spellings of their name, such as Philips, it's definitely possible (There are two common spellings of the name depending on whether you use one or two “L”'s). And it takes considerable time to spell them out.
• There's no evidence that callers frequently (if ever) hang up and go to the Web after having heard this kind of message.

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.

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).

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.

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.

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.

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.

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

• There is a legal obligation to play the message (e.g. Government regulation)
• The IVR is actually recording

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:

• “This call is recorded”,
• “Calls are recorded for quality”, or
• “Calls may be monitored”

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

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

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.

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.