These days, business owners have started calculating Return on Investment (ROI – more on this later) for each penny that they put into their business. So it is very important that you too should know how to calculate ROI on Technical Writing so that when the time comes you can prove your worth to the company.

What is ROI and why is it important?

ROI stands for Return On Investment. Here is how it’s calculated:

Return on Investment = (Total Return on Investment – Actual Investment) / Actual Investment x 100

(ROI is usually calculated in percentage; hence, added 100 at the end.)

For example, if you create a fixed deposit in a bank of Rs. 1000 and by year end you receive Rs. 1400, then the ROI of this investment would be

(1400 – 1000) / 1000 x 100 = 40%

It is important that you calculate ROI from each investment that you make so that you can make an informed decision on which investments fetch higher returns. Same holds true for businesses.

Why is it important to calculate ROI on Technical Writing?

Most technical writers take pride in the fact that they can write error free English with perfect grammar. However, these days, most Devs and QAs can do that too (trust me on this). Heck there is hardly anything unique that a tech writer can do which a Dev or QA cannot.

You might come back to me and say “You know what, Devs don’t want to write guides and manuals and stuff like that…” and I will agree with you on this. But when the management pressurizes them to do something, then they have to do it whether they like it or not. (I have seen this happen quite a few times.)

So how can you differentiate between a manual written by a developer and a manual written by a Technical Writer. The answer is by calculating the ROI for both, and I can assure you that a manual written by a Technical Writer will have a much higher ROI because the writer keeps the user in mind whereas the Devs or QAs usually tend to keep the product/features in mind while documenting a product.

Sometimes Technical Writers forget that a technical writer’s job is not to write perfect English, strictly follow style guides, or learn all the technical writing tools that are available in the market. But a Technical Writer’s job is to help users in effectively using the product that they are documenting and helping users in getting the most out of the product.

How to calculate ROI in tech writing?

The simplest and the best way to calculate ROI on Technical Writing is to measure the decrease in the amount of support calls. You can measure this for a particular feature or for a particular issue.

First, get in touch with your support team, and ask them which are the most common questions that customers ask and the number of calls that they receive for each issue. Note down the number of calls that they receive for a particular issue.

Then, check if the required resolution of the issue is already existing in the docs. If yes, then check whether the information is adequate to resolve the issue. If not, rewrite the content to ensure that the required information is present.

Also, ensure that the when customers search for help on the particular issue, the right topic should appear at the top of the search results (this is very important because customers always search for resolution on a particular issue).

Do these for a few selected issues.

After you have resolutions to the selected issues, go back to your support team, and ask them to check with every customer on whether they tried to check for the resolution of the issue in the docs. If not, ask the support team to ask the customer to go through the documentation that is related to the issue (This is an important step because the support person should judge how crucial the issue is. If the issue is really pressing, then they should provide the resolution immediately rather than asking the customer to go through a document. If the customer has some time to spend, then the support person can ask them to go through a document to get the issue resolved).

If the customer is not able to resolve the issue using the provided documentation, the customer support should ask customers why they were not able to resolve the issue using the provided document. This feedback will help you in improving the content in the document.

Continue this for a month and then you should be able to calculate the amount of support calls that customer support received before the document existed and the amount of calls they received after the document was created. Ideally there should be a significant reduction in the amount of support calls.

Note that calculating the reduction in support calls is not the only metric by which you can measure the ROI on technical writing. But this is a good way to get started.

Conclusion

In the end, after reading this post you might say, “Do I really need to do all of this?” My reply would be “Yes, you should, because doing all this will help you to keep your job so that you will not have to settle for Plain Rice if you want to go for Veg Biriyani”.