Can Technical Writing and Technical Support Work Together? Achieving a High Client-Satisfaction Rate News & Views Feature Article

by Will Schirmer SofterWare, Inc. Originally published in News & Views November, 1997 issue. Copyright 1997 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.

When you hear the term "Technical Support," you often think of the department down the hall. The phones are ringing, people are moving quickly to talk with one another, and there’s usually a certain degree of noise. The average Technical Writer would head in the opposite direction—where the phones aren’t ringing, fingers are moving quickly across the keyboard, and for the most part, it’s quiet. Now picture yourself in this situation--you are being interviewed for a job as a technical writer. You look at the manuals that need updating, and you hear the plans for future projects, and the more you hear, the more interested you become. Then you hear something you don’t expect: part of your time will be spent on telephone support. That’s exactly what happened to me last year. My first thoughts were: How do you combine these two areas? I had been in both roles at another company, and I saw them as different as night and day. It didn’t seem to be a likely combination at first. However, the more I looked into it, and the more I learned about the company, the more I saw how the pieces would fit together, and thus accepted the position. Background To begin with, let me give a little background about the company I work for, SofterWare, Incorporated. Founded in 1982, they have provided software for the day care and camping industries. Seven years later, they expanded their services to meet the needs of the non-profit spectrum with the sales and support of fund raising software. Today, the company employs over 40 people, sells and supports four major product lines, has a client base of thousands of clients, and is in the process of developing a new product. If you ask SofterWare’s clientele and management what the company is known best for, the answer will be one word: support. Good client support is the foundation around which everything else is built around at SofterWare. A lot of time and resources are dedicated to support, starting with the full time support staffs for the two main divisions. Every employee is involved in client support in some capacity--all the way up to the president, Dr. Nathan Relles, who spends some of his time on the phone with clients. All this has resulted in a consistently high satisfaction rate with the clients, so says our latest survey. Our median rating was a nine on a scale of one to ten. Job description My job includes assignments you might expect in any documentation department: updating manuals, writing new manuals, desktop publishing of newsletters and marketing material, and recently, developing an online help system. It also includes a specified time of support-related duties: answering calls from clients, dispatching calls (distributing call overload among the support staff), working the evening support shift, and various client related projects. This mix has enabled me to develop and use my skills across several areas. Focus on clients—writing as a support rep It’s a principle that is believed by many in our occupation: If you write a good manual, the clients won’t call support as much. Using this as a guiding principle, my goal is to write manuals that are appealing, as clear as possible, and easy to use. The same goes for updating existing manuals. These goals, however noble, are basic to every writer and every documentation group. What do we do as the next step? In SofterWare’s case, the manuals are written primarily for reference. They cover the basic installation of our systems, but the majority of the manual is accessed by a client who needs help with a particular situation. So, to enhance the manuals, Installation Guides were created. These guides give details for installing additional software modules, setting up databases, and general preparation for use of a particular module. The full manual takes over after the module is operational. These Installation Guides are designed as a result of listening to clients during support calls. "How do I run this?" "How do I answer this prompt?" "What does this prompt mean?" "What fields do I need to set up in my database?" "How do I know my installation finished properly?" These are all questions I can answer in the Installation Guide, and in the manual (when applicable), so the next client can have the answers--eliminating the need to call with questions. There is a second principle that has plagued every writer: No matter how well you write the documentation, some users will never read it anyway. However discouraging this sounds, it gets more discouraging when it is misinterpreted as: No one ever reads the documentation, anyway. The former description of the principle is true, and has to be accepted as fact. The latter is a mentality that those of us in this profession will never accept, yet always battle. I’ve received many calls from people who have not read the documentation. When you ask them why not, there are dozens of excuses. So in that case, when I have a client on the phone, I do what a former manager used to call "paper training a client." It goes like this. "While I explain this module to you, I’d like you to turn to page AR-24 in the manual and follow along. As you’ll see, the prompts and responses are explained in that section. As we answer each prompt, note the options written in the book. When we’re done with this procedure, you’ll know exactly where to find it in the manual. In fact, put a yellow sticky paper on the top of the page and write the section name on the part that sticks out. After you use the manual and do this a few times, you’ll be so good at it you’ll do this on your own in a snap!" What have I done here? Several things: I’ve satisfied the client’s need to have their questions answered immediately. I’ve taught them how to use the appropriate section in the documentation. I’ve encouraged them and strengthened their confidence in themselves—they have the ability to read the manual and do this task on their own. I’ve saved the support department at least two future calls, since the client will likely not call us again for the exact same situation. Granted, there are still people who will call support because they perceive it as being easier than reading documentation. I found another way to encourage reading a manual over calling support--leave the support number off the documentation (especially for smaller material). Don’t give the clients an easy out from reading--if the phone number is there, they won’t read any further. Focus on support staff--support colleagues as a writer As part of the support team, I benefit from the same meetings, training and resources the other support reps have available to them. Being a writer, however, I can contribute to the resource pool that benefits the entire staff. One way is the creation of Internal Memos. Someone in the group has discovered a way to create reports that skip lines when the year changes. Another person has gathered information on printer drivers that clients need in order to run our system. A new procedure needs to be explained to the department. This information can start out as a pile of words and phrases, which I can turn into a format that is easy to read, or easy for a rep to access when we have a client on the phone. Another tool SofterWare has established for the Support Department is the Fast FAX. Using FAX Server software, we can create documents that provide detailed answers for clients. By using this material, a support rep can send the answers to the client via computer, while moving on to help the next client. Although some faxes are created from scratch, a lot of them are reproductions of memos, portions of newsletters, pages from manuals, and pieces of updates that haven’t yet been released. And they can be reproduced from our available word processing and desktop publishing software. A third way to provide support for the Support Department is Email Documentation. Presently, we are using email attachments to send database files back and forth to clients that use email. Why not use email attachments for documentation? This is an area I am just getting into and plan to implement in the next few months. Here’s an example of how it works: I am currently putting the finishing touches on a manual that is quite large compared to our other manuals. There are several "options" to this product that only a portion of our clients use. Instead of including these options as chapters or appendices in the manual, they can be obtained by interested clients who use email. (They can also be mailed or faxed to clients that don’t use e-mail.) By leaving those pages out of the manual, and multiplying the cost of printing multiple copies of those pages, the low cost of email saves money in the long run, and gives our clients more confidence in our "cutting edge abilities." The email documents will be available in two popular word processing formats and can be read into the current version of almost any word processor on the market. Learning the software quicker--from the client and support points of view When writing a manual, it’s one thing to run a copy of it with dummy data to see how it works. It’s another thing to be stuck knee deep in error messages, blank reports, and missing fields with a client on the phone, using real data to see how it doesn’t work. To fully learn our product, I’ve learned from the client’s mistakes--literally. I’ve also learned from my support experiences, as well as the experiences of the entire Support Department. Sometimes you need to go beyond the capabilities of your own computer. You know how the module should work. But what don’t you know? What didn’t you set up? Or, how can you prevent a client from having a disaster if he uses the software the wrong way? From this experience, I’ve added two new elements to the manuals. The first is a series of warning messages, each having a different level of intensity. Note: This indicates vital information that you need to know about the function described. Important: This warns you that you have to take action or be aware of certain facts to produce the desired results. Caution: Indicates the potential for disastrous results if choices are not made carefully Advanced Users: Recommended action only for users who are experienced with our software and computer operating systems in general. New users or non-technical users are encouraged to contact the Support Department for assistance. Reference: The function described may require additional explanation from another chapter in the manual, or another manual. The user is informed where to obtain that information. Each of these warnings is indicated by a graphic in the left margin of the text. In addition, I have been creating a Troubleshooting/Solutions section in the back of each new manual. This is a compilation of information from various members of the Support Department who have expertise in a particular model or application. Just the word Troubleshooting suggests known problems, so I added the word Solutions to bring a more positive, reassuring tone to the section. Bringing the technical writer and the client together One of the biggest advantages I have in my situation is the fact that I can speak with the clients. Not many technical writers have this opportunity. Not only can I help the clients and support staff with their work, but they can help in the process of producing documentation. The manual I’m ready to release has several re-written sections and some new material. At one point, when I felt the Setup section was near completion, I received a call from a client installing the software. "Good," I thought, "I can help them. After all, I wrote (part of) the book on it." Then the client asked: "How do you set up the initial database on the remote computer?" My mouth opened and stayed open. I never thought of that. Neither did the previous writer of this documentation. But the client did. In fact, it was a basic procedure for a client to do when installing this software. But nobody on this end of the phone ever considered that part of the process. You can learn a lot from clients using your software. You can also be encouraged or discouraged by them. One night on the evening support shift, I spoke with a client who read a certain section of the manual. "I can’t make heads or tails of this--it’s confusing, and it doesn’t help me one bit." One hour later, another client had a similar problem and referred to the same section of the manual: "The manual is great. It’s been a tremendous help. It got me this far and saved me lots of time." Go figure. I will say that I did not write the documentation mentioned by these clients--but I took their comments as personally as if I did write it. Conclusion I enjoy my role at SofterWare. I should point out that in addition to the Support Department, my writing, editing, and desktop publishing skills are put to use on projects for the Sales Department, as well as another product division. I consider myself fortunate, in many ways, to be here doing what I’m doing, and enjoying it. It’s given me a new perspective on technical writing, it’s broadened my abilities, and it’s put me in touch with the people who read and use what I write. Someone recently said "Before you judge someone, walk a mile in their shoes, because that way you’ll have their shoes and a mile head start." There’s a parallel in technical writing for a software company: stay close to your users, stay close to support, and keep a large recycle bin for rough drafts.

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Posted November 23, 1997 (rst)