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.