Jun. 2000 Issue of
WebBusiness Magazine
A Closer Look Index
BY LOU ROSENFELD
 Louis Rosenfeld is president of Argus Associates, which specializes in providing information architecture consulting to Fortune 500s. He is coauthor of the best-seller, Information Architecture on the World Wide Web. Read previous installments of "A Closer Look." |
hy is technical support so unsupportive? Why is there no uniformity of terms, forcing us to puzzle whether the terms "Technical Support," "Help Desk" or "Knowledge Base" describe what we need? Why don't companies devote more resources toward improving web-based, self-serve support, one of the most frequent tasks performed online?
Like any good American, I have a conspiracy theory: vendors strive to have no contact with consumers, especially those in need. Vendors happily use technology to achieve this goal. In the past, with telephone support, they wasted hours of our lives in Hold Hell. Now they can use more advanced technologies to avoid you online too. There are other, more widely subscribed to ideas about why tech support is often not support at all. Here are three of them.
1. We Don't Really Know What Support Is
Go to a few web sites and click on "Technical Support" (or whatever it's called) and what will you find? Could be a bunch of basic documents describing a product. Or a run-of-the-mill FAQ. Or an interactive tool or "wizard" that helps narrow your question (such as Intel's "Troubleshooting Assistant." Triage applications are increasingly common; they help you send your question to the right expert on the vendor end. Technical documentation like Cisco's is fairly typical, as are user discussion groups and forums where "communities" congregate and attempt help each other with problems that company representatives were unable to solve. Some of these might actually be helpful, but the fact remains: there simply aren't conventions to help users know what kinds of content to expect from support areas and how those areas are navigated. In my opinion, a lack of a consistent content and architecture among and within support areas may be the biggest reason users fail to find information they need.
2. Technological Fetishes Distract us from the Real Problem
IT professionals like cool applications. And IT professionals who work in call centers really like applications that promise, no matter how egregiously, to eliminate wetware.
This isn't surprising; many support operations, facing a hyper-competitive job market, are trying their darndest to slash payroll and let technology take over the jobs of humans.
These wholly technical solutions wholly miss the point.
Providing technical support is hugely complex, not unlike the interaction between a librarian and a patron at a library's reference desk. In both cases, the expert needs to identify the source of the question. For the librarian, this means, for example, determining whether the patron is a 10-year-old schoolboy or the chairman of the local school board. In the technical support setting, we must know whether a question comes from a home hobbyist or a senior sysadmin.
Next, we contextualize the question: the librarian needs to learn how the information is to be used (a single title for show-and-tell or extensive research to support a doctoral thesis). Technical support may involve determining whether the answer will impact a stand-alone PC or a globally distributed network of PCs, minis, and mainframes.
Nailing these variables is necessary to answer a question appropriately. But identifying users and contextualizing their needs is not something that software does well. And given the increasing complexity of technologies that companies support, there is a need for greater, not diminished, human expertise. Technical support providers should begin preparing themselves intellectually and fiscally for greater investment in both technical support tools and personnel over the coming years if they wish to remain competitive.
3. Support Faces Heavy-Duty Content Integration Challenges
It is especially difficult to develop a sound information architecture for a web site's support area. Let's take a look at Apple's technical support area.
Apple is doing its best to provide useful content to users, including:
- Product specifications
- Software downloads
- The "TechInfo Library," a collection of various documents
- Discussion forums
- Webified manuals
- Product-specific areas (e.g., PowerMacs, iMacs)
- Localized navigation (e.g., site index, multilingual architecture and content)
Integration Challenge #1 is developing a sound content model that delineates what the appropriate content "objects" are, how they should relate (and link) to each other, and how they should employ metadata (to enable better searching and browsing). The goal of such a content model is simply to make it easier for users to find information they need (and for owners to have a better sense of what content they're actually responsible for managing).
In such a rosy scenario, a user might visit a "product spec" document for an Apple Scanner. From there, the user should be presented with logical contextual navigation options, such as links to "how-to," "bug report," "discussion thread," and other documents that have something to do with the Apple Scanner. The benefit of planning a content model in advance is that many of these links can be generated automatically, a big win in a huge and dynamic content environment.
Integration Challenge #2 involves developing labels that accurately describe content. Right now Apple doesn't seem to have any policies or procedures in place for standard application of labels. For example, product-specific support areas offer some categories that sound useful:
- Get Help
- Connect
- Update
- Service
- Select Other
But what's the difference between "Get Help" and "Service"? Doesn't "Select Other" sound suspiciously like "Miscellaneous"?
The people who maintain the site are probably similarly confused. The options under each pull-down menu, when you can decipher them, seem to be apples and oranges (pardon the pun). Options like "Upgrading RAM" might fit better under "Update" than "Get Help".
Worse labeling problems are found in discussion forums, where postings are generally labeled with the subject line headings keyed in by posting authors.
It's unreasonable to expect users who post questions to select clear and descriptive subject lines. They are authoring content not unlike email: quick-and-dirty and without consideration for long-term use. Yet, many providers of technical support depend on discussion forums as a primary means of helping users, expecting those users to wade through such raw information to find the help they need.
Read previous installments of "A Closer Look."
|
