Some support techs just don’t seem to get documentation. Whether it’s because they’re too busy or just don’t think about it, they often make changes to a system and then never bother to create a record for what they do.

As Jeff Davis pointed out in a recent article, there are at least four good reasons why support techs should document what they do:

  • Customers deserve the information.
  • You deserve recognition.
  • You might forget something.
  • You’ll spot trends.

Additionally, he pointed out that documentation leaves evidence for future tech support personnel who may have to go behind them to fix problems.

In the article’s discussion, TechRepublic members chimed in with more reasons and some additional documentation tips. We’ve gathered some of their responses here.

Double-edged sword: Information is power
DonaldA-M keyed in on a reason why some tech supports don’t document: “Some…like being indispensable.” Knowing that knowledge is power, many support techs don’t document in hopes that it will keep their position from being “downsized.”

That reasoning can be a double-edged sword, however. When you’re the only one who knows what’s going on, it makes folks more likely to come to you for everything. It creates the “Ask John—he knows about that” mentality, which can cause your phone to ring endlessly. Further, DonaldA-M said that if you don’t document, you cause future tech support people to have to “reinvent the wheel,” wasting valuable time figuring out what you did in the first place.

Malosa echoed DonaldA-M’s last point, saying that documenting support calls, especially in larger environments, creates a group memory that’s helpful for addressing future calls. Although he’s gone on to a new job, Malosa said, “My team mates still use my well documented work tickets for insight and reference.” By working together to build support documentation, every support tech in your organization benefits in the shared knowledge.

If you’re in the consulting business, jlmiller came up with a great reason to document tech support calls and to have clients sign off on them.

“When it’s time to bill we send the client a copy of both the problem and resolution. In many cases it has solved [issues] regarding what I did vs. what they did,” she said.

This can solve many problems when billing time comes around. The client clearly knows what you did and why you’re charging them.

Additional how-to documentation tips
Members also shared some documentation strategies beyond Davis’s suggestions, including additional ways to document what tech support people do and what should be documented. For example, mroder creates a file in a shared folder on the network that’s accessible everywhere that he uses to keep track of such things as hardware information, who serviced the computer, when, and what was done.

This ensures that should the supported system crash, he still has access to the history file. Another key tip he provides in the form of a question: “Ever try to re-install software from the CD when the CD key is not available?” He makes sure to keep a well-documented history of those, as well.

Ansed takes a decidedly low-tech approach to documenting tech support calls.

“I attach a pocket containing a small notepad to the side of the computer. I then add entries for everything I do to that computer from running MS updates to when the system was last backed up,” he said. “This also provides an extra bonus that my clients can add entries for any problems they have if I am out of the office.”

He said he likes this approach because it works even when the machine you’re servicing doesn’t. You don’t have to worry about carrying a laptop to access a remote history or fumbling to try and find it somewhere else because the notepad is right on the machine, he said.

For a little more modern approach, several readers suggested creating a searchable database that can run on a PDA. Comptech3 articulated the allure of a PDA-based history very well.

“I get the advantage of a searchable database in the palm of my hand, but I also find that I tend to document more by using the PDA,” he said.

True tales of documentation dilemmas

Do you have a problematic approach to support that makes documentation especially hard? Post it below and have our members provide suggested solutions.