Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Bad Software: What to Do When Software Fails

Bad Software: What to Do When Software Fails

by Cem Kaner, David Pels, David L. Pels

Avoid technological lemons and be your own consumer advocate.

Most software products are released with known defects. Misleading advertising is rampant in the industry, and few software publishers provide real warranties for their products. And as we all know, most software companies provide woefully inadequate technical support. Quite simply, consumers usually


Avoid technological lemons and be your own consumer advocate.

Most software products are released with known defects. Misleading advertising is rampant in the industry, and few software publishers provide real warranties for their products. And as we all know, most software companies provide woefully inadequate technical support. Quite simply, consumers usually get the short end of the stick in the software industry. Not for long, if the authors of Bad Software can help it. This book pulls no punches in explaining why things are so bad, and how consumers can best stand up for themselves. The authors provide guidance on how to troubleshoot faulty software and when to call for help; exactly what to demand of software companies when defective products cost you time and money; how to ensure a replacement or refund; how best to deal with intransigent companies and their personnel; and much more. Written by industry insiders with software management, technical support management, and legal experience, this book will show you how to fight for your rights and get valuable results.

Companion Web site features legislative and regulatory news and commentary, court cases, and contact information for protection agencies.

Editorial Reviews

Offers advice on how to tackle problems that can arise from a faulty software purchase and reviews applicable laws. The authors explain how to negotiate with the software publisher, bring additional pressure to bear through complaints, and take legal action, if necessary. The last chapter suggests ways to shop for software that reduce the chance of being cheated on the next software purchase. Annotation c. by Book News, Inc., Portland, Or.

Product Details

Publication date:
Product dimensions:
7.53(w) x 9.24(h) x 0.89(d)
Age Range:
9 Years

Read an Excerpt

Chapter 2

Basic Messages of this Chapter Some people are made to feel stupid when they call for technical support. You are not stupid. It's not your fault that the program doesn't work. It's not your computer's fault that the program doesn't work on your computer. You spent good money to get a program that works, not to get a new hobby called Troubleshooting 101.

The customer support technician that you're talking to is an innocent vic-tim. Most of these technicians genuinely want to help you, but their hands might be tied. Don't fight with them; find a way to cooperate.

This chapter looks at the business decisions that go into making software programs. Asking for proper service from the publisher will be easier once you understand that problems probably result from decisions the publisher made with its eyes wide open. Some service technicians make people who call for help feel stupid; sometimes this is a deliberate tactic, sometimes not. Don't take it personally. The problem you're facing is a business prob-lem; deal with it at that level.

This chapter also starts our effort to help you evaluate whether you're get-ting good service from the publisher. At some point, you may have to de-cide whether the publisher is treating you fairly. If not, your strategy might be much harsher than if you think the publisher is making honest mistakes.

THE CHAPTER ADDRESSES FOUR KEY QUESTIONS: 1. How are problems handled? (Are you getting service or excuses?)
2. What's the business situation? (Publishers make trade-offs knowingly.)
3. Is it "shelfware?" (Are you being played for a sucker?)
4. What are your rights? (Quick overview of some law.)

How Problems Are Handled Imagine that you buy a radio only to discover when you try to use it that one of its buttons doesn't work. Naturally, you'd take it back. The people at the store would say, "Oops, sorry," and either fix it immediately or give you a new one. Let's further imagine that this model is bad, that all these radios have this button that doesn't work. You'd ask for a different model or for a refund. And, the people at the store would say, "Certainly."

Suppose, however, that the people at the store didn't want to give you a refund. Instead they said, "The radio works. Just hold it upside down and press these other two buttons. Then this button will operate. This feature helps you stay in shape by exercising your hands and fingers." You'd say, "You must be kidding. Give me that refund." If they still wouldn't give you a refund, you'd feel perfectly justified in complaining to the store manager, the Better Business Bureau, the manufacturer of the radio, the newspaper, all of your friends, and your county or state's consumer protection department.

When you buy a computer program and one of its "buttons" doesn't work, life can be just that challenging. Here are some of the key problems that you and the industry face:

It is impossible to write defect-free software. (Software defects are called bugs.) It is also impossible to fully test a program. No one can find and remove all the bugs. So, every program has bugs; in theory, you could demand a re-fund for every program you own.

