Tag Archives: technical writing

The Case of the FAQ

Tech support follows the Pareto Principle: 80% of the support requests involve just 20% of the questions that users have. These frequently asked questions tie up resources that could be used on other problems.

The tech support manager can see that his techs are answering the same small set of questions over and over, but the problem isn’t a support issue. Rather it’s a documentation issue: If users come up with the same problems consistently then chances are those issues aren’t addressed, or aren’t addressed adequately, in the user docs.

A technical writer can help free up the support department’s resources. The writer can work with the support techs and review their ticket tracker to identify the most common questions and learn how the techs usually address them. Then the writer can survey the existing user documentation, identify trouble spots, and create new content to help users get the help they need without a call to tech support.

Now your techs have more time to deal with the truly difficult problems. They can reduce escalation to more expensive support levels or even begin to develop a knowledge base to improve the support process overall.

The result is a more effective, more efficient technical support process.

The Case of The Unwary Salesperson

This is the first in a series of posts about how good documentation solves business problems.

It is not uncommon for sales teams to over-promise. Either because your salespeople don’t know the current feature set, or because they don’t recognize the limits of customization, they may sell your customers more than you can easily deliver.

The executive in charge of sales feels the pain in the form of lost sales and irate customers, when it turns out that what they’re getting is not what they thought they were buying. The Director of Engineering (hardware or software) feels the pain when he or she gets a brush fire in the form of a customization order for a client that simply can’t be left unsatisfied.

Both scenarios – lost sales and cost overruns for customization – hurt the company’s bottom line. Unhappy customers hurt your company’s reputation and reduce future revenue.

The solution is better documentation. Sales training materials can keep the sales team up to date on the latest feature set and when new features are expected to roll out. Reference cards can keep the information ready to hand on sales calls. A technical writer can bring the sales team and product development team together in ways that help keep everyone happy.

Silo Busting

Everyone knows that technical writers do documentation. If you need a user manual, marketing collateral, or a better website, you call a tech writer. However technical writers provide another service that is less well-understood or appreciated.

Every business with more than one person has organizational silos: business groups that compartmentalize functions and information. People often communicate fairly well within their silo, but communication is harder between silos. Different silos often have different jargons, ideas, and priorities.

This is an efficient model, most of the time, but it can lead to serious disconnects.

The technical writer is one of the few people on the project who has to understand almost every aspect of it. We can’t afford to take anything for granted, so we often ask questions that no one ever bothered to ask before.

Every technical writer has had this meeting:

Tech Writer: So how does this feature work?
Bob from Hardware: Well, it works like this….
Ted from Software: Wait a minute. It’s not like that at all!

Different silos sometimes have radically different views of a project, and may address the same problem in different ways. If these differences aren’t caught and reconciled, they may hang up the project at the most inopportune time, such as during rollout or worse, after the product is in users’ hands and tech support is giving them incorrect information.

The solution is to bring a technical writer on-board as early as possible. Simply by documenting the project, the writer acts as a filter to spot discrepancies between silos and bring them to the attention of people who can fix them early.