My 4 principals of support documentation

text

Whichever one of my talks you listen to, I make a point of adding in something relevant about how important documentation is. Because, it doesn’t matter which aspect of remote working or customer support you discuss, documentation is there, somewhere, as a point to be made.

To condense everything do, I have 4 basic principals. And the 1st one is the most important of all.

1. Document everything

Unless you get an obscure question that you know will NEVER be asked again, document all support answers.

That way, your support team should only ever need to investigate any issue only once. Which is different to “answering” the same question more than once – it doesn’t matter how well everything is documented, customers will ask anyway. In this scenario, you always have an answer, ready-prepared.

In the ideal situation, you should never receive the same question twice, as your customer-facing documentation from the first time it occurred means that they already have the answer. This is unlikely due to the reason I gave before but also because not everything is documented for use by the customer. Which leads us neatly onto…

2. Provide front and back-end documentation

And, by this, I mean documentation both for your internal support teams but also customer facing too. So, as much as possible should be made visible for the customer but, where something can’t be (e.g. a process that only the support team can do), ensure that’s documented too.

Ensure you have a simple, fool-proof method to be able to search both sources at the same time.

3. Don’t duplicate content

By duplicating content you make it harder for yourself to make changes in future.

Let’s take an example – a WordPress example. You create a general document explaining how to install and activate a plugin. You also create a separate document all about a specific plugin and, as part of that, you explain how to install and activate it. Now that details is in 2 places. What if your advice on how to do this changes in the future? You’ll have to remember where it’s been documented and change each one.

Wouldn’t it have been easier, in that second document, to have just directed people to that first document on how to install it?

4. Write your words first

Pause and add images and other media later.

During that pause ensure that the documentation can be fully understood. Other media, such as screenshots, should assist but shouldn’t be used as a crutch – the text should be good enough to explain without the use of anything else.

Additionally, screenshots are not accessible, so some people may be reliant on the text descriptions.

Fully describing something in just words is a skill that should never be underestimated.

Talk to me!

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from David Artiss

Subscribe now to keep reading and get access to the full archive.

Continue reading