The Benefits Of A Support Ticket To Documentation Lifecycle

I think that support tickets are an unsung fantastic source material for technical documentation. Every devrel should read support tickets and the answers, even if they don’t respond to them.

This post applies to any kind of support request:

• support tickets filed in a tool like Zendesk or Intercom
• bugs/feature requests filed wherever you accept them
• questions frequently reported by sales engineers
• community support channels like Slack or Discord

But I’ll use the shorthand ‘support tickets’ to apply to all ways your users ask for your help.

Reading these help you understand how your users are working with your software. They illustrate sharp edges and places where folks run into issues and don’t understand how to get past them.

Here’s how I turn support tickets into documentation.

• Read all the support tickets. I get an email for each one.
• If it is a generic issue, I forward it to myself in a week. This gives the support team time to dig in and answer it.
• In a week, if the answer is not present, I re-forward it. If the answer is present, I paste the link into a slack channel.
• Someone (used to be me, now it is another team member) reads the slack channel and refines the support ticket into a clear, generic, question and answer.
• The question and answer get posted to our forum.
• If there are clarifying changes to documentation, they get made or put into a queue.
• If the question and answers come up repeatedly, I look into making a standalone technical doc. And then tell the support team and sales team

Why post the q&a to a forum rather than immediately turn it into a doc?

I like forums for many reasons, but in this case, a post to a forum is, crucially, timestamped. Technical documentation should be accurate forever (that is the goal).

A forum post, because it has that timestamp, doesn’t have to be. It has to be true for that moment in time.

Sharing that knowledge is valuable but imposes far less future costs on the organization. You do impose costs on the end user, however. They have to evaluate the accuracy and applicability of the forum post based on timestamp, number of views and other comments on it. At least it is not an unanswered question.

I believe the tradeoff is worth it because it lets many more users benefit from the research and knowledge of the support team at extremely low organizational cost. It also helps LLMs (who love the q&a format) and improves your long-tail traffic from search engines, helping your SEO.

Reading support tickets not only helps you build content, it also makes you aware of where users are confused. This is super helpful for devrels looking to make high-impact example apps, videos and other documentation. If 10 folks don’t understand how to use feature X and cared enough to write in, you should probably document feature X in some way. Following around product experts like your support team and converting what they have written to generic posts is a great way to teach you important details about commonly used features and issues of your product that you might otherwise have never known.

What this process is not is quick. You can’t create content for non-existent support tickets. And it won’t create a solid documentation user experience if used in isolation. Make sure you handle common important use cases and add these ad-hoc docs into the appropriate place in a larger documentation architecture.

It also may be harder to implement this lifecycle in a larger organization. I only have experience with it in smaller orgs.

When you do create standalone documentation for common issues, your support team will thank you. In my experience they’ll reference it going forward, and other users will also find it using Google, your site search, or an LLM.

So you decrease the support burden at the same time as you increase discoverability. Yahoo!