This post was inspired by Melissa Rach’s post on “The Value of Content” on Braintraffic.com. (Good stuff there so go read the original post for the details).
I thought I’d take a stab at converting her steps to my own technical documentation work, and here’s what I came up with:
- Define your content – That would be user guides, references, release notes and the like. What is it all doing? It guides customers in using our products to their fullest potential. If we get into things like troubleshooting guides, then we have an added benefit of reducing support costs to the company by solving customer problems with our content. Desired characteristics? That would be accurate (free of technical errors) professional quality, ease of use/readability, and ease of localization (that comes from our editors who tell us when we are phrasing something impossible for the translation folks to deal with).
- Assign values to your content – This is where educated guessing comes in. Some things can be clearly defined – $500 is the cost for the average Technical Assistance call to the company, so each topic in that troubleshooting guide could save the company $500. If we have 10 topics, and make some assumption like 10% of the 1000 visitors last month to that content found a solution (and thus avoid a support call to the company) we get a number around $50,000 for that troubleshooting guide per month in cost savings to the company. We can extend this model to configuration guides because we know our own support folks point customers to our guides to solve their issues. How about quality and accuracy? Well if we assume a certain cost to the company for fixing documentation errors (Say $100 per doc bug), multiplied by 5 customer-found bugs per month, we run over $6000 a year. But that doesn’t account for customer frustration, and whether or not that documentation error ended up in a customer support call to resolve the issue, plus that support person tracking down the correct writer to fix the problem. If we assume 1 in 5 customer-found bug has an ‘extended’ cost (support call, customer frustration and potential lost revenue) we can say improved quality content saves the company $12000 a year, per product. (For a company with over 1000 products, that number gets very big!) The last way we can quantify content would be to estimate lost revenue. With a deepdive in web analytics, we can determine if our customers come to our documentation from marketing collateral. If we then assume a small percentage of those customers are evaluating the product, then good vs bad quality technical documentation can mean lost sales and that would also be a sizable number. If the average product purchase for a high-tech networking company is $10,000, and poor content leads to just 1% of 1000 potential customers going someplace else, the lost revenue is upwards of $100,000 per product! Again, the numbers get quite big, and then you compare those numbers to what it would cost the company to hire additional top quality writers to address the issues. The average cost of a full-time employee runs around $255,000 (full benefits included). That means one fulltime writer on that troubleshooting guide would still save the company $250,000 annually on technical support calls.
- Measure every way you can – Web analytics can tell you how popular some content is (and some content isn’t!) Getting beyond that, we can again, use support call logs (if available) to determine how often our documentation solves customer issues (and thus shortens the length of a support call). Also, internal email aliases point to our content to help each other out, and then there are customer-facing forums that use our content. Then customer interviews can add to the value equation. What are they looking for and do we have that information? What are their top tasks when using our product? Do we have those tasks clearly covered in our technical documentation?
- Baseline it all – Assign value today, and then use the same analysis after we make changes to determine if we can see measurable improvements. Do we get more hits on certain content? Less technical errors in our documentation because of improved SME review processes implemented? Measure at the baseline and then remeasure six months or more after you’ve implemented change to determine its effectiveness.