Many retailers actively discourage customers from returning software, even if it is defective. Some companies even publish a policy that says they can't take returns because that would violate the Copyright Act. But, there's nothing against taking returns in that act. The Copyright Act restricts software rentals; giving a refund to a dissatisfied customer is not a rental situation. (See the analysis in Central Point Software, Inc. v. Global Software & Accessories, Inc., 1995).

Retail salespeople rarely know how to help you make the program work. Face it, these underpaid salespeople are rarely computer experts. And, even the savvy ones have a hard time keeping up with all of the programs that the store sells. Result: You'll have to direct most of your questions and complaints to the publisher rather than to your local retailer.

Software problems can be subtle and, thus, difficult to troubleshoot. For example, a normally reliable program might crash only if you use it with a particular mouse, video card, and certain versions of the programs (drivers) that make the mouse and video card work. Use a different card, mouse, or driver, and you won't have the problem. A problem that is obvious on your computer might seem odd to the publisher's technician. Skilled technicians make it a practice to learn everything they can about your computer's components be-cause their advice to you could depend on what you have.

Excuses, Excuses People tend to use the same lame excuses time after time. Here are some of the common ones you'll hear when you try to return bad software.

At the Store

  • The Copyright Act forbids us from taking back software from dissatisfied customers.
  • We can't take the software back because your computer might have given it a virus.
  • We don't understand your problem. You have to call the publisher. If they authorize the return, in writing, we'll take it back.
  • Sorry that we can't answer your questions. You have to call the publisher for technical support.
  • Our policy says we can replace only defective media.
From the Publisher
  • This is the first time we've heard of this problem.
  • Maybe you just don't understand the program. How carefully have you read the manual?
  • What kind of video card (mouse, memory, printer, CD-ROM drive, disk drive, monitor, joystick, modem, and so on) do you have? Oh, that. Maybe that's why your computer doesn't work properly. Call them.
  • That's not a bug; it's a feature.
  • Oh, you're right. This feature doesn't work. But, we have a workaround. Just do this (inconvenient or bizarre thing) and you can get the result you want.
  • We're working on a new version to fix this problem. Call back in six weeks.
  • We have a new version that will fix your bug. Of course, you have to pay $89 for this version because we added lots of features. You don't really think you should get all those features for free, do you?
  • A refund? You have to get that at the store that sold you the program.
  • Of course you can't do that with this version of the program. You have to buy our professional version to do that. With your preferred customer discount, it's only $129.99. Would you like to order it now?

Few people know how to investigate or describe software problems systematically. This makes it difficult for even a conscientious technician to help you, because she has to figure out what you're complaining about.

When you call a software publisher, you eventually will speak to a customer support technician. She has to make several judgment calls during the phone call. Here are some of the questions that an ethical technician might be considering:

  • Have I heard of this problem before? If so, what have we tried before to solve it? If not, what questions can I ask to find out what is causing it and how serious it might be?
  • Is it possible that something is broken in the customer's machine? (A surprising number of people forget to plug in or turn on the computer.)
  • Could I solve this customer's problem by teaching him something about how the program works or by pointing him to a useful place in the manual?
  • Would a reasonable customer be upset about this problem? If not, what's the company's policy on dealing with unreasonable people?
  • Is this likely to be a hardware-specific bug? If so, what is the customer's configuration? Can I help the customer make the program work on that system?
  • How can I find out if some other program is also in memory on the customer's machine and is interfering with this one?
  • What would it take to satisfy this customer?

Note the tone and objective of these questions. Their goal is to get enough in-formation to solve the problem and then to solve it. Many of these questions sound like the excuses in "Excuses, Excuses" (page 15). The difference is in the use of the information. The conscientious technician tries to solve the customer's problem. If she can't find a technical solution, she'll look for some other way to satisfy the customer (refund, exchange for a different product, upgrade to the next version, enrollment in the beta test program, whatever). At excuse-making companies, the technician might still try to find a solution for the customer's problem, but if she can't find one quickly, or if she feels of-fended by the customer (poorly trained technicians are more easily offended by people who are, often legitimately, upset), then she'll use the information she gets from you to push the problem back at you.

Here's a practical illustration of the difference. Suppose that the technician realizes that you don't understand how one of the features works:

