Support Driven is a community of over 2,000 people who care deeply about customer support. By joining their Slack team you can learn from your peers, share your own ideas, and even get a virtual hug when you need one.
This month I asked the community for their advice to someone just starting to build out their knowledge base. Whether you’re starting from scratch, looking to expand, or rethinking your knowledge base approach, their advice will help set you on the right path.
1. Build to a plan
“Make a skeleton plan for how you’re going to organize it before you start (but be prepared to potentially totally redraw that plan at some point!).”
- Katie Thomson, Customer Support Manager at Transit
Knowledge bases tend to grow organically, as new FAQs are added or new features are documented day to day. If you don’t have a greater structure in mind, you can end up with an unwieldy mass of information that’s difficult to navigate and hard to maintain.
Help Scout’s own Emily Triplett Lentz has experienced the same issue: “Many knowledge bases are originally built by simply answering the most frequently asked customer questions. A set of ‘How do you X?’ pages on its own is not good information architecture.”
Morten Lundsby of UserChamp suggests a better alternative: “Organize content based on your user’s paths (where are they coming from and going to?) instead of topic-based content buckets.
Too many knowledge bases are structured around the internal workings of the application or service, instead of matching the tasks the customers are trying to accomplish.”
2. Use customer questions to prioritize and tweak your content
“Knowing your audience is key and it’s okay to have to work backwards sometimes. I have learned a lot about content and writing it based on e-mail correspondence from users.”
- Ashley Sachs, Customer Support Manager at Appear.in
Use your customers’ own words to describe and answer their issues, rather than your own internal labels for concepts and features. If you call them “pre-fills” but all your customers think of them as “templates,” your help document titles and copy need to say templates (in addition to your own term).
Your customers will also help you know which topics to start with. Jen Southan, Director of Customer Experience at TeamSnap, says, “We spent a bit of time looking at the top ticket drivers in our support system. We started with making sure we had great content for those topics and then moved down the list from there.”
3. Treat your knowledge base like a product
“The knowledge base is a product, and should be managed like one.”
- Morten Lundsby
Documentation should not be an afterthought, constantly lagging behind the customer experience. Considering it as a product means making documentation a required part of a new release, including it in your testing schedules, and assigning regular resources.
Denise Twum of SmugMug recommends finding people outside your team to help make that happen: “Try to identify other stakeholders outside the support team who may be interested/invested in the knowledge base, as it is one of the public faces of your company.”
In particular, if you’re documenting a frequently changing product, it is important to make correct documentation a formal part of the release process. Ashley Sachs faced that challenge:
“We have a super small distributed team and the devs work pretty fast … we were running into the devs releasing things while I was sleeping and not even knowing about it until a customer asked a question or mentioned it on social media.
“So documenting the process helped with communication and accountability as well when it came to myself and the dev team collaborating.”
4. Make it measurable
“Make sure you have a customer experience metric tied to knowledge base articles, for example a CSAT or resolution survey”
- Jessica Malnik, Community Manager, Content Strategist, and Writer at DynamiteCircle.com
If you’re treating your knowledge base as a product and want it to continue to get investment of time and resources, you need to show results.
You may also directly ask visitors to help pages whether the page has answered their query or not. You can record who is visiting the knowledge base, how long they stay on the page, and where they go next.
Over at Kayako you can even download a super handy Help Center Health Check Template for helping you track which ones are being used and which ones need to be retired.
Denise Twum says, “In the end, what is the purpose of the knowledge base? To help your customers so they help themselves, and to also reduce support volume. … Tracking metrics can help you see whether the knowledge base is doing what you expected it to do.”
5. Test your work
“Do user testing (task based, screen sharing) on the main paths and content.”
- Morten Lundsby
In addition to passively measuring your knowledge base content, direct user testing can help you spot potential problems. Can users find the right document? Is the page readable to them? Does the search feature return the expected results?
Create some sample knowledge base tasks and have typical users talk you through how they would solve them. Watch, learn and improve!
6. Use a style guide
“Taking time to decide what you want your tone and approach to things like bullets, phrasing, etc. to be early on can help with ensuring a consistency of voice across articles that may be written by different people.”
- Emily Kinzig, Member Support Specialist, NerdWallet
Be kind to your future self by making some decisions on style and voice up front. Your company may already have a style guide you can adapt, or take a look at Help Scout’s own guide for inspiration.
7. Set up regular content reviews
“Have a very specific cadence for reviewing/updating content to make sure it doesn’t go stale. My rule of thumb was that each FAQ had to be reviewed at least once a quarter.”
- Derek Homann, Co-founder of Median
Planning ahead for reviewing and updating your existing documentation means you can (mostly!) find and fix issues before they impact your customers.
Your knowledge base tool may let you sort your content by updated date, or you can keep your own list and make maintenance a recurring documentation task.
Bonus tip: Engage with other teams
Knowing how to create effective help documents is essential, but if you want long-term investment and support from your company, you’ll need to develop new skills.
Carlee and Craig, Campaign Monitor’s technical writing team, recently faced that challenge.
Watch the full interview to hear how they redesigned and migrated close to 400 help documents.