The Power of Good Documentation in Technical Spaces

One of the most overlooked efficiencies there are is with excellent documentation within technical spaces. Poor documentation can leave support agents and engineers searching for that email or shared file from 2 years ago.

A good example in cost savings is an agent spending an extra 8 minutes on 5 tickets per day looking for an item or escalation point where the documentation was unclear will cost 40 minutes per agent per working day. If there are 35 technical staff spending an extra 8 minutes a day because of poor documentation over 5 times that is over 23 hours of productivity time alone. If the technical staff, on average, earn $32.00 per hour that is $746.67 per day in costs due to poor documentation. This is $3,733.33 per week or $194,133.33 per year due to poor documentation. This can be scaled up or down for the organization. Smaller organizations will see less cost but their documentation load may also be lower than larger organizations. With only 5 tickets needing an extra 8 minutes the time and cost quickly adds up.

Added to this cost should be the fact that during the 8 minute wait it is often at least 2 employees held up for the 8 minute time period not just the technical employee. This will add to the cost. Better efficiency can also reduce stress in the work place giving the senior leadership more resources, time, and finances to spend on improving the business in other ways.

It is worth noting that poor process and procedure also have a similar cost and lower efficiency effect within a business and team. Additionally, if five to six of issues like the given example are found in one department it can quickly add up to over a million dollars.

Some components of a good documentation system is status such as draft, published, review, and retired statuses of documents. Who authors the documents is also important. Another good starting point is having the ability to show the knowledge team or manager all the documentation in the system. Have the knowledge agents if any are working under a knowledge manager they should be able to at least see their own articles. Some fields to include would be: Title, Operating System, Version, Date, Author, Approved By, Body, Keywords, Tags, and Related.

When writing documentation a good thing to remember is that the article may be read by someone either new to the team it is for or new to the organization. While never every detail of how to open email software may be included in an engineering level article it should include enough information to make sense for the level of end-user the articles are written for, including those team members who will be on-boarded.

If articles are written from the start for those newer to the organization this will have a long-term down stream effect on lowering on-boarding, transition, and advancing cross training costs. In addition it can speed up after hours or holiday support if the information is easily accessed by the correct people. The example previously mentioned applies in all these scenarios as well.

Repositories of any information should also be secure. In light of this proper encryption and data access control is necessary for any repository of company documentation. This is particularly the case with information that may contain technically sensitive information such as IP Addresses, MAC address, any known vulnerabilities, and details of the company’s technical assets.