Sharp Words

[Just a note: I'm aiming to get back to a more regular posting schedule for my Technical Writing Tuesday posts. My current intention is to post on the 2nd and 4th Tuesdays of the month. Topic suggestions are welcome!]

The good news: having quality, easy-to-read, frequently updated documentation for your product can reduce support calls, entice customers and contribute to profits.

The bad news: there are very few studies out there which show this, which means that trying to convince your boss that you should write more documentation and you need more resources (training, new staff and so on) can be pretty difficult.

If you’re lucky, your company knows the worth of its documentation, at least qualitatively. However, if a technical publications department is asked to prove its worth quantatively, it isn’t always easy. And in these days of recession and tightening belts, it’s possible that we technical writers may have to justify our positions.

There are a few ways of getting some actual numbers about who’s reading your documentation and about its benefits. As mentioned, there aren’t a lot of studies out there – at least not necessarily ones readily available online – which give examples of the cost benefits of technical writing (the type that managers care about), so you’re going to have to develop your own way of quantifying your contribution.

If your documentation is hosted on a website, it’s pretty straightforward to set up some sort of hit counter. These come in various levels of sophistication, from a simple counter to something like Google Analytics which can tell you exactly when, from where and how readers reach your site – and even why, if they reach it from a search, which also lets you see if they were looking for something you don’t currently have. Some knowledge base software also enables you to log readers’ queries, so you can see if there are gaps missing in your documentation set.

If you’re launching a new knowledge base, or releasing guides or help for a previously undocumented products, ask your product’s support team to keep a note of how many calls they used to get about the product, and how many they get after the document’s release. This is possibly one of the most useful statistics you will ever have, as it can be used to demonstrate how much less support time is taken up compared to the time invested in creating and maintaining the knowledge base or guide/help. (Of course, the support manager might not be so delighted if they were hoping to expand their team!)

Check with your sales people too, to see if any customers have demanded particular documentation; some might even make it a condition of the sale. Certain industries have legislative requirements for documentation as well. If you can prove that a sale was made because a guide existed – or you could produce one at short notice – then you’ve got a very solid argument for the ‘value added’ by the tech pubs department. (I hate that phrase, but it is a useful one sometimes!)

Further reading: Cherryleaf – Benefits of using a technical author (has some numbers towards the bottom as well as other useful information)

————–
If you have any questions or comments about this article, or any suggestions for future posts, please comment on this post or email me via my contact form.
Technical Writing Tuesdays: index of posts