To allow expert users a short cut to the two-question solution, mixed initiative yes-no questions are easy to build.

• Do you know the check number?

Some users may answer, "yes, it's check number 406." This is called a mixed-initiaitve reply because the user has initiated a new answer to a question that you haven't yet asked. These users are now able to answer both the yes-no question and the follow-on check number question in a single turn.

The core problem with MI solutions is that callers must experiment to discover that they can answer in a more flexible way, so most callers will never take advantage of the shortcut. On the other hand, this solution is forgiving when users do experiment.

Another solution to the problem of yanking back the turn is to split one prompt into two. Instead of:

• What is the check number? ... or say, "list my recent checks."

Ask the user explicitly, and use "yes-no" to bifurcate the population:

• Do you know the check number?

If the user answers "yes," drop to the prompt that solicits the number. "Then say the number now," or just "what's the number?" If the user answers "no," then follow-on with the alternative dialogue, "Here's a list of your recent checks ..." The population has been divided into those who know and those who don't know, leading to a different follow-on dialogue.

The problem with this solution is that ALL users now must pass through two questions instead of one.

One simple solution to the problem of yanking back the turn is simply to invert the question. Instead of:

• Say your account number, or say I don't know it.

Reverse the two parts of the question:

• If you know your account number, say it now.

With this solution, the conditional part of the question comes first, and therefore does not have any turn taking implications. The user has no answer to "If you know your account number ...." and so does not perceive that it's her turn to talk. The following imperative sentence, "Say it now" becomes the sole turn taking juncture.

The core problem with this solution is that it leaves users hanging if they don't know their account number. The 80-20 rule applies here. As long as most callers know the number, then this solution is acceptable. Most callers who don't know the answer infer correctly that their job is simply to wait silently.

There will be few OOG utterances (although you still have vulnerability to background noise). In most cases, those who don't know the number are served more slowly, but the majority are served quickly.

Last time I talked about the challenge of helping users who may not know how to reply to a prompt. The same solution is often applied to a related challenge -- offering additional options after a short pause:

Please say the name of the Acme product for which you want technical support ... (3 second pause) ... You can also say, "repair status," or "find a store."

It has the same basic flaw, doesn't it? The design yanks back the turn. Indeed, you can think of this specific design solution as a common knee-jerk response to a broad, general prompting puzzle. What do I do when I have a simple prompt -- one that is appropriate to a large subset of my users -- along with a collection of special cases? The solution of generating two prompts separated by a pause is almost always weak. You can find many examples:

• What is the check number? ... or say, "list my recent checks."
• When do you want to pay? ... say a date, or say "today."
• Please say the date of the claim. ... for example, "January thirteenth, two-thousand eight."

As you can see, the same flawed solution is used for coaching, instructions, examples, alternatives, special cases -- anytime it seems appropriate to add "a little extra" to a prompt with the goal of "clarifying" expectations.

As you consider some possible solutions, bear in mind that the core problem is a turn-taking problem -- the machine asks a question and then yanks back the turn.

Here's a common quandary. You want your user to give you a piece of information. Many (sometimes most) users know the information. BUT, some don't. Those users need a different instruction. A common solution goes like this:

Say this ... (arbitrary pause) ... or [you can] do|say that.

It seems an obvious solution, and, indeed, it is often difficult to arrive at alternatives. So we see the solution in play in all sorts of contexts:

• Say the name (of the person you're calling) ... or say, "What are my options?"
• Please say your account number ... if you don't know your account number, say ...
• Please say the flight number ... or say, "I don't know it."

This is an example of "yanking back the turn." The first part of the prompt -- the direct request for input -- represents a full machine turn. Having asked for some data and turned the floor over to the user, correct machine behavior is to shut up and listen to the answer. But it's not possible. Because SOME users won't know the answer, and timeouts, OOG, and confidence problems will dominate the interface. So we offer the follow-on "additional" information to "help" these users.

Well, of course, the solution causes all kinds of turn-taking problems. Users start to speak, stop, and then restart as they fight over the floor. The machine makes state changes that are invisible to the user. Error amplification ensues.

Many designers fuss over the duration of the pause. Making it longer might alleviate turn-taking stumbles among the slower responders. Making it shorter might fuse both instructions into a single turn, allowing users to choose which response to give. But, of course there is no "best" pause duration -- the problem is the fundamental design of giving and then yanking back the turn.

In the next article, I'll talk about some solutions to this design problem.

Customers always appreciate as much information as possible. More, accurate, information is never bad for customer service. Inaccurate information however is always a problem when announcing wait times. The greatest difficulty that most of our customers have with this issue is actually providing customers with accurate data due to two things:

• Different queues have different wait times.
• Skills-based routing plans are often too complex to predict the actual wait time for a given call.

The second point is important. Queues often have multiple skills assigned to them in the call routing plan which can confuse any prediction of future wait times.

Our suggestion would be to approach the problem one step at a time:

Find out what level of detail you can actually get regarding queue time data for each queue. How accurate is it? Devise a plan to announce the queuing time at a level that is accurate enough given your information source

In general we would suggest that queue times under 60 seconds should not be announced. Over that, granularity in minutes is helpful but you can be rougher – e.g. ‘up to 5 minutes’, ‘up to 10 minutes’ for example depending on the quality of your data source and technical infrastructure.

For long wait times, abandons will increase at the announcement point. It is very hard to ascertain whether this increases or decreases customer satisfaction over the alternative but you need to be careful to bear this in mind when analyzing statistics. For example these abandons may show up as containment in your containment statistic.

One final thing to consider. It makes a major difference to customer satisfaction if you can offer to ring customers back when wait times are over a certain amount (say 5 minutes). This has a significant impact on customer satisfaction but only if it can delivered at a realistic service level. Call center operations generally find these kind of commitments very difficult to meet which is why is this solution is seen rarely in the marketplace.