‍

Startups ship fast. You release new features, make user interface (UI) changes, and might even rename a few things along the way.

In an ideal world, you'd update your knowledge base whenever anything changed in your product, and run content maintenance checks on a routine basis. But if your team doesn't have someone who can give this their full attention, that might be a touch ambitious.

This guide will give you a good grasp on how to maintain your knowledge base as efficiently as possible, using the resources and team you already have. It's for you if:

• You want to create and maintain a great knowledge base
• You’re concerned about the support debt you’re accumulating
• You don't have a dedicated technical writer creating knowledge base articles
• You're taking responsibility for improving self serve support at your startup

Your support docs are only as useful as they are accurate. Letting them grow outdated can increase inbound support tickets and place extra strain on your customer support team — as well as negatively impacting customer satisfaction and success. This guide will help you avoid that.

‍

What situations require an update to your support content?

First off: it’s okay – normal even — to have some degree of support debt. It’s a sign there’s strong product velocity and iteration.

The problem arises when you don’t take a systematic approach to reducing it.

Update your self service content in the following situations:

You've added a new feature that needs its own support articles

For anything with any degree of complexity, it usually pays to create the docs up-front. A good knowledge base article will deflect support cases before they're raised.

But for features that seem incredibly self-explanatory, you might want to take a wait-and-see approach to creating new articles — as in, don't write the docs until there's proven need for them.

Demand can look like customer support requests, social media comments, product analytics data, or search terms in Google Search Console that indicate customers are struggling to use the feature.

You've released something that impacts the information in existing support docs

Update articles when you add something in-product that impacts existing articles in your help center. For example, if you modify how a feature works, change a navigational element, or introduce new customization options.

You have new insights on content or content gaps

Customer feedback and content performance data can indicate when a knowledge base article isn't as helpful as expected.

Analytics data

You can check your content performance in Google Analytics, or natively within your knowledge base software. Metrics like page views, time on page, or search trends can indicate when certain articles have become less useful to customers.

Review what customers are typing into your help center search bar, and check article feedback scores (% of users finding an article helpful) and comments if that's something your knowledge base software offers.

Feedback or data from your customer support team

Analyze tickets submitted to your customer support team to identify common themes. If they're hearing the same questions over and over, it's possible your knowledge base has some gaps.

You can reduce repetitive support requests by addressing frequently asked questions in your knowledge base articles.

You're preparing to leverage AI for customer support

Your AI assistant is only as good as your knowledge base. An accurate, in-depth knowledge base is the most critical foundation for launching an AI customer support assistant or using ChatGPT for customer support.

If you're looking to test out AI for self service in the next 12 months, get your knowledge base into good shape now.

How often should you edit your knowledge base articles?

Broadly speaking, you should update your knowledge base articles whenever they're out of date. The best way to stay on top of this is to have a good process for both proactive updates (when you launch something new) and maintenance updates (periodically reviewing old content).

There's no one-size-fits-all here: early stage SaaS startups will likely need to review much more often than a company that ships more slowly. If your articles are still up-to-date and performing well, you don't need to edit them.

Aim to review and refresh your knowledge base content multiple times each year: for fast-moving companies, reviewing every 3 months is a good target; for more stable products, every 6 months.

Frequent small updates are easier to manage than massive overhauls. Depending on how much time you can devote to maintaining your knowledge base, you have a couple of options:

Update your knowledge base when you update your product

This is most effective approach to knowledge base management, so we'd recommend starting here. In the long run, creating new docs as they're needed is less time consuming than clawing your way back if you fall behind.

Ahead of a release, speak to your subject matter experts to find out what's changing, and grab all the assets you'll need in advance. Create new articles and schedule updates to existing ones.

This approach is also best for your support team and customers, as it equips them with knowledge base content as soon as the release is live.

You'll still need to make time for routine knowledge base maintenance, but this approach will make it much easier to stay on top of things.

Batch updates on a rolling cadence

If you've tried the first approach and it's not working, this is the second-best way to keep your self serve content fresh for customers.

Block out time on your calendar on a monthly basis (or quarterly, depending on how fast you ship) to edit existing articles in your help center. Prioritize edits to your most popular articles first.

Who's best placed to update your knowledge base?

The people closest to your product are best equipped to keep your knowledge base up to date. They typically have a deep understanding of what's new or changing, which means they already have the information they need for content creation.

If you're taking ownership of the knowledge base but don't currently fit that description, you can get closer to the product by:

• Joining product or dev standups on a weekly basis
• Having regular 1-1s with your product managers
• Reading internal release notes and public changelogs
• Letting your product colleagues know that you'll need their help to maintain the knowledge base, and asking them to bring you in on any relevant discussions or Slack channels

In a small team without a dedicated documentarian, whoever writes the release notes is a good candidate for creating new help center articles. You can ask them for assistance.

For content audits and routine article maintenance, anyone with access to product release notes should be able to update articles (or at least flag them for a rewrite).

