Citi bank IVR

You've seen those commercials where they make noise about how when you call Citibank, you won't be tortured by an IVR? Well, not quite: I've called them a dozen times this week trying to resolve an issue, and every time I call, their IVR asks me to enter my 16 digit number to "expedite" my call. Fair enough. The thing is that every single time I've called, the representative has asked me to give them the number again. When I told them that I had entered the number already, the more polite ones apologized, claiming that it was not coming through, while the ones with less patienve straight out hung up on me.... Wow!!!

Randomising prompts...

Zeno from the VUIDs group asked the following question:

I am thinking about Random Prompting. For me, this feature always has two sides:(1)It can make an application much more human-like, since humans also tend to formulate a certain question/information in different ways.(I know, there are very contradictory opinions, wheter a system should behuman-like or not. But IF you want to have system human-like, Random Promptingcould be an effective way and it's easy to implement). (2) On the other hand, it hinders the user from creating a "mental map" of thesystem. This could especially be bad for power-users but also for situations,where the user returns to a certain place within one dialog/call.Does anyone have had experiences with random prompting, or even startedexperiments? Would be very interesting...

I would say that randomization for the sake of variability is not a compelling reason -- in fact, I would say it is self defeating since the caller may be thrown off by the seemingly purposeless variability. On the other hand, purposeful variability is a good thing when done right -- e.g., personalization. I would rather that the system anticipated my need and proposed an option rather than safely provide me with a main menu -- e.g., "Are you calling about the status of your recent on-line purchase?" I think in such cases, the potential fast-tracking is worth the mental map disruption....

An interesting response was from Eduardo Olvera, who wrote:

Even though I agree with the points mentioned below about Dynamic Prompting and Design in general, I think there are actual appropriate uses of random prompts (by random meaning prompts that are pulled from a pool of possible prompt alternatives, not prompts that are driven by context or dynamic values). For example: (1) During user identification and/or authentication - asking callers to repeat a random sequence of letters, or asking a random security question from a set, for the purpose of increasing the security of a system (e.g. if someone listens to the answer to your question, they shouldn't be able to call back in and authenticate with the answer they just heard)

(2) To provide tips and/or information once a caller has successfully completed a task or when, based on the context, it makes sense to present information the user might not be aware of - for example, if a system contains many features, or is constantly updated/enhanced, having "By the way" type of prompts at the end once a task has been completed and the user is likely to simply hang-up, it is sometimes useful to present those tips to educate callers about features/services they might not know about

(3) When attempting to help users recover from a situation that might take place so early in a call that we might not know anything about the intent, which the user might visit more than once, and which furthermore might have so many different possibilities that it would be hard to only offer a narrow set of subchoices. For example, on a Natural Language Main Menu Router (SLM), sometimes it is helpful to have a handful of random prompts, each with a slightly different set of suggestions/examples

(4) When trying to break the monotony of repetitive exit prompts that serve a particular purpose but that might not have a direct impact on the outcome of the interaction. For example, on a learning system, if you're asking your user to follow a certain sequence of steps and you're trying to encourage them along the way, it's helpful to have a random set of prompts with various "encouraging" short messages like "That's it", "Perfect", "Nice", "Good job", etc. so that you don't play back the same message over and over again, making it even more apparent that you're dealing with an automated system

Closing the Dialog -- Part IV

11. Reassure users of success

If the main purpose of the call was to execute a transaction and the transaction was successfully completed, repeat to the user that the transaction was successful, and if possible, let them know that a follow-up confirmation will reach them. Ideally, an email detailing the transaction should be sent. This email will serve as a reassuring, visible, warm-and fuzzy and will go a long way towards reducing the number of calls from people who just want to make sure that the stupid IVR system did do what they wanted it to do.

System: Great! We are done! You should receive an email shortly detailing your transaction. Thanks for calling. Goodbye.

12. Don’t provide any crucial new information

Whether the call termination was initiated by the user or the system, try to avoid announcing anything new or important at the call-closing prompt. After the user says, "Goodbye", their attention to what the system is saying is minimal. At most, repeat some piece of information before closing with "Goodbye": e.g., "Remember, your coupon is valid only through June 30th, 2008."

13. Turn barge-in off

Since information will be flowing only one way – from the system to the user -- during the closing of a dialog, turn barge-in off to ensure that the closing prompt is not interrupted.

14. Give the user a quick tip

If the user had to traverse a deep menu to reach the option they selected, the system should tip the user on how, next time they call, they can make their selection with an easy to remember simple shortcut. The shortcut could be a DTMF sequence or a simple, easy-to-remember phrase. It is important, however, that the tip be provided quickly, at the very beginning of the closing sequence, before the user stops listening.

15. Offer to call back

If the system determines that the user needs to wait 3 minutes or more to speak with an agent, then offer the user the option to be called back by the system when an agent is freed up to speak with the user.

16. Explicitly mark that the dialog is over

Once the dialog termination sequence has been initiated, the system should explicitly inform the user that the dialog is over. The system should never simply hang up.

System: Great! We are done! Thanks for calling. Goodbye.

Closing the Dialog -- Part II

4. Provide the option to cancel a transfer to an agent

After providing the user with an estimate of how long it will take them to reach an agent, provide the user with the option to cancel the transfer and to either return to the self-service dialog or to leave a voice mail.

5. Keep the “while you wait” recording relevant

Users hate to be placed on hold. But what they hate more is being forced to listen to marketing pitches that are not relevant to their needs. Recordings that you play while the user is waiting need to be geared towards helping the user solve the problem they called about – or at the very least, they need to be relevant in some way to who the user is. For instance, if the user is the user has a dangerously low checking balance and the system determines that they are in danger of bouncing checks, the system can suggest to the user to request from the agent information about the overdraft protection plan.

6. Keep the user’s state of mind when you play the “while you wait” recording

Make sure your system is sensitive to the emotional state of the user. If the user is likely to be frustrated or angry (for instance, they are opening a new ticket or want to get the latest status of a ticket they opened), having the system boast about how the company had just won an industry award is likely to trigger a sarcastic sneer from the user.

Closing the Dialog -- Part I

Dialogs with IVR systems end in one of five ways: (1) the user hangs up, (2) the user requests to end the dialog, (3) the user requests to be directed to a human agent, (4) the system determines that the dialog has reached its end and decides to end the call, or (5) the system determines that the user needs to be directed to an agent.

There is little that the system can do in reaction to case (1). For the other scenarios, we provide in the next few posts some guidelines that should be kept in mind on how to design the closing of a dialog.

***

1. Allow the users to explicitly end the dialog

In a dialog contexts where a valid user option is for the user to simply hang up (e.g., after they have successfully executed a transfer and are back to the main menu), let the user know that they can say, “goodbye” or simply hang up. Make sure you include the option of saying “goodbye,” since many users find it unnatural (and impolite) to end a conversation by simply hanging up.

System: Main menu. You can say, “Check balance”, “Withdraw funds”, or “Transfer funds.” If you are done, you can say “Goodbye” or simply hang up.

2. Allow the user to request a human agent

You should let users know, especially when they are having trouble using the system, that they have the option to be connected to an agent.

3. When transferring and the user has to be queued, provide a waiting time estimate

If transferring to an agent, provide the user with an estimate of the time the user will need to wait prior to talking to a human.

Please listen carefully as we don't really care how awful our IVR is...

You've heard them enough times, and if you are like me, you cringe every time: "Your call is very important to us," they say, and then they keep you waiting and waiting; "For English, press one," they insist on telling you, even though you've called them a hundred times and every time you pressed – that's right -- one for English; then there are those little phrases you've heard so many times that your ears don't event bother to pick them up any more – ones like, "You can interrupt me at any time" or "Please select from the following menu options."

But there is one particular little gem that, in spite of the thick skin of my ears, still gets my goat. I'm talking about, "Please listen carefully as our options may have changed!"

I would say 9 out of 10 of the IVRs I call these days have this phrase right there upfront, proudly played as if to signal that you are dealing with a company so dynamic and so cutting edge that its menu options are constantly changing – so, you'd better pay attention lest you get hurt.

The sad thing is that almost 100% of the time the phrase is played, nothing had really changed in the IVR menu for months – and in some cases, the phrase is inserted from the very beginning of the IVR deployment!

So wherefore the horrid little habit?

A good guess would be that it started legitimately enough when menus did change and power users skipped ahead without listening to the new options, resulting in confusion and complaint call backs about how the system was broken.

From that point on, my guess is that the context of the inclusion of the phrase falls into one of the two scenarios: (1) the voice user interface (VUI) "designers" were rank amateurs and therefore proceeded like all tentative amateurs do -- that is, by playing it safe and methodically and carefully imitating "what is out there," or (2) the VUI was designed by professionals who knew better than to perpetrate the atrocity but who were forced to include the phrase by adamant call center managers who perceive the IVR's mission to be first and foremost keeping callers from reaching humans and are therefore willing to throw any verbiage at callers if it forces them to listen carefully to the instruction prompts – i.e., are willing to outright lie to callers about how the menu is constantly changing.

Case (1) is the easier to remedy: if companies were to systematically invest in hiring professionally trained VUI designers and would take the development of their IVR as seriously as they do their web site, the phrase will at long last set itself on the path of extinction.

Case (2) requires a bit of a struggle. If you are a VUI designer and find yourself battling an arrogant, all-knowing call center manager who insists on including the phrase, here is how I would suggest you proceed.

First, point out that power users do not listen to prompts – they know what to press and they start pressing as soon as they realize they are connected. They will certainly not notice the white noise language of, "Please listen carefully as our options have changed" -- especially if it is played every time they call. The only way power-users will learn that an option has changed is for them to get lost once or twice.

Second, point out that even non-power users filter out the phrase if it is played every time they call. After a while, they will catch on that you are crying wolf and will simply tune out your pleas.

Third, propose that if there was indeed a drastic menu change and you desperately needed your callers to notice it, then at the very least, use something far more attention grabbing than flat language to signal the change: a double dings sound followed by an announcement that the menu options had changed, for instance, would be far more effective.

And to close the deal, explain to the call center manager that the best way to contain callers within the IVR is to ensure that they have a great experience with it every time they call it. What if the IVR were to remember who among the callers had already heard the menu change notification and then would act on that knowledge? For instance, noticing that the caller is calling for the first time since the menu change, the IVR would play the menu change alert and disable barge in, hence both ensuring that the caller notice that the menu had changed and forcing them to listen to the new options. And then, next time that person called, the IVR wouldn't play the menu change alert again.

Wouldn't that be more likely to minimize errors and misrouting than playing a phrase that is either not even noticed by the caller or, if noticed, can only needlessly annoy?

Balentine's Brave New World

Been plowing through Bruce Balentine's new Book, "It's Better to be a Good Machine than a Bad Person," and I must say that so far I am enjoying it.

The basic idea of the book is that it's about time that we gave up trying to have machines try to behave like human beings (and do an awful job at it -- bad persons) and started having machines tackle those problems that they can solve well (good machines), and in the process interact with human beings in their capacity as machines rather than pretend to be human beings.

So, as you can imagine, Balentine doesn't like it when a machine tries to act or sound like a human: saying that it's sorry, expressing gratitude, giving compliments, etc. For Balentine, such anthropomorphism not only adds little value to the interaction but in fact confuses and ultimately leads to frustration and disappointment when the the system does not live up to the intelligence the surface anthropomorphism implied.

I am completely sympathetic to the idea of building machines that are true to their identity. Yes: humans do not interact with machines the way they interact with other humans. My only concern is that spoken and heard language are so suffused with the human that expecting a human being to somehow find a way to use it and yet strip away the layers of emotional and cognitive meanings that are fully enmeshed in it is a difficult endeavor, to say the least.

Imagine being interrupted in mid-sentence by a machine: would you help not feeling irritated? Or how would you feel if the system were to order you around with "Give me your contact ID" or "Say that again." As things stand, I wouldn't like it and -- and this is the main point -- I wouldn't be able to help not liking it.

But Balentine feels that sooner or later, we will get to that brave new world where we wouldn't react emotionally when we are talking to a machine. We would know that this is the way to interact with a machine and we would turn our emotional sensors off.

I think what makes this tricky is the fact that the interaction is verbal in both ways. We have no problems shouting orders at machines in a way that we would not a human being; and we have no way accepting cryptic responses from machine when not spoken (ATM menus, Boarding passes). But as soon as we are engaged in a two-way verbal dialog (even when not spoken), we are overwhelmed with the anthropomorphic illusion.

But let's grant that someday we will somehow get ourselves to that point. The question is: how are we to cross the chasm from where we are today to that time when humans will talk to machines in that special human-to-machine way? Will one killer product (iPhone?) or application help us make the quantum leap? Or will we gradually evolve into such a new standard?

Will ramble on some more in future posts as I read and think about this....