What’s the Statistical ROI of Technical Documentation? [Collaborative Post]

What's the ROI of technical writing?Kartik asks,

I have trouble explaining people of the value adds, and measurable differences, and advantages of technical writing. Is there a case study, white paper or any other doc that statistically shows the ROI of technical documentation?

This is a collaborative post, so if you have an insight to help Kartik answer this question, please add it in the comments.

Adobe RobohelpMadcap Flare

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

13 thoughts on “What’s the Statistical ROI of Technical Documentation? [Collaborative Post]

  1. Kai

    Two caveats: I only know ways to argue ROI for doing tech writing WELL, not for doing it in general. And I guess what I point to are methods and examples rather than statistics. Hope you still find it helpful:

    – Ann Rockley, Managing Enterprise Content, chapter 3: “Assessing ROI for a unified content strategy”, pp. 43-62.

    – Rahel Anne Bailie, “Technical Communications Value Proposition: Providing Value and ROI”, intercom, July/August 2009, pp. 4-7.

    – Sarah O’Keefe, “Calculating the ROI for XML and DITA”, http://www.scriptorium.com/2010/10/calculating-the-roi-for-xml-and-dita/

    – Mark Lewis, “DITA Metrics: Cost Metrics”, http://dita.xml.org/resource/dita-metrics-cost-metrics

  2. Anne Gentle

    Hi Kartik – I’ve written up a blog post that could be like a case study for using web analytics to prove return on investment – like how website conversions to a sale can be directly correlated to ecommerce income, how could tech comm web pages directly funnel into revenue or cost savings?

    This post focuses mostly on support cost savings, but a next step would be to apply web analytics to show that tech comm content leads to software downloads and purchases (or some other wanted behavior).
    See http://justwriteclick.com/2010/09/01/web-analytics-for-technical-documentation-sites/.

    I’d also say, the calculation has to have a bottom-line-enhancing goal in the first place, is it to sell software, increase trials, reduce call-based support costs, minimize translation costs?

  3. Scott B

    Although you’d hope management would already be on board with the idea of providing good documentation, it’s true that documentation is sometimes seen as unnecessary overhead, especially for low-cost, bare-bones products.

    Building on what Kai was saying, however, it sounds like you are asking for an easy answer to a touchy question. I think you’d be better off finding ways to demonstrate the value of your particular work then trying to justify the entire tech comm field.

    One good idea I heard for this is to work with your Support department to get statistics on their top user problems. Then systematically address each of those problems in your documentation. After a few months, get updated statistics from Support on those areas, and show the difference to your boss. “My documentation reduced support calls on these areas by X percent.” That’s pretty concrete justification.

    Another idea: the field of User Experience (which documentation is part of) has been dealing with this challenge too. Get a good, accessible book and follow its suggestions or even have your boss read it. There are several out there (search “User Experience” on Amazon). This one looks good, although I haven’t read it yet:


    1. Tom Johnson

      Scott, good comment. There’s just one problem with the methodology of looking at support calls before and after you produce documentation. Support calls spike around product release. If you just release a product, there will be a ton of calls. Then the calls taper off. For this methodology to work, you’d need to have a consistent set of factors that doesn’t change by date.

      I have another possible methodology. I wrote documentation for a product in English. The product is being released in 10 languages, but the documentation isn’t being translated (yet). My hypothesis is that adoption for countries that don’t speak English will be abysmally low. But again, one might attribute lack of adoption to cultural factors, so this research would also be problematic.

  4. Techquestioner

    To calculate ROI on anything you have to have before and after measurements. What statistics do you have, and what do you expect to improve? If you have no statistics yet, go count what you want to increase or decrease.

    In reference to support costs, I worked on one project for a telecom company’s telemarketing center support desk. The company had 4 telemarketing centers around the US supported by a 3-VAX processing center in Atlanta. The two shift supervisors took turns being on call overnight to handle any problems the on-site staff couldn’t. When all the trouble-shooting procedures were documented, the on-site staff could follow them to resolve even very rare or complex problems, and the two supervisors lost all their on-call overtime pay. The ROI on that project was the decrease in overtime pay.

    1. Tom Johnson

      Aaron, thanks for commenting. I remember reading your Forbes post when it came out. I’ve been thinking a bit about the support costs of call centers. One problem with the way IT is run is that project managers aren’t usually responsible for support costs of their product; therefore they minimize documentation and usability, because the company as a whole has to pay for it, not the PM. If the PM were accountable for support, he or she would increase the emphasis on help materials and usability.

      I realize this is a tangent to our discussion of ROI, but it feeds into the topic of support centers. We’re not often connected to support centers in the ways we should be. Most tech writers are completely unaware of the number of calls about the products they documented. Closing this gap with technical writers is the first step. Closing it with project managers is another good step to take.

  5. Chet Kamal Parkash

    Dear Mr. Kartik,
    I am able to figure out your problem dealing with the people. The job of a Technical Writer is to simplify the Technical Jargon and to make them understand the Whatever system you come across.
    Yes definitely,there is a case study, white papers and several other documents that will play an important role to show you the role of technical documentation.
    You can browse over the Internet with refined search for such dcuments in pdf format. Otherwise, i can be reached at : chet.k.parkash@gmail.com for your additional help.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>