Unhappy Customers Are Just the Beginning: Potential Costs of Poor or Missing Technical Documentation

By Joseph Devney | Associate Fellow

Technical communicators sometimes talk about the value of good technical documentation. What about the converse—the business costs of bad documentation? Or of documentation that simply isn't provided? Sometimes such costs can be very high.

Missing documentation is self-explanatory: a manual or online help for some audience doesn't exist. What makes for "poor" documentation is more complicated. The document or document set can be incomplete. That is, the documentation itself exists, but it is missing some important information.

Or the documentation can be poorly organized, difficult to navigate. For example, an index would be helpful, but there is none. Or the hierarchical nature of the information isn't obvious. Material that should be relegated to an appendix might instead dominate the middle of the book. The index or search feature in an online help system gives unhelpful results.

Some documentation seems to be aimed at the wrong audience. Usually this means that the material is more technical than it should be. Just because a software engineer or other subject matter expert can understand it doesn't mean a customer or other reader can.

Sometimes the tone of the documentation is persuasive rather than instructive. I have seen user manuals that tell me how easy a software application will make my life, without actually telling me how to do the things promised.

Where Does Poor Documentation Come From?

Many operational issues can contribute to inadequate documentation. Among them are:

Limited time to produce documents
Non-writers writing technical documentation
Too much influence from marketing
Unqualified technical writers
Poorly designed templates; too strict attention to templates

One thread runs through these causes: they can be the product of management decisions. Managers decide on schedules and budgets and hire the writers. Managers can decide to allow time and budget for user testing or not.

As we will see, skimping on documentation can be a costly decision.

How Common Are These Problems?

In 2012, STC Associate Fellow Sharon Burton conducted a survey of consumers about product documentation. More than half of her respondents said that they look at the documentation before buying a product. What if they find the instructions for a product they have bought to be confusing or incomplete? A small number—7 percent—said they would never buy from that company again. But a 7 percent drop in sales could be significant. And another 37 percent would "possibly" not buy from the company again.

Taking a somewhat different tack, market research company IDC surveyed companies regarding "document-driven processes." More than three-fourths of their respondents had suffered "serious business risk and/or compliance issues as a direct result of ineffective document processes." The consequences included compliance problems and lawsuits, two subjects addressed later in this article.

Potential Consequences

Inadequate documentation can harm a business's bottom line in many ways. Here are some of them.

Unhappy customers. People may complain to their friends (or on the Web!) about the company or the product. They may not buy your products again, and they may discourage others from buying them.

Lost sales. Either from unhappy customers not repeating, or potential customers choosing a competitor with better user documentation.

Wasted employee time. Time spent by employees looking for information is time they are not spending on more profitable tasks. Badly written or poorly organized documentation makes the search longer.

Higher customer service expenses. Providing a manual or good online help can be cheaper than paying help desk personnel to solve customer problems or sending engineers to customer sites.

Fines or other penalties. These can be imposed by regulatory bodies, either from government or industry. Government agencies can also restrict how your company conducts its business.

Product liability lawsuits. The documentation is part of the product and may be the ultimate source of the injury to the plaintiff.

Let's look at some of these consequences in more detail.

Lost Revenue

Poor documentation can lead to lost revenue, as is implied by the results of Burton's survey. Unhappy customers hurt your reputation and can lower your sales directly or indirectly.

Case Study: Lost Revenue

This story is from outside the realm of strictly technical documentation, but is instructive nonetheless. The United Kingdom had a revenue problem. Many small businesses were not paying their taxes or not paying them promptly. The government sent out dunning letters, with limited success. The letters were ineffective communication.

The government's Behavioural Insights Team, established in 2010, addressed the problem the same way a well-managed technical documentation group might: they did user testing. In this case, they drafted several different tax letters for a pilot project. Each one went to thousands of taxpayers and the team tracked the results. They then used the most effective message for the rest of the letters.

In this case, cutting costs by not doing the user testing turned out to be an expensive approach. The government projected that applying the lessons learned from the pilot test nationwide would bring in approximately £30 million per year—far more than the one-time expense of less than £1 million for the test.

The lesson: Real-world testing of the effectiveness of documentation is worth paying for.

Internal Efficiency

Maybe you don't write for customers. Even if you write for internal audiences, poor documentation can bring costs. Is it too hard to find existing information? Once found, does it turn out to be outdated or poorly designed? Do employees ever have to recreate information? All of these activities waste employee time.

A recurring problem I've run into is having to reuse a graphic without being able to locate the original. There are workarounds, but not good solutions. The missing graphic can be recreated from scratch; that takes time. Or an electronic version can be created from a screen shot or a scan of the existing version; that usually produces a lower-quality image. In some cases, an embedded graphic in Word can be saved in Visio.

