Callers Objectives and Needs

Callers ' Objectives and Needs

Users of these systems also have goals ”but those goals are usually different than those of the service provider. To design a system that is well received by the intended audience, it's necessary to understand the following.

The application need: Why will callers call? (E.g., because they don't have the ability to go to a branch of their bank in which to perform basic banking tasks during normal business hours, thus requiring off- hour service.)

The application objective: What will callers hope to accomplish with the system? (A basic banking application should allow a vast majority of callers the ability to perform all the tasks that they associate with basic banking, and perhaps more. However, systems that don't satisfy callers' objectives won't be well received and may be underutilized .)

The caller's profile: What are the demographic attributes of the callers? What is their skill/education level, background, familiarity with technology, and so on?

The caller's frame of mind: Will callers be angry ? (If they can't get the information they want easily.) Anxious? (Because they lost their credit card.) Excited? (Because they're booking a vacation.)

The most fundamental question to ask ourselves about callers is: Who are they? Often callers are the clients ' current customers, employees , and business partners . But not always. Sometimes a company wants to appeal to a new group of people ”or the application is so new that there is no existing caller base. What difference does it make who the callers are? A lot ”because we all speak in different ways to different people. How we speak to friends is different from how we speak to strangers. And when we're trying to sell something rather than provide service to an irate customer ”again, we speak differently.

What do you need to know about the callers to design a system? A good starting point is basic demographic data ”age, gender, education, income level, and so on. This information will tell you whether the caller population is homogeneous or heterogeneous, and help you sharpen your focus on particular elements of research. If there were, for example, a system that served two different types of callers, hurried business people and the elderly, perhaps the system would have to try to accommodate these different users. If the caller population includes two or more groups with divergent needs ”for example, business partners and direct customers ”you need to create a system that quickly identifies each caller and sends them down appropriate paths.

Knowing who the callers are ”and their relationship to the client ”is the first essential step for us to understanding them. The best system designers take the time and effort to really get inside the heads of prospective callers. What do callers expect from the call? What do they want to accomplish? What is their mental state? Are they looking for fast answers or more personalized interaction? Will they need calming reassurance or "just the facts?"

How callers think about their tasks can make a big difference. For example, a bank that prohibits callers from talking to an agent before entering their 15-digit account number may receive many complaints from people who have lost their cards and urgently need a replacement. These callers are typically upset, want quick service, and won't have their account number memorized ”thus preventing them from getting an expedient resolution to their problem. This system fails to help them efficiently resolve their problem.

But how do we get this more detailed information about caller needs and attitudes? One obvious way is to ask the service provider. But it shouldn't end there. Human nature being what it is, service providers aren't always the most reliable source of information about their callers and their feelings. A credit card provider may not have ever considered the mental state of callers who have lost their credit cards and how that relates to the design of a system. The touchtone system of the credit card division of MBNA America Bank ^[1] requires the caller to listen to prompts for approximately 45 seconds and asks for the credit card number. (Note that if the caller presses "zero" too soon, the system says "Sorry, that account number wasn't recognized," and then starts to play some options.) Eventually a list of five options is played , where the fourth one is for a "lost or stolen credit card." This process can take well over a minute ”an eternity to a frustrated and concerned caller. And while callers might understand that the very first option of the system may not be "Press 1 for a lost card otherwise , please enter your credit card number," they will be a little frustrated by the time the system very calmly, and with a few too many words, tells them that the next available representative will help them. Even on their Web site, the home page and the 622-word site map have no reference to lost or stolen credit cards.

^[1] Based on the system design as of August 31, 2002.

Perhaps their card members don't lose many cards, and if they do they're very calm about it. But if we were to examine how people react when they lose a credit card, we'd imagine that they're not calm, nor are they willing to do much more then press the zero key on a phone repeatedly, or do a very cursory search on a Web site. If we contrast this design to the Web site offered by MasterCard Cardholder Solutions, Inc. (http://www.mastercard.com), we'll find that on the home page, the first option in a list of eight is for "Emergency Services" ” clicking on that provides comprehensive text with a large-type phone number (1-800-MC-ASSIST). ^[2] Do both of these companies satisfy their users? And how does a designer know what to do when there are competing ideas about how to treat the caller?

^[2] Based on the Web site as of September 1, 2002.

A very good way, of course, is for us to go straight to the callers themselves .

As designers, we must directly observe how callers currently interact with the service provider. Obtain touchtone and Web data when possible. Visit call centers and listen to live calls. Interact with callers directly via focus groups or questionnaires. There's no such thing as too much user data (unless the process of digesting it slows down the designer too much). It's all worthwhile ”and it all enhances our ability to be the caller and build a better system.