The helpful technician asks whether you have the manual handy. If you do, she directs your attention to the relevant section. She might even save you from being embarrassed by reassuring you that a lot of people miss this section. She then gives you an overview of the section or gives you time to scan it and ask questions, or she gives you a direct-dial number to call her back if you have questions. When you hang up, you and she are both confident that you'll understand this material.

The not-so-helpful technician asks whether you have read the part of the manual that explains this feature. If you admit that you haven't, she'll suggest that you do so now. Then she'll say good-bye and hang up. If you say you can't find this feature in the manual, she'll "win" because she can tell you the relevant page number to look on. If you tell her that you did read it but you didn't understand it, she'll say, "Oh" in that tone of voice that implies she has known rocks that are smarter than you. You might or might not under-stand the feature when you hang up, but you definitely get the message: This is your problem, not ours. You deal with it. What do you expect for $100? Quit bothering us!

No matter who you get on the phone, keep your perspective. Be polite, friendly, and reasonable. Don't be embarrassed if you are not an expert at describing and analyzing the program's problems. This is a technical skill that often requires special training to develop. But, be willing to conduct basic troubleshooting, because if you aren't, no technician can help you. Don't let yourself be intimidated. Let the following reminder guide you.

Reminder You are not stupid. It is not your fault that the program doesn't work. It is not your computer's fault that the program doesn't work on your computer. You spent good money to get a program that works, not to get a new hobby called Troubleshooting 101.

Example: A Faulty Interface Card A few years ago, a company sold a computer interface card that did input/ output functions. Let's call this company Brand X. We can't tell you what card this was, so imagine that this card had video display, video animation, sound, or some other capability that people could see or hear.

Brand X advertised its card as being "fully compatible with" (which means, working just like) another manufacturer's card, the industry best-seller. Unfortunately, even though Brand X's card usually worked pretty much like the standard card, the Brand X card's output was distorted, sometimes obviously and annoyingly.

Unfortunately, Brand X had laid off key engineering staff and so could no longer upgrade this card. Oops. As a result, customers who had problems had to live with them or take a refund. No cost-effective solution to the incompatibilities was available, and Brand X had no intention of upgrading the card.

Not knowing how else to respond to the crisis, Brand X's Marketing Department decided to contain it. They specifically ordered the support staff to discourage customers from asking for refunds. They said that the distortion was usually pretty minor and that the complaining customers were just nitpickers.

Furthermore, Marketing ordered the support staff to say that they'd never heard of this problem before, to promise to investigate it, to take the customer's name and phone number, and to promise to call the customer back if they found a solution. Marketing even supplied a form letter to send to complaining customers.

The support technicians were furious about this. They knew full well that they would never call back with a solution. They were just stalling customers, not helping them. Morale suffered. Brand X's middle managers had heated meetings about this problem. Unfortunately, nobody knew how to solve it. Some wanted to do more for the customers (such as offer refunds). Others wanted to stop making the technicians lie to customers. Still others wanted to stop selling the product or at least to stop manufacturing new cards and just sell the last of the stock on hand. In the end, most of the managers weren't willing to just give up on the product and take a loss. So for a while, Brand X kept making and selling these defective cards.