The International Data Corporation has estimated that poorly organized documentation can cost a company with 1,000 knowledge workers approximately $3 million per year in lost time. Add an additional $15 million in opportunity cost—that is, lost revenue because the employees were not working on more useful tasks while they were searching for information internally.

Case Study: Recreating Information

I once helped a microchip company convert production of documentation from Microsoft Word to Adobe FrameMaker. It was impossible to locate originals of some of the graphics. A few images were created with PowerPoint (not really a graphics application), or with a specialized application owned by only one person in the company (not in my department). The problematic graphics were either recreated from scratch or replaced by screen captures from existing PDFs.

The lesson: Organizing and indexing all component files saves time and effort in document production.

Regulatory Compliance

Many companies must comply with regulations. These can be mandated by governments or by industry groups. For instance, in the United States, airlines are regulated by the Federal Aviation Administration and pharmaceutical companies by the Food and Drug Administration. These are government agencies. The American National Standards Institute is not a government entity, but a standards-setting body. Some of their standards address documentation.

Running afoul of the strictures imposed by either government or industry groups can have serious consequences. An electric utility that has agreed to follow industry guidelines for system security—including for documentation—can be fined up to a million dollars a day if they don't pass an audit.

Sometimes the stakes are even higher.

Case Study: Noncompliance

In January 2005, a jet veered of an airport runway in Canada. This caused Transport Canada, the Canadian equivalent of the FAA, to start an investigation of JetsGo, the airline that owned the jet. The investigation found, among other things, that some required documentation was missing. The airline was not fined, but the penalty was at least as bad. They were ordered to fly their planes at lower altitudes, which greatly increased their fuel costs. The company couldn't keep this up for long: in March, 50 days after the initial incident, JetsGo stopped flying planes. They declared bankruptcy not long after that, and were eventually bought by another airline.

The lesson: If your company's documentation falls under regulations from an outside entity, make sure you follow the rules regarding documentation to the letter. Failing to do so can be very expensive. In extreme cases, it can mean the end of the company.

Lawsuits

One issue that could bring your documentation to a court of law is copyright violations. This should not be an issue if qualified writers produce the documentation—or at least police material from managers or SMEs. On one project I worked on, a manager brought back a three-ring binder of material from an outside class. He asked me to retype the material in his company's template, making it "theirs." I refused; that is exactly the kind of thing copyright laws were implemented to prevent. At another company, I was asked to edit material written by an engineer. The writing style at the beginning sounded like "marketingese." I did a Web search for a distinctive phrase in the text, and found that he had simply copied a few paragraphs from the website of an industry group. Again, a clear copyright violation.

And perhaps you remember Google's project to scan and post on the Internet millions of books from libraries. From a technology point of view, it's an ambitious challenge. From a writer's point of view, it is theft. A lawsuit filed by publishers was recently settled after seven years; the lawsuit by authors is still ongoing as of the end of 2012.

If actual harm comes to a customer, though, that can be much worse than something like a copyright issue. Product liability lawsuits are not common, but can be very expensive. And since the documentation is part of the product, the documentation can be the focus of the suit.

How much can a lawsuit cost? In an informal survey, I got ballpark figures from two lawyers. A Nevada attorney estimated that the cost of investigating and litigating this type of case easily exceeds $100,000. He pointed out that a product liability lawsuit usually requires expert witnesses and the evaluation of thousands of documents, maybe more.

An attorney in New York suggested the following breakdown:

Attorney's fees: $300 to $600/hour times 100 to 300 hours
Depositions: $750 to $1,500 each
Experts: $10,000 to $20,000 each
Travel costs
Loss of productivity due to litigation-related time loss.

In sum: "An easy $500,000, win, lose, or draw."

Obviously, there is no single firm number for "what a lawsuit costs." But these estimates tell us that whatever the cost of a lawsuit to your company, it will likely be a large number.

Not only do the stakes go up if your documents end up in court, but the rules can change. Here is a useful anecdote. Consider the following sentence from an insurance contract. But don't spend much time trying to decode it.

"For all reasonable expense incurred in connection with the investigation, settlement, or defense of such claims or suits and the Company's reimbursement obligation for the settlement of all damages imposed on and expenses incurred by the insured shall be limited to the amount stated in the policy as the applicable limit of the Company's Liability for damages that the Company may, at its discretion, participate, in, in the defense or settlement of such claims or suit."

