As a technical communicator, whether you’re a writer or a trainer or both, have you found yourself troubleshooting with an end user? If so, you may have thought to yourself, “I’m a tech writer, not tech support!” The line between training and support is thin and therefore easy to cross. Some companies consider them the same thing, so there is no line as far as they’re concerned. But there are fundamental differences.

The next time you’re visiting a Web site that offers products or services, look for the location of the company’s documentation, training, and support information. Chances are, you’ll find them on the same part of the site. For example, on Adobe.com, all documentation and training resources are grouped in the dropdown menu under “Support” in the nav bar.

I draw the line between training and support where the line lies between their purposes. Training is preparatory and foundational, and support is responsive.

When you train someone you’re teaching her how to use the product. Training typically comes when someone begins a job or purchases a product so that she can start off on the right foot and do things correctly and efficiently from the first day. Getting-started guides, workshops and classes, and tutorials are developed in order to train.

“Support” typically indicates a response to a problem that the user has. The user has been working for a while and stumbles into an obstacle. Tech support agents, knowledge bases, troubleshooting guides, and forums are put in place to meet support needs.

A live trainer especially can easily slide into support. In fact, that has happened a little in our team at work. Learners hear the trainer’s voice, and they know that he understands the product. He himself becomes accustomed to answering questions and explaining the product. Especially if the trainer is employed by the company who distributes the product, he may find himself receiving emails or phone calls from the people he trained. Therefore, it is a good idea for the trainer to keep his contact information to himself and emphasize the route that the learners should take to get help.

Our service desk team is a clearly defined group, and our team is a separate group. The two have had contact and try to coordinate, for documentation straddles the line between training and support. Out of the examples of training and support I listed above, half are materials that technical communicators create.

Documentation can cover both fronts. I have created help systems that take either or both approaches. Some are task-based, which is more of a training approach, and others are context-sensitive, presenting information that I hope answers questions about how the system works.

You may wonder what the big deal is if a tech writer or trainer steps over the line into support. I think it’s fine if it’s in your job description or if you happen to be in a position to help a user troubleshoot every once in a while. But if you have plenty to do in your role as a technical communicator, stepping into tech support shoes may sap your precious time. If our team were to let ourselves be handed support responsibilities, it could quickly get out of hand and prevent us from filling our primary role: documentation and training.

I look at training and support as siblings. They should have some coordination and contact, which is beneficial especially for the technical communicator, who can see the problems that real users are having. Then the training or documentation materials can be updated to address user problems so that support has the time to handle the big calls.

Related entries (auto-generated):

I Admit It: Sometimes I Like to Play Tech Support

Captivate Training Simulations Perfect for a Scripted Presentation

The Result of Working with the Stakeholders on Our Training Scheme

Three Tips for Effective Web Conference Training

Four More Reasons Your Company Needs Technical Communicators