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
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
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
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.
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 email@example.com
or at 888-378-2333. and on the Web at
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:
For more information about these books and other reading
recommendations, see the Resources page of the ProSpring website
The Practical Guide to People-Friendly Documentation by
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
A Practical Guide to Usability Testing by Joseph Dumas and
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: firstname.lastname@example.org.