Encouraging Support Teams To Write Help Docs

In Ask Help Scout, long-time customer service professional Mat “Patto” Patterson answers readers' most challenging customer support delivery, leadership, and career questions.

Hello Umar,

You are absolutely correct that your customer service team has the knowledge needed to create effective, clear help documentation. In one sense, a lot of one-to-one support is like writing a help document that’s super specific to that one customer.

Some customer service folks will love the chance to spend time out of the queue writing help documents. For those people, all you need to do is protect their time so they can get it done.

Writing documentation is hard to do in small bursts, so you’ll need to find a way to give them uninterrupted blocks of writing time (I’d say two-hour blocks as a minimum). Make sure that any ticket metrics are adjusted to account for this non-queue time, too.

If you find that some people are more hesitant to write documents or they agree to do it but fail to follow through, there are a few angles you can take to improve matters.

First, do they understand the value of a great knowledge base as a tool to reduce effort for customers and make their own jobs less repetitive? If not, begin the discussion there.

Second, offer some training. Creating a help document means writing for a wider audience. People arrive at a help document with different problems, levels of skill, expectations, and reading capacities. Crafting something that can work for all those people isn’t easy. Communities like Write the Docs are a great place to find resources to develop technical writing skills for those interested.

Third, create the right environment to encourage the creation and maintenance of your knowledge base. I mentioned protecting their writing time earlier, but you might also consider adding a new metric for “additions to the knowledge base” to track the progress of individuals and of the team.

Apart from clear metrics, the best thing you can do is to reduce the friction between “this should be a help document” and the document being written and published.

When any team member notices a missing document or one that needs improvement, what should they do? Ideally, they can tag it in your help desk, mention a colleague, or cc an address — or any similar approach that takes very little time.

That way, whenever anyone does have time to write help documents, they don’t have to scrounge about for ideas; they can just work down the list. With a system like this, every support person can help improve your knowledge base, even if they can’t personally write the documents.

I gave a talk at Web Directions Australia that lays out the combination of support and technical writers, and it includes some example processes from other teams. I think you’ll find it useful:

You can read more in my related article.

My last suggestion is to find the person who cares most about documentation, and let them drive the project. They can be your point person while your team is small, and it may allow them to run a documentation team in the long term.

Good luck!

Have a question for Patto?