Friday, April 24, 2009

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.

Saturday, February 14, 2009

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.

Saturday, January 10, 2009

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.

Monday, December 22, 2008

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?

Monday, November 17, 2008

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

Thursday, July 17, 2008

Follow up study to be presented in SpeechTek

Susan Hura, one of the head organizers of SpeechTek this year just posted following on the VUIDS Yahoogroups group:
For those of you coming to SpeechTEK next month, Tim Pearce from Dimension Data and Mike Bergelson from Cisco are going to present year 2 data from the Alignment Index at the conference. We're kicking off the Business Goals track with this session, Monday, August 18, 10:15-11 AM. We'll also be hearing about a similar study conducted in the EU by VoiceObjects.

Here is a link to the session.

Tuesday, July 15, 2008

The Parallel Worlds of Vendors and Users

Just came across a fascinating study by Dimension Data (in collaboration with Cisco) on the perception gap between "vendors" and "consumers" of speech-enabled self service solutions. By "vendors" the study refers to platform developers, system integrators, voice application developers, and speech technology vendors. 128 such vendors were surveyed for the study. By "consumers" they refer to callers who have interacted with speech-enabled self-service applications. They surveyed 1,203 such consumers.


Misalignment

The key findings revolve around 6 questions:


(1) How often would you prefer to use a speech recognition system rather than a touch-tone system? 9% of vendors answered "As little as possible," while 45% of users gave that answer. A huge disconnect. On the flip side, 47% of users gave a qualified "Yes" -- that is, they would prefer speech under some circumstances (depending on time of day, where the caller is, etc.), which tells us that users are not necessarily reflexively rejecting speech-enabled automation under all circumstances.


(2) What do you think is the main reason organizations provide automated services in their call centers? 69% of vendors said "to save money" compared to 54% of users. In other words, callers are no dupes: they fully understand what motivates to deployment of these solutions.


(3) What do you think is the most important benefit of using an automated system when you phone a call center? 51% of vendors mentioned "to avoid wait time" while 49% of users mentioned "24 x 7 service" against 18% who mentioned "Avoid wait time"! A remarkable mis-alignment and a clear opportunity for marketers and designers to exploit for increasing adoption.


(4) In general, when you've used a speech recognition system, which of the following best describes how well it helped you deal with your query? 77% of vendors said that it "Partially addressed the reason I called" while only 43% of users did. Another large gap. 2% of vendors responded with, "Did nothing I needed," while 13% users gave that response. Again, another noticeable gap that points to excessive optimism from vendors. On the other hand, only 8% of vendors responded with "Fully addressed the reason I called," while 18% of users gave that answer. In other words, it seems that vendor answers are driven by mushy conservative wishful thinking rather than insight into actual user reception.


(5) Having used a speech recognition automated system, would you now...? 44% of vendors responded with, "Be neutral to use one again" vs. only 28% of users giving the same answers. What is noteworthy is that a greater proportion of users (36%) responded with "Be happy to use one again" vs. 32% of vendors giving that answer, and a greater proportion of users (also 36%) responded with "Be reluctant to use one again" vs. 24% from vendors. In other words, just like question 4, users are more opinionated and have a less neutral disposition than vendors.


(6) The thing that annoys or irritates me most about using an automated speech application is when.... 41% of vendors answered with "System didn't understand me," vendors' number one answer, while users' number one answer was, "Transfer to agent with no context." This is a fascinating disconnect. Only 17% of users responded with, "System didn't understand me." Which simply means that it's not speech recognition that users find annoying or irritating, but the experience with the application: an additional 16% of users said, "Can't skip ahead" and 14% said, "No alternatives". In other words, 67% of dissatisfaction revolves around the experience with the application. Vendors by contrast focused on technology, in this case ASR and CTI ("Transfer to agent with no context" receiving 38%). "Can't skip" received 4% and "No alternative" a mere 1%.


The report gives a couple of general recommendations such as establishing "cross-functional engagement within organizations" and ensuring "contributions from non-technology stakeholders, e.g., marketing, customer services, and usability experts." But that is no revelation to anyone who seriously engages in voice user interface design.


What would have made the study complete would have been including a third category of stakeholders: the companies that deploy these applications -- i.e., the actual customers of the vendors. I suspect that since many of these customers are sold on the value of self-service applications by the very vendors surveyed in the study, a parallel mis-alignment between customer expectations and those of the ultimate users also holds.


The authors promise to run the survey year over year. Let's keep our eyes open. Hopefully, vendors and customers will read the report and will begin to actually align their goals and values along those of end users.