Why Customers Call Tech Support and What Tech Writers Can do About It

The high-tech industry in the United States spends billions of dollars a year staffing tech support departments, and technical writers can help reduce those costs.

Although the reasons why customers call tech support vary widely based on product type, for simplicity we can say that customers call tech support either because there is a problem with the product, or because they just want to know how to do something with the product.

Customers calling tech support just because they want to know how to do something is an indication of one or more of the following:

1. There is no user documentation for the product.
2. There is documentation but the procedure the customer wants is not in it.
3. The procedure is in the documentation but the customer never bothered to look it up.
4. The procedure is in the documentation and the customer actually looked in the manual, but couldn't find the needed information.
5. The procedure is in the documentation but the procedure is wrong (missing steps, screens have changed, etc).
6. The procedure is in the documentation but the procedure is so badly written that it couldn’t be understood (different from #5).
7. There is no applicable procedure because the product can't do what the customer wants it to.

Technical writers can do something about reasons 1 to 6, and what’s great is that many of the above situations can be fixed for very little time and money.

Here is the list of problems again, and some sample solutions. I have also included a list of books at the end of this article that give detailed advice on how to handle the problems covered in this article. (Note: I wrote this article for the person who will be doing the writing. If you don’t have a good tech writer and need one, I can help--my contact info is at the end of the article.)

1.There is no documentation: Well that’s easy--write some! Granted, you may need to "sell" your company or client on why they need user documentation, but showing your boss this article would be a good start. Then show your boss how much the company spends on tech support. Good technical communicators save companies money. We just need to convince them!

2. The information is missing: That’s easy too--just add the missing procedures.

3. RTFM*: OK, now we are getting into an area that may be a little more difficult (but hardly impossible) to fix. Suppose you have worn your fingers to the bone making sure that every conceivable procedure is addressed in the user documentation, and customers are still not looking for the wanted information. Before I give you a glib solution, let me just say, Find out why. Do a small usability test, talk with some of your customers. It could be the RTFM customer tends to throw the doc away with the packaging. In such cases, ship the documentation chained to the product (just kidding!).

But seriously, it could be that RTFM customers are simply intimidated by the big words and complex diagrams on the manual cover so they think they won’t understand it so never bother to look. In that case, get a graphic designer to create more "user friendly" cover art. Perhaps you have crammed so much information on every page (shame on you!) that the customer can’t confront reading the text. Perhaps the "typical" RTFM customer for your company has English as a second language or has a low literacy level. In this case, consider using less text and more "visual language" in the manual.

Did your company try to save money by totally replacing the printed documentation with online documentation? Well, perhaps shipping a quick reference guide that covers common procedures and includes references to the online documentation will help the online-shy reader.

In other words, don’t assume that customers will read your words just because you wrote them. Investigate what users are doing with the "Fine Manual" and handle accordingly.

4. The reader can’t find the information: You can solve this problem by making the information more accessible--include a table of contents, a detailed index that includes gerunds and synonyms (not just features), etc. Also, apply good structured documentation and manual design theory so users can easily navigate through the text to find the information needed.

5. The documentation is wrong: In a perfect world engineers would tell us every time they make changes before the product ships. Unfortunately, this is rarely the case so unfortunately what used to be a correct procedure doesn’t work now. If the engineers are making changes and not telling you, it’s your responsibility to acquire the information you need by getting on the distribution of applicable emails, meeting notifications, etc. Keep screaming "look how much we are spending on tech support!" to your boss until he/she gives you the backup you need. Then make sure you document the changes when you do get them!

And what can you do if changes are constantly made to the product after the documentation goes to the printer? Well, consider using a form of online documentation that automatically checks your website and displays the correct, current procedure. This can be a complex and costly solution, but considering how much it could save in tech support costs, it might be a viable solution.

6. The documentation is badly written. It is not uncommon for a technical writer to inherit documentation that was written by the engineers themselves (shudder!). Well, you should know what to do with that: rewrite the existing procedures using numbered lists, screen shots, active voice, decision tables, etc.

Finally, once you have fixed the problems we just covered, be sure to check with tech support for before-and-after metrics. One reason is that once you fixed one problem (say, there was no documentation), other problems can come to light (such as there are now missing procedures in the doc you just wrote). Another reason is that you need to show your boss and senior management how effective your changes were at reducing tech support costs. Not only is this important for "selling" the next phase of changes you want to do, you also want these numbers to hand when it’s time for your annual salary review!

Again, let me emphasize how important it is to gather before-and-after metrics. One project we did for a client reduced their support calls by a whopping 95% for one complex product they sell. That project alone not only ensured we’d get more work from that client, but it helps us close new clients.

Epilogue
I'm always happy to hear from my readers, so if you have any questions or need help improving your company’s documentation, please contact me at jackm@prospring.net or at 888-378-2333. and on the Web at www.prospring.net.

About the Writer
Jack Molisani has been a project officer in the Space Division of the USAF, the manager of training and documentation of a multi-million dollar software firm, and currently is the founder and president of ProSpring Inc., a technical communication and placement firm.

Jack teaches courses on how to reduce support costs through better documentation and training materials for Cal State University, is a regular speaker at the Society for Technical Communication (STC) and WinWriters international conferences, and is the chairman of LavaCon: The International Conference on Technical Communication Management to be held in Maui, HI in October 2003: www.lavacon.org.

Recommended Reading
For more information about these books and other reading recommendations, see the Resources page of the ProSpring website www.ProSpring.net.

The Practical Guide to People-Friendly Documentation by Adrienne Escoe

The Non-Designer's Type Book Insights and Techniques for Creating Professional-Level Type by Robin Williams

Human Factors for Technical Communicators by Marlana Coe

Strunk & White's Elements of Style

The Art of Indexing by Larry Bonura

Standards for Online Communication by Joann Hackos and Dawn Stevens

A Practical Guide to Usability Testing by Joseph Dumas and Janice Redish

Visual Language: Global Communication for the 21st Century by Robert E. Horn

* Read The "Fine" Manual--a common response from support personnel when someone asks a question that is clearly covered in the manual.

Copyright 2002 by Jack Molisani. All rights reserved.

Jack Molisani, president, ProSpring, 2500 Via Cabrilla Marina, #200-D, San Pedro, Calif., 90731; 888/378-2333. E-mail: jackm@prospring.net.