I’m at Write the Docs today in Portland and will be posting notes from sessions throughout the day. These are all posted right after a talk finishes so they’re rough around the edges.
Nisha and Elaine work at Twilio where a large portion of documentation is owned by the support team.
Why do people write to support? They’ll ask questions like “Can I do…”, “How do I…” as well as report things that are broken. A customer company thinks of documentation as something that is helpful to your customers as well as helpful to the company. From the company perspective docs provide a consistent answer that’s inline with what the company wants to convey. Documentation is, essentially, a way to maintain a healthy relationship with customers and maintain expectations.
Support can own docs that compliment engineering docs. You don’t need to spend a lot of time gathering topics for docs. Every ticket that comes in to support is an opportunity to document the answer to that. Documentation, then, can decrease the increase in growth your support team sees in tickets.
A primary goal for your documentation should be making answers easy to find. Having questions be phrased as the customers ask them is just one way to do this. The overall structure of a knowledge base is also important. It has to be logical. Creating those buckets for common questions and tasks with your application can help guide a user from one piece to the next. Finally, your docs have to be searchable. Not having that is a deal-breaker.
Your customer support team takes care of new features, products, and bugs while the documentation takes care of known issues, features, products, and workflows.
How will you know that you’ve created a successful documentation structure? First, customers will become doers. They’ll trust that they can become self-sufficient with your documentation.