You may have had to untangle convoluted writing such as this in your own job. In this case, the contract ended up in court. A hospital and its insurance company were disputing how to split the costs of a multi-million-dollar lawsuit. The judge in the case did not make the effort to parse this text. He declared it "gibberish" and removed it from the discussion. He threw it out.

This power the judge has in a court case may affect your technical documentation as well. Perhaps your company is one of those that uses a disclaimer such as this.

"Although every effort has been made to ensure the accuracy of the information contained herein, [company] gives no warranty that the information is accurate and shall in no circumstances be liable to any person if it is not."

Knowing that the judge has the power to throw out unreasonable legal language, and that JetsGo went out of business at least partly because of inadequate documentation, a smart manager would not want to bet the company on such a disclaimer holding up in court. Better to make sure the documentation itself is "bulletproof."

Why "bulletproof"? In the worst case scenario, your documents might be gone over with a fine-tooth comb by a linguist, someone who knows in great detail how language works. Roger Shuy, in his book Fighting over Words, writes about several cases he has worked on. Here is a recap of one.

Case Study: Product Liability Lawsuit

A couple with a young son worked for a traveling carnival and lived in an RV (recreational vehicle). One morning the husband woke up with headache and nausea and had a hard time waking his wife. They couldn't wake the son at all and took him to the hospital. All three were diagnosed with carbon monoxide poisoning. The son's was the worst: he was at risk for permanent brain damage. The source of the CO? The RV's gasoline-powered electrical generator, made by a company called Generac. The parents sought out a lawyer. The lawyer called in two experts, an engineer to evaluate the generator and its installation, and a linguist to analyze the owner's manual.

The linguist, Roger Shuy, analyzed the manual on its own and also compared it to two similar manuals—one from Fleetwood, the manufacturer of the RV, and one from Onan, the company whose generators can be factory-installed by Fleetwood. He found many weaknesses in both the Generac and Fleetwood manuals that experienced technical writers would have identified. The warnings about carbon monoxide poisoning were not clear or prominent; there were no warnings at all about sleeping in the RV or using an exhaust fan with the generator running; the captions about hazards were not used consistently.

Some of the differences between the manuals were striking. In warning about obstructions, the Generac manual said that the generator may overheat and stop working if the air vents are blocked—and even that information was at the end of a paragraph. On the same topic, the Onan manual drew the reader's attention with the first words of the equivalent paragraph: "WARNING: Exhaust gases can cause severe personal injury or death." This puts the most important information right at the front.

Shuy's report said explicitly that two of the manuals failed to "follow effective communication principles about how to avoid multiple lines of all capitalized text." I'm sure everyone reading this magazine understands what that means. More broadly, he said that they also failed to "follow acceptable principles of effective document design."

The family filed suit against the manufacturer, but the case never went to trial. The linguist's report was enough to make the manufacturer settle a week before the trial started.

The Generac and Fleetwood manuals suffered in the evaluation by being compared to the one from Onan, which was both more thorough and more carefully designed—they obviously used the services of a knowledgeable technical communicator.

The lesson: If you want to increase your chances of avoiding or winning a lawsuit like this, make sure your technical documentation is at least as good as your competitors'. The plaintiff may compare them in building the case against you. Or you may use the weaker competitor's documents to defend yourself.

Addressing the Problems

Warning management about potential costs of skimping on documentation can have good effects—not least of which is better documentation. You really can lower the company's risk of loss from the consequences discussed. You can also raise the profile of the technical documentation department, possibly gaining additional resources. (Or lowering your own chances of being laid off when budgets are cut.) But how do you get the message to the right people? That depends on your own situation.

I once began a campaign for a major change to document production with an email to my manager, explaining the time savings possible. In a different company, I took a more direct and confrontational approach, setting up a meeting with the manager in charge of documentation (who had no background in technical writing), where I brought in a stack of books about technical communication and talked about the research and professional knowledge that goes into document design. You are in the best position to determine what approach will work best in your organization.

The important thing is to have some data to back yourself up. Speak in terms of money or time lost. The resources listed at the end of this article are a good starting point. If you can gather data from your own company, that would be even more effective. Talk to the help desk, talk to the corporate legal department (they know more about copyright issues than engineers), talk to people who have to find things on the company intranet.

Use whatever you think will work for you. This is just another communication challenge.

Joe Devney (joe@devney.com) is both a writer and a linguist. He has worked in the field of technical communication since 1995, primarily documenting software and data centers. He has been active in STC nearly as long, serving as chapter president and as a competition judge, among other things. More recently, he earned his master's degree in linguistics and is especially interested in the intersection of language and law. One particular area of linguistic research has been the comprehensibility of jury instructions, which he sees as a technical communication issue.