If you had called Brand X with a complaint about this problem, the technician you talked to would have lied to you. If you had escalated the discussion (talked to the technician's supervisor), that person would have lied to you, too. To get a refund (and plenty of people gave up along the way), you had to work your way up the ladder until you finally got to someone with the authority to give you a refund (who might not be able to tell you the truth but could send you a check.)

Until the company finally decided to stop making these cards, the sup-port technicians could follow the company's orders, or they could quit. They had no other choices. You would never have suspected that they were furious about being ordered to do this. You would have done absolutely no good by shouting. On the other hand, you wouldn't have served yourself well by believing these people and putting up with a card that was obviously defective. Too many people accepted this stalling and evasion. Because tactics like these are effective, companies continue to use them.

The Business Situation: Publisher Trade-Offs Publishers make decisions that affect quality, service, and revenue with their eyes open. The odds are good that the problem you're facing is the result of a deliberate decision made during the program's development or during the planning for its technical support. This section identifies and explains some of those types of decisions.

Tip By the time you buy the program, call the publisher, and speak to the technician, quality and service decisions are history. There's nothing the technician can do about them; she probably wasn't consulted about them when the decisions were made, and she probably has been forbidden by the company (which considers its internal decisions to be secret) to even tell you about them. People like you complain because of these decisions, and people like her have to listen to all of these complaints because of these decisions. She's probably as frustrated with some of those decisions as you are, maybe much more so. Don't take out your frustrations on the technician. All you achieve is to hurt her feelings and make her less interested in helping you.

When the publisher makes a deliberate trade-off, it expects complaints. The publisher has accepted that the product will not serve the needs of certain customers. It gambles that not many people will complain. The lesson here is: If you want the publisher to make better products in the future, you should complain. that category's market, even when a later release is better. After a product is regarded by customers as a standard, which can happen pretty quickly with a first-to-market product, later competitors might have an extremely difficult time gaining a viable share of the market. (Arthur, 1994, discusses the natural development of monopolies in industries like software.) The publisher also has to trade off money, which it might not have, against customer satisfaction. Every decision about quality or customer service involves trade-off.

Software publishing has become a tough business with established, entrenched competitors. The following numbers, from the early days of CD-ROM-based mass-market software, show how hard it is to market and sell new software products:

  • By early 1995, at least 11,837 CD-ROM titles had been published; many of them were new, published in 1994 (InfoTech, 1995; Swisher, 1995).
  • In 1994, the typical traditional software store carried only about 300 titles, and mass-market retailers carried only about 30 (Steinberg & Sege, 1995).
  • Of an estimated 1,700 CD-ROM titles being released for the 1994 Christmas season, estimates were that only 200 would turn a profit (Steinberg & Sege, 1995).

For many software publishers, distribution has become less certain, and mar-gins have thinned (Software Publishers Association, 1996). Several publishers are making less money and struggling to stay in business. Looking at numbers like these, you can understand why several software publishers have been trying to reduce their per-customer investment in customer care during the past few years.

On the other hand, the market has become huge. In 1994, sales of personal computers ($ 8 billion) exceeded sales of ordinary televisions (Associated Press, 1995). The computer has become a common consumer purchase. Software publishers have chosen to stay in this market, and many of them are faring quite well (Software Publishers Association, 1996).

EYES-WIDE-OPEN DECISIONS Against this background of uncertain returns on their investments, publishers make deliberate decisions to trade off costs against customer satisfaction, with their eyes wide open to the effects. Some product failings are due to blunders or to poorly organized software-development processes. But, in many cases, publishers consciously decide to save money on the product now and to deal with customer dissatisfaction later. The following sections offer some examples in a variety of categories.

During Product Planning and Design Why is the program missing obvious, essential features? Publishers know how to research the market. (Those who don't hire consultants who do.) It's not hard to survey the capabilities of competitive products, to read product reviews, and to talk to customers. So, the question is, when a publisher re-leases a product that is missing obvious, essential features, did it know those features were needed but chose not to spend the money developing them, or did it just skimp on the basic market research? Either way, the publisher saved money at your expense.

Why is the program hard to use? It costs money to design products that are easy to use. Publishers choose whether to hire usability specialists, to build and test prototypes of their products, or to test a product's usability during the design stages.

Why does the program crash? A publisher can use fault-tolerant design methods to create programs that cope gracefully with unexpected or invalid data, broken computer components, and even with serious logic errors. But, those methods take money, time, effort, and careful analysis.

Why do the same bugs infest version after version? Some publishers don't study their customer complaint records when they design a new version of a product. Result: Old problems don't get fixed. Other publishers know what needs fixing, but they introduce so many new bugs into new versions (and have to fix those in crisis, panic mode) that they run out of time to fix the old ones. Overly optimistic schedules destroy many fine products.

During Programming Why does the program have so many bugs? Because the programmers made a lot of mistakes. Why? Because they didn't have the time, resources, or leader-ship to do the job well. Here are some common examples:

Some publishers don't plan realistically. Many schedules are based on an executive order, not an analysis of the amount of time and staff it will take to do the job. The project becomes a rush job, and the customer is stuck with the result.

Some programmers are so overworked they don't get enough sleep. We're not kidding. This is a problem. Some publishers drive their (salaried, not eligible for overtime) staff for long, long hours. Tired programmers produce buggy programs.

Some publishers won't invest in good tools for their staff. Imagine trying to build a house without a level. That's what it's like to build a program without a great debugger, a source-control program, a top-notch debugging compiler, a run-time memory management checker, and so on.

Some publishers reward staff for speed instead of reliability. Example: Joe and Sandy started comparable tasks in July. Joe finished programming in August, but his code was so unreliable that the testing group kept finding bugs in it until December. Sandy took until September to code and check her work; she got it right, and her program cleared testing in October. Many companies would reward Joe instead of Sandy, because he ap-peared to be a faster programmer. Not surprisingly, those publishers' pro-grams have lots of bugs.

Why can't you understand the program's error messages? Why doesn't the program warn you before you do something that has serious repercussions (such as erasing all your work)? It's tedious and time-consuming (and therefore expensive) to predict the mistakes that people are likely to make, then to deliver an understandable warning or error message for each, and finally provide documentation or online help that further explains each message. The attitude of some publishers is that if it's your mistake, you can't blame the publisher for it. So why should the publisher help you deal with it?

Note Watts Humphrey was a senior manager of software development at IBM; then he founded the Software Engineering Institute. He is also a well-known author. He wrote us to object strongly to our use of the common buzzword "bug." He made the point so well that we are including most of that letter here:

[Bug] trivializes an important issue. When programs have "bugs," we tend to think of them as annoyances. While many may be annoyances, some will be much more serious. I contend that they are not bugs but defects. Any program with one or more defects is defective. While we cannot guarantee that programs are defect-free, we cannot guarantee that 747's are defect-free either. But that does not stop Boeing from striving for defect-free work. It should not stop the software community from striving for defect-free work either.

Unfortunately, with a trivializing term like bug, programmers tend to think of quality as unimportant. It is nothing of the kind! When developers say their program is fully tested and only has a few bugs, people think that is okay. If we called them "land mines" or "time bombs," the statement that the program was pretty well tested and only has a few time bombs would get a different reaction. We must face it, out of the millions of software defects, some really are time bombs.

While the Program Is Being Tested It's impossible to fully test a program (Kaner, 1997f); therefore, it is probably impossible to find all the bugs in the program; and it is certainly impossible for the publisher to know whether it has found all the bugs. But short of the in-finite amount of time required for complete testing, there are wide differences among publishers. One might budget four to six months to test a product; an-other might spend four weeks testing the same product, or a publisher might do virtually no in-house testing and rely on their customers to do their testing for them. They think, usually incorrectly, that this type of testing is nearly cost-free. But, even if the costs are low, the real problem is that customers are not systematic, trained testers, and they miss a lot of bugs. When a publisher says, "We've never heard of that bug," it might mean, "We didn't find that bug because we did almost no testing."

It is possible, however, to find almost all of the bugs in a program. Software test managers have told us of products in which all but five bugs reported by customers actually had been found first in the test lab. (We assume that they are not including reports of incompatibility between their software and various types of equipment.) One large software publisher tracked this type of performance over a two-year period. The head of its software testing organization said that customers reported only 10 new bugs (bugs that hadn't been found in the test lab before release of the product to customers) in one product. In all of the other products, customers reported even fewer new bugs. Software testing (or quality control) managers and consultants sometimes measure the effectiveness of their software testers in percentage terms. They add all the bugs that were either found presale (usually by in-house testers) to all new bugs re-ported post-sale by customers. What percentage of the total were found by the testers? In the mass-market software world, percentages like 95 percent seem to be common, and percentages like 99.5 percent might not be out of line. (These estimates are based on verbal reports from the following: testing/quality-control managers who take pride in their group's work; from a few sets of numbers sent to us; and from a reputable independent test lab that keeps such statistics as a matter of contractual responsibility. These numbers are not widely published nor easy to obtain, and we do not know how representative they are. Relatively few publishers track this number or any other measure of testing effectiveness. We suspect that not all mass-market soft-ware publishers obtain results like these. In these fast-to-market times, several companies have cut back on their quality-control budgets. They probably find and fix fewer problems. We caution readers that different numbers occur in different market segments. For some very expensive, large systems, it seems common and acceptable to put a product in service with a much lower percentage of bugs found. The vendors in these cases handle the problems on a customer-by-customer basis, with a much higher level of service. The net result seems acceptable to those customers. )

Even though well-run publishers do find most of their problems during their testing process, they don't fix them all. Early bug-fixing takes time away from coding new features. Late bug-fixes can delay the release of the product and cause even more bugs. Publishers consider some bugs minor and irrelevant. They decide that probably no one is going to complain about these bugs or that no one's work will be affected by them, so they don't bother to fix them.

(Bach, 1996; Yourdon, 1996). For example, it is widely reported that Windows 3.1 shipped with 5,000 known bugs. (This sounds like a big number, but don't infer a criticism of Microsoft that we don't intend. We believe that Microsoft's staff members are careful in their risk analyses and that they try hard to en-sure that the bugs they knowingly ship with a product will not impact consumers' use of their products. We aren't saying that we agree with all of their decisions. We are saying that we think that they're ethical.)

Similar to the Microsoft numbers, here is a report from Apple, "Apple shipped the first version of Hypercard with about 500 known bugs in it... I was working at Apple when Macintosh System 7.0 shipped, and it went out with thousands of bugs." (Bach, 1996)

Some companies exercise care and wisdom in their risk analyses, but others' practices are much sloppier. As a result, some publishers release products with inappropriate errors, which were known (if not necessarily fully appreciated) at the time of release. Customers' complaints are often about known bugs, even if an individual customer support technician has not heard of the bug or pre-tends to have never heard of it.

Note This does not mean that software publishers are aware of every bug when they ship a product. It is dismayingly common to be surprised by repeated customer complaints about one or two serious bugs that were never imagined in the lab. But, once publishers start getting reports of these bugs, they know about them. Certain publishers will continue to manufacture and sell products that contain serious errors for longer than others.

Finally, what if the program won't work on your computer, but it works on other computers? Don't let the publisher's technicians intimidate you by saying that your computer's configuration is weird or unusual. Never forget that the publisher chooses the amount and extent of configuration testing that it does. (Configuration testing includes testing the program with other programs, different types of computer equipment, different versions of the operating system, etc.) Configuration testing is expensive, and it can be an overwhelming job. To keep within their budget, publishers limit their testing to specific hard-ware and software; as a result, they ignore many products that they know customers will use in conjunction with their software. For example, even though a publisher can't afford to test the program with every video card, that doesn't excuse the program's incompatibility with your video card, and it doesn't necessarily mean that your card is weird or unusual. (On the other hand, if you do have unusual equipment, don't be surprised if programs have trouble with it.) Conscientious publishers will list the supported or tested configurations on the outside of the box or at their Web site. Others hope that their software will work on configurations that they never tested, and then they blame you when it doesn't.

One kind of configuration problem makes unwilling victims of both you and the publisher. If the device, such as a video card, was designed after the publisher started selling its product, you can't expect the publisher to have found incompatibility with this device before it released the software. The same type of problem arises when you try to run a new program with an old one. The old one might no longer work because of odd behavior by the new one. You can't (usually) blame that on the old one.

About the Documentation A favorite complaint of customer support technicians is that customers don't read the manual. So, they tell you to read it. (Under their breath, they say RTFM, Read the Fine Manual.) So you try. But, if you don't understand it, a manual isn't very useful. Is it you? Are you stupid? Is it because you aren't experienced enough with computers? Probably not.

Good writing costs money. A well-written, comprehensive software manual for a consumer audience costs about eight hours of work per page. (These estimates include planning, researching, writing, editing, layout, and indexing. Hackos (1994) gives slightly lower estimates, but we are allowing for the extra time it takes to include good troubleshooting info, which takes longer to research per page, and for a better-than-average index.)

Publishers often choose not to invest enough to write a manual that its customers can understand. Writers often are budgeted for as little as an hour per page. In many companies, such decisions are rationalized with statements that there's no point spending much money on the documentation because no one reads it anyway. (So, why do these companies whine "RTFM" when people don't learn anything from their lousy documentation?)

Some publishers believe the myth that no one reads their manuals because so many of the people who call for support seem not to have read (or not to have understood) the manual. What they don't realize is that most people solve their own problems without calling for support. Research by Dataquest (Johnson, 1995) illustrates the point. Most customers (more than 80 percent) solved their own problems by looking up information in the manual, through online help, or by using other electronic documentation. People were less successful at finding information in these documents than they wanted to be. With better documentation, more people would have solved more problems.

Kaner recently studied this issue for a client. When customers called for sup-port, we asked whether they had checked their manuals before calling. They usually said, "Yes," so we followed up by asking what they had found. Nearly 90 percent of the callers could specify why the manual or online help hadn't answered their question. The problems they cited were unsurprising. They couldn't find what they needed because of the following reasons:

  • The index was incomplete, or wrong, or pointed to irrelevant information.
  • The table of contents provided no hint as to where to find the information.
  • The information was wrong, incomplete, incomprehensible, or spread across too many places in the book to be useful.

Sound familiar? If the manual and help were correct, useful, and understandable, how many support calls would never be made, and how many others could be handled much more quickly?

Some publishers try to save money on documentation by putting the manual online. This saves them the cost of printing a manual. Unfortunately, material that is structured for the printed page doesn't work as well on screen. (Hackos, 1997, explains the differences well and concisely.) Good help systems take longer to create and test than excellent manuals. As a result, help systems that come with mass-market products are usually incomplete and hard to use.

Other problems with documentation include the following:

Errors. In a recent survey, 50 percent of the responding companies admitted that they don't put their documentation through quality control. (Customer Care, Inc., 1994, p. V-29; for additional references see Kaner and Pels, 1996). Thoroughly testing a manual costs about 15 minutes per page. But, some managers contend, if nobody's going to read it, why spend so much time checking whether it is accurate? In short, you get what they paid for.

Incorrectly described and missing features. One of the frustrations of being a technical writer is that the writing must be done while the program is still changing. It takes less time to duplicate disks than to print a manual. The result of this, on a time-constrained project (which includes most mass-market software projects) is that the manual goes to the printer while the software is still being tested, fixed, and revised.

Poor (or no) index. Readers rate a good index as a critically important feature of a manual (Grech, 1992). But, a good index should be created, reviewed, and edited as the book is written (Hackos, 1994; and see Mulvany, 1994, for an excellent discussion of techniques for developing high-quality indexes). A well-edited, thorough index costs as much as 30 to 45 minutes for each page of the manual. But, most indexes are compiled quickly at the very end of the project, when there's no time for a good job, and no time for a careful edit without slip-ping the book's schedule. (See Bonura, 1994, for an explanation of the quick indexing approach.)

Insufficient and/ or ineffective troubleshooting tips. Good troubleshooting is expensive. The writer must do research to determine which problems to write about and then has to master each problem's symptoms and solutions. The underlying issues are often much more technical than the rest of the book. It can take 20 (or more) hours per page to research, write, edit, lay out, and test troubleshooting material.

If the manual and online help are poorly written, disjointed, and error-ridden, and you can't find anything in them, or even if you do find something and if it doesn't try to help you get out of trouble, then the publisher has given you nowhere to go when you have problems. This doesn't mean that you're too dumb to understand the program and the manual. It means the publisher was too cheap.

About Technical Support The software industry is facing a crisis in support costs. As products reach a broader audience, the customer base expects products that are more reliable and more capable of living up to their advertised benefits. Early adopters of products are tolerant of many practices that infuriate the mass market (Moore, 1991). Computers and software have become mass-market items during this decade, and the result has been a shock to the industry. The numbers given here illustrate the size of the problem. These are industry data, from reputable sources. We provide additional references in Kaner and Pels (1997).

  • In 1996, 200 million calls were made for technical support (Johnson and Gately, 1996; Bultema and Oxton, 1997; Schreiber 1997).
  • Complaints to consumer protection agencies about home computers and software have gone through the roof. According to the Better Business Bureau, in 1995, computers and software were the eighth most complained about industry. This jumped to seventh place in 1996.
  • At an average of about $23 per call, the industry spent about $4.6 billion on these calls. (Tarter, 1993, $23.33; Murtagh, 1994, $20.22; Help Desk Institute 1997, $25; Customer Care Institute, 1993, $25, but the 1994 estimate was $18. The Software Support Professionals Association, 1997, document RTR0011 estimates $25 per call for PC/ shrink-wrap products and much more for Unix and mainframe products.)
  • According to a report by Dataquest, over a seven-year period, the ratio of support to total employees in hardware and software companies grew from 1 in 12 to 1 in 6 (Johnson and Gately, 1996). The Association of Support Professionals (1997) confirmed this, reporting that on average, customer support staff make up 15 percent of software publishers' total employees.
  • Customer satisfaction with software publishers' technical support dropped steadily for 10 years. (Bill Rose, president of the Software Support Professionals Association, 1996; Ron Schreiber, chairman of Softbank Services, 1997.) J. B. Wood, executive vice-president of Prognostics, a leading market research firm, reported in 1996 that customer dissatisfaction with support had finally bottomed out in the eleventh year.

  • Publishers differ widely in the percentage of revenue that they're willing to invest in customer support (Tarter, 1993). Some publishers see the quality of their support relationship with customers as a strategic advantage and as a source of invaluable marketing and product-improvement information. (Barlow and Moller, 1996, and Van Bennekom, 1994, explain this well.)
Others don't. For example, Jeffrey Tarter, editor of Soft* Letter, a very influential newsletter in the industry, in 1996, wrote a widely read commentary on Microsoft's investment in better technical support. Starting in 1993, Microsoft spent about $500,000,000 to improve its technical support for products such as Office. The organization improved greatly (to world-class levels, according to other data that we've seen). However, according to customer surveys, customer perceptions of Microsoft's service quality improved, but only to not much better than average. Tarter concluded that this investment would, therefore, not affect customers' buying behavior, "Despite lots of wishful thinking to the contrary, spending money to upgrade a company's service reputation remains a lousy investment."

We are horrified by thinking like this. It doesn't serve customers. And, we doubt that it serves the industry. We suspect that the main effect of bad sup-port is not on new sales but on the probability that existing customers will buy the next version of a product or other products from the same company. The cost of losing existing customers is very high (Wood, 1996; Goodman, 1997). Good service is an important factor in helping companies build long-term relationships with customers (Anton, 1996). Sterne (1996) cites data showing that customers who complain are among the business' most loyal customers. Unfortunately, some publishers analyze the world differently. They invest less in support because they think that it won't significantly improve sales or profitability.

Why Don't They Answer the Phone? Publishers can predict the number of customers who will call and when they will call for support. Publishers decide how long they want to leave the average caller on hold and how many of these callers they want to eventually talk to and help. (See, for example, Murtagh, 1993; Brown, 1996; and Khandpur and Laub, 1997). For many publishers, this number is not 100 percent. Most publishers want to talk to most callers, but some plan their staffing level to handle as few as 10 percent of the incoming calls. They correctly expect the other callers to hang up without service after being left on hold for an hour or two.

Tip You might be on hold a long time even with a very customer-focused publisher, due to unexpected flurries of calls. But, companies that decide to leave their typical caller on hold for outrageously long periods of time do so because they don't want to talk to them. With such companies, you must show that you are serious about getting help.

About half of the calls into software publishers are left on hold for two minutes or less. (Software Publishers Association, 1995, p. 18, estimated 2 minutes; Customer Care, Inc., 1994, estimated 4 minutes.) Others get to very few of their calls this quickly. If you look at the average amount of time people are left on hold (total number of minutes on hold, divided by the number of calls), it's about 15 minutes. Average hold times have been reported as follows: 12.2 minutes (Software Publishers Association, 1995, p. 17), 15 minutes for PC/ shrink-wrap products but less for Unix and mainframe software (Software Support Professionals Association, 1997, document RTR0018); 19.8 minutes (Schreiber, 1997). Many people spend more than an hour on hold. At 15 minutes hold time per call, for more than 200 million people, the industry left people on hold for about 3 billion minutes last year. 4

Note Service Management International (Brown, 1996) did a small study of hold times across industries and found that software companies leave callers on hold longer than any other industry studied. They were worse than government agencies, computer hardware companies, airlines, banks, utility companies, and others.

Leaving callers on hold can be expensive. For example, in 1996, software publishers who provide toll-free support paid $500 million for toll charges while customers sat on hold (Schreiber, 1997). Rather than wasting this money, many publishers now give you a busy signal when they're too busy to take your call. According to Schreiber (1997), at peak times, 85 percent of calls into technical support groups now get busy signals.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews