12.1 Efficiency

Callers' perceptions of the efficiency of an interface reflect a number of system characteristics. Clock time, although it has an effect, is less salient than a number of other measures. One such measure is the number of interchanges required to get the job done. Another is pacing, measured by the latency between the time a caller finishes speaking and the beginning of the next prompt. If these delays are much longer than what callers have learned to expect in human-to-human conversation, the dialog starts to feel sluggish and inefficient.

The single biggest barrier to the perception of efficiency is repeated requests for the same information. Many deployed systems request information such as name and account number when they transfer the caller to a live agent or to another service, even when that information has already been supplied earlier in the call. Callers find this tremendously frustrating. Such behavior by the system creates an image of the service (and, to some degree, of the deploying company) as unintelligent, inconsiderate, and uncooperative, as well as inefficient.

Poor efficiency can lead to reduced task completion because impatient callers are more likely to hang up. It also results in longer call durations (which increase costs), lowered user satisfaction, and even a reduced level of attention by the caller.

Many of the guidelines for improving the efficiency of interfaces are simple and obvious. But because they are often violated in deployed systems, we briefly review some of them here.

12.1.1 Don't Lose Work

The first rule of thumb is to avoid the problem just cited: Don't ask for the same information a second time after it has been gathered successfully. The reason deployed systems make such repeated requests is that it takes infrastructure (e.g., integration with a CTI system) to communicate information gathered by the application to the screen of a customer service agent. Sometimes it simply does not make economic sense to provide such infrastructure. However, it is important for managers to make that decision with full awareness of the significant impact such a decision will have on caller satisfaction.

There are other reasons callers may lose work. For example, if they are in the middle of specifying a transaction or filling in details of a form (e.g., parameters of a trip they are planning) and they navigate elsewhere in the application (e.g., by going to the main menu or jumping to some other part of the application), they may lose the information already entered.

This latter problem can be avoided. Whenever a command might result in lost work, the caller should be alerted and provided with an opportunity to cancel the command. This same guideline is typically followed by software utilities (such as word processors): When users try to exit a system without saving the latest version of the file they have been editing, they are alerted and offered an opportunity to save the file.

12.1.2 Make Frequent Tasks Efficient

The next rule of thumb is to focus on making the most frequent tasks the most efficient, even at the expense of making other tasks less efficient. For many applications, the 80/20 rule applies: In short, 20 percent of the functionality is exercised 80 percent of the time. Optimizing frequent tasks may require changes in the structure of the dialog or in prompt wording. You may also have to change the order of presenting menu options or list information.

For example, consider voice-activated dialing (VAD). A VAD system must place calls as well as manage the user's call list (e.g., allowing users to add names to the list of people they can call). Most of the time, the user is placing a call. It's best to accomplish this task directly and simply, even at the expense of adding a step for users to get to the call-list management facility.

12.1.3 Provide Shortcuts

Some systems, such as personal assistants, are designed for repeated use. As callers become familiar with a system, they lose patience for listening to instructions about features they already know how to use. They also prefer to get their work done with fewer steps. You should provide shortcuts to let frequent callers navigate your system quickly and complete their tasks.

To teach callers about shortcuts, you can use hints. For example, if a personal agent system allows dialing from the top-level menu but a caller is taking a less direct route, tell the caller about the more efficient way to perform the operation. The hint might read as in example (1).

(1)

SYSTEM:	What would you like to do?
CALLER:	Place a call.
SYSTEM:	Who would you like to call?
CALLER:	Steve Smith.
SYSTEM:	Okay, calling Steve Smith. By the way, in the future you can save time by requesting a call directly at the main menu. Just say, "Call," followed by the person's name.

Do not repeat hints very often, and do not provide hints if the caller has ever used the shortcut before.

12.1.4 Use Caller Modeling to Save Steps

Knowledge about a caller may be useful in reducing the number of steps required to complete a task. For example, a travel application that uses caller profiles can use knowledge about where callers live and places to which they typically travel to reduce the amount of information they must provide when making travel arrangements. Similarly, knowledge obtained earlier in the current call (the call history) can be used to make the interaction more efficient later in the call.

The dialog in (2) shows an interaction with a travel planning application in which the system uses both call history and caller profile. The profile includes things provided explicitly by the caller, such as home address, as well as things learned implicitly from previous calls or earlier in this same call.

The caller states her destination city, but no city of origin. Rather than prompt for origin city, the system gets her home address from her profile and assumes that she is traveling from her home airport. The confirmation prompt makes the caller aware that the system has assumed the origin city. If it is wrong, she can change it.

The caller specifies New York as the destination. New York is served by a number of airports. The system assumes Kennedy Airport based on earlier experience with this caller; she often books flights to Kennedy Airport.

The caller requests a rental car. Her preference for midsize cars from Hertz is included in her profile. The system assumes she wants it available soon after landing at Kennedy Airport, basing that assumption on information obtained earlier in the current call. Again, the caller is made aware of assumptions in the confirmation prompt and can make changes at that time.

(2)

SYSTEM:	Where are you traveling?
CALLER:	I'm going to New York.
SYSTEM:	When do you want to leave?
CALLER:	Wednesday, March tenth, around one p.m.
SYSTEM:	Just to confirm you want to go from San Francisco International to New York, Kennedy Airport, on Wednesday, March tenth, leaving around one PM. Is that right?
CALLER:	Yes.
SYSTEM:	Great. Hold on while I check available flights <pause> There's an American Airlines flight leaving SFO at 1:20 p.m. and arriving at JFK at 9:30 p.m..
CALLER:	Please book it for me.
SYSTEM:	Okay. You're booked on American Airlines Flight 825, leaving SFO at 1:20 p.m. and arriving at JFK at 9:30 p.m. on March tenth. Now, would you like a return flight?
CALLER:	No.
SYSTEM:	How about a rental car?
CALLER:	Yup. I'll need a car.
SYSTEM:	I can reserve a midsize car with Hertz for thirty-four dollars a day. Is that okay?
CALLER:	Yes.
SYSTEM:	Great. I have a midsize car reserved for you with Hertz. You can pick it up at 9:30 p.m. on March tenth, at the Hertz desk at Kennedy Airport.