What to look for when conducting routine knowledge base maintenance

Maintenance is a big part of the knowledge management process. In your regular knowledge base reviews, check for:

• Guidance that's no longer accurate: This is worse than not having support content at all (especially if it's informing an AI assistant's output) as it's misleading and wastes customers' time.
• Outdated screenshots and video content: Images or video tutorials that feature outdated UI can make it difficult for end users to follow.
• Uses of deprecated terminology: E.g. changes to naming conventions.
• Broken links: Use a tool like Ahrefs to see if you're linking to any internal or external content that's since been removed.
• Missing alt text: Add alt text to images to improve accessibility.
• References to things that no longer exist: E.g. guidance on how to use a promo code if you no longer support them. This can make the end user feel like they're missing out.
• Non mobile friendly content: Check for large gifs and images and that haven't been compressed — they load slowly on mobile. Long articles with large blocks of text may need a few line breaks so they're easier to read.
• Outdated dependencies or integrations: Fact-check any mentions of other software or technology, e.g. compatible browser or OS versions.
• Things that don't adhere to your style guide: E.g. inconsistent capitalization of a feature name.

One large article, or smaller separate ones? Best practice for breaking topics up

As a general rule, each article in your knowledge base should guide users on completing one task, or several small, highly connected tasks.

Example: using one article for connected tasks

Let's say you want to show customers how to update their profile in your product.

You could have one article titled "How to update your user profile", with sections on:

• Changing their profile picture
• Updating their display name
• Adding personal information, e.g. a bio or job title

If all of these actions can be performed from the same page in-product, it makes sense to group them into one article. They're all simple and closely related tasks — and if a customer wants to do one, it's likely they'll want to do another.

Example: using multiple articles in a category

Now, let's imagine your product has several integrations.

It would make sense here to give each integration its own individual page, because:

• The integration process may be different for each product
• "I want to integrate with Slack" and "I want to integrate with Linear" are two significantly different objectives — there's little to no crossover between them.

In this scenario, you can use hierarchical elements like sections and categories to organize your knowledge base and group different articles together.

Guidance for writing knowledge base articles

When writing support docs, you want to be as clear as concise as possible for your end users. Regardless of their technical expertise, all customers will benefit from simple and straightforward explanations.

Language and terminology

Use terms that your audience is familiar with. If technical terms are unavoidable, provide a simple explanation or a glossary link.

Active voice makes your instructions more direct and easier to follow. For example, use "Select the 'File' menu" rather than  "The 'File' menu should be selected.”

Use structural elements

Format your docs so it's easier for your customers to follow step by step instructions, and determine quickly if a guide is relevant to them. In Outverse, you can format docs with:

• Numbered lists
• Bullet points
• Tables
• Tabbed content
• Code embeds
• Headers
• Index galleries

‍

Include visuals where possible

A short video or GIF can demonstrate a process much more effectively than text, especially for complex tasks.

You can annotate screenshots to guide customers through software interfaces or to highlight where they can find specific features.

Diagrams and charts can be great for explaining concepts that involve relationships or hierarchies.

Use visuals in addition to written guidance, rather than instead of — this keeps your help center accessible to customers using screen readers.

Where to start if you've fallen behind with your knowledge base

If you're knowledge base is out of date and you're ready to correct it, you need to do two things before rewriting anything:

1. Create a list of stale articles

In your knowledge base software

As long as you work systematically, you'll likely be fine just running through articles in your knowledge base software. A few methods to consider:

• Start with the most accessed articles
• Start with articles with the lowest "helpful" scores
• Start with the most stale articles (with the earliest "last updated" date)

Some knowledge base software, like Outverse, also uses AI to determine when older articles might need updating, and can nudge you to review stale or unhelpful content. If your knowledge base software can do this, you can save a lot of time vs running through everything manually.

Manually audit your articles

Teams that are extremely behind on their docs might find it easier to export all knowledge base URLs into a spreadsheet. This takes time, but it's methodical and allows you to be thorough.

If you need to work manually through your knowledge base articles, start with the ones that get the most traffic. You can grab a list of URLs from your analytics tool (as well as data on traffic etc.) or a site crawler like Ahrefs. In your spreadsheet, add the following columns:

• Last updated
• Traffic in past 3 months
• Primary topic
• Contains images/video?
• Notes
• Action (e.g. update now, batch with topic, revisit in 3 months...)

You can then group similar tasks together to save time — e.g. rewriting any articles relating to your admin panel, and reshooting any video in those articles.

2. Gather product information

For articles that are super out-of-date, you might need to do some detective work to uncover info on what's since changed. Good sources of information include:

• Previous release notes
• Any relevant blog content written by the product team
• Your issue tracker and roadmap tool (Linear, Jira...)
• The team responsible for the features

Batching updates by topic means you can gather all resources beforehand and don't need to switch context between articles.