In this post, I’ll cover building the core IVR menus.
Before I go too far, I’d like to point you to my series on call center queues. In the first two posts, I cover some of the thinking that I use when designing IVR menus (which, of course go hand in hand with the queues). This stuff is critical, because your IVR will affect your wait times and/or your staffing levels.
IVR Menus and Applications
Our menus will be used to:
- Classify the calls
- Send the calls to the correct queue
- Possibly, access other self serve applications.
For those who haven’t come from the call center world, it’s useful to introduce the concept of IVR applications. In addition to call classification, IVRs can also be used for self service functions. These are typically organized into “IVR Applications”. Check your bank balance and pay a bill? That’s an IVR app. Validate a credit card by entering in the number and PIN? That’s an app. Partitioning your function into these apps is a useful construct, much better than one large monolithic clump of spaghetti.
There are two options for prompts. As you would expect, you can upload .wav sound files for your prompts. These have to be converted to “telephone quality” audio1, and I have run into systems that do this poorly, leaving the prompts sounding noisy or distorted. I did a test recording in my studio (yeah, I have a studio), and uploaded it. The results were, uh, OK, but I did expect better. I need to do more tests and compare it against using it with converters I know, so my recommendation is to test it yourself. Record some prompts, upload them, then dial in and listen.
The second option is Text to Speech (TTS). I wouldn’t typically recommend using TTS, but with Amazon Connect it is a viable option. It uses Amazon Polly, the same engine that drives Amazon Alexis. The basic TTS works pretty well, and you can do better if you take advantage of Speech Synthesis Markup Language (SSML)2.
I would still recommend professional voice talent. You can tell that Polly is machine speech, albeit excellent machine speech. However, prompts are an ongoing commitment, and keeping the same professional voice over time isn’t always easy. You would be better off using Amazon Polly if your alternative is using internal employees or different voices in different parts of the menu (seriously, please don’t do this).
Of course, Amazon Connect supports DTMF3 menu navigation (“Press 1 for Sales, Press 2 for Service”). It also supports Amazon Lex, their service to build conversational interfaces, which, again is used with Amazon Alexis. This is extremely advanced stuff, and is something that Amazon is emphasizing.
I would avoid using it for menus for now. Not because Lex doesn’t work, because it does. Alexis proves it.
The first reason is that building a good IVR, queues, and all the other facilities that go into customer treatment is HARD to do well. It is easy to do badly, as evidenced by all the frustrating systems out there. Building a good voice response system takes a lot of effort, and you should really concentrate on not frustrating your customers. I will grant that playing with Lex is more fun, though.
The second reason is that the call center industry has already gone through the Great Automatic Speech Recognition Scare of the 2000s, where voice recognition was heralded by the industry as the savior of customer care. And customers hated even the best of them4.
This video is equal part funny and distressingly accurate. Excuse the lousy quality.
Now, the Lex technology is superior to what these IVRs used. But it doesn’t solve the core problem. People don’t know what to do when confronted with a voice IVR.
Truth is, people don’t like IVRs, period. The best that you can do is make them clear, unambiguous and quick. DTMF for the win – for now.
I would consider Lex for other IVR apps, though, if the app would be used by a customer frequently enough that they could get used to it.
Get Customer Input Block
For menus, you use the “Get Customer Input” block. In the block configuration, you enter which keys you want available for key presses, and they appear as outputs on the block. This is also where you select the prompt you’ll play.
You also have Default, Timeout and our standard Error output.
The Default output is for keys they’re not supposed to press. Standard practice is to play an “Invalid Selection” type prompt, and replay the menu.
Timeout is a tricky one. The standard choices for handling a customer that doesn’t press any keys are to repeat the menu, hang up or transfer to an agent. None of these is very good.
- If the customer walks away from the phone (it does happen), you’ll be playing that menu forever, and paying for the privilege
- Hanging up on the first timeout is cruel, as your menu might be confusing, and the customer is trying to figure out what to press
- Sending the customer to an agent on timeout provides a backdoor that gets discovered, and posted on the web.
It’s possible to add logic to the timeout so you repeat the menu once or twice, then choose alternate treatment. I’ve worked it out for Amazon Connect, and it’s not pretty. A timeout count on the menu block would be a useful addition.
As a rule of thumb, I try to do the following:
- I put the initial greeting in its own box. This way, if the first menu is repeated, I’m not thanking them every time
- 5 or less options in a menu, no more than 3 menu levels deep. Now, it’s not a hard and fast rule, but it’s a good guideline. By the way, If I need a language selection at the top level, I don’t count that as a menu level
- Provide an option to replay the menu (“Press * to repeat this menu”). What may be obvious to you may not be obvious to the customer
- When you get beyond the first menu, provide an option to get back to the first menu (“Press # to get to return to the initial menu”)
- At the appropriate time, provide a zero out option or an explicit option to reach a human. The right time is when the customer has navigated to a menu that will get them to the correct department regardless of what selection they make. Before then, you’ll just end up having to transfer them, and that’s not a good idea.
Can I Build My Menus?
Well, of course. This one was kind of a gimme.
I’m not crazy about the current state of the tool when used to build the menus.
Building and critically, maintaining menus is fundamental to an IVR, and I would have preferred a menu block with more functionality. I’m going to do the same thing for my timeout, default and error handling on every menu. I’m going to provide the same keys to repeat the menu and return to the first menu. And better timeout handling options should be built in.
Still, I can make it do what’s required.
What I Didn’t Cover
What I described above are the basics. I add metadata in my IVR menus to provide a means to classify the call for analytics, and to make it easier to discover IVR issues that result in poor customer treatment. It’s outside of our scope. I’ll just say that it will make a messy IVR diagram even more cluttered.
1Audio for telephony follows the G.711 standard. It passes audio in the range of 300-3400 Hz, and encodes it as an 8 bit sample, at a sample rate of 8 kHz. That’s what you get when you are following a worldwide digital standard from 1972.
2Speech Synthesis Markup Language (SSML) defines additional tags that you can add to text to make the speech sound more natural. You can choose specific phonetic pronunciations, different pauses, add emphasis, change pitch, etc.
3DTMF stands for Dual Tone Multi Frequency, a.k.a the beep boop tones your phone makes when you press the keys.
4A little time with The Google will show you how deep the hated is. One example can be found at Ars Technica, one of my favorite tech blogs. Read this post titled, “Automatic voice recognition for “customer service” – how much do you hate them?” Zero (“0”) percent liked them. I must point out, though that 13% of the respondents of that survey chose, “Ketchup on a steak taco is the one true superfood.” Joke selection aside, the truth is in the comments.
Standard Disclaimer – My comments are based on Amazon Connect at the time of posting, and I endeavor to be accurate. The nature of SaaS is that there can be improvements and changes at any time. If I’ve got something wrong, please let me know, and I’ll correct.