SaaS knowledge base: the two kinds and how to build

TL;DR. A SaaS knowledge base is the self-service library that answers your customers’ questions so they don’t have to open a ticket. The part most guides skip: a SaaS company actually runs two knowledge bases — the customer-facing help centre, and the internal wiki where support, engineering, and product write things down for each other. They have different readers, different tools, and different success metrics. The number that tells you the customer one works isn’t page count. It’s how many questions it answers before a human has to.

Every SaaS company eventually discovers it is also a documentation company. Nobody puts that on the pitch deck. A SaaS knowledge base is the self-service help centre where your customers find answers without emailing you — the searchable set of articles, guides, and how-tos that sits between a confused user and your support inbox.

That is the direct answer. The useful answer is longer, because the phrase quietly covers two different things, and picking the wrong one is how teams end up with a customer help centre that reads like an engineer’s runbook. (We’ve all met that help centre. It opens with “Prerequisites.”)

This post covers what a SaaS knowledge base is, the two kinds every SaaS company runs, why it earns its keep, what goes in one, how to create a self-service knowledge base step by step, and a few real examples worth stealing from.

What a SaaS knowledge base actually is

A SaaS knowledge base is a cloud-hosted library of articles that helps customers use your product on their own — feature docs, setup guides, troubleshooting steps, and answers to the questions your support team is tired of typing. It lives at a public URL (usually help.yourproduct.com), it’s searchable, and its whole job is deflection: answering the question before it becomes a ticket.

That’s the customer-facing definition, and it’s the one the search results mostly mean. For the broader category — what a knowledge base is in general, internal or external — see our what is a knowledge base explainer. For the buying side, the knowledge base software roundup covers the tools.

The reason the term gets slippery is the next section.

The two knowledge bases every SaaS company runs

Here’s the distinction the top search results flatten, and it’s the one that decides which tool you buy.

A SaaS company runs two knowledge bases, not one:

	Customer KB (help centre)	Internal KB (team wiki)
Who reads it	Your customers, the public	Your employees
What it’s for	Self-service support, onboarding	Running the company
Writing standard	Polished, beginner-friendly, branded	Operational, terse, assumes context
Where it lives	Help-centre software	A wiki
Success metric	Ticket deflection	”Did anyone have to ask in Slack”

The customer KB is the help centre your users see. The internal KB is where your support agents look up the actual answer, your engineers keep runbooks, and your product team files decision records. The first is marketing-adjacent and lives in help-centre software (Zendesk Guide, Intercom, Document360, HelpScout, GitBook). The second is a wiki, and it’s the one we go deep on in the internal knowledge base post.

They feed each other. A support agent answers a novel question once, writes it into the internal wiki, and the best of those graduate into public help-centre articles. The internal KB is the draft; the customer KB is the published edition. Trying to run both in one tool is the classic Confluence-space-that-became-a- help-centre mistake — it serves neither audience, and it gets re-platformed within eighteen months.

This is also the honest part. Raccoon Page is not a customer help centre. If you need a branded public portal with feedback widgets and buyer-tuned search analytics, the answer is a help-centre tool, and we’ll happily point you at one. Raccoon Page is the internal wiki your support, engineering, and product teams write from — the place the answers exist before anyone polishes them for customers. Knowing which problem you’re solving is the whole first step.

Why a SaaS knowledge base earns its keep

The benefits every SaaS-KB post lists: fewer support tickets, faster onboarding, happier customers, lower churn. All true. A customer who can’t figure out your product at 11pm doesn’t email support — they cancel. A knowledge base is the thing that’s awake at 11pm.

But “fewer tickets” is a direction, not a number, and most teams measure the wrong thing. They count articles. Article count is a vanity metric — a help centre with 400 articles and a broken search is worse than one with 40 articles and a good one.

The number that matters is deflection rate: of the people who land on your help centre, how many find their answer and don’t open a ticket. You measure it with two signals your help-centre software already tracks — search-success rate (searches that end in an article view, not a dead end) and the ratio of help-centre sessions to new tickets. When deflection goes up, support load goes down, and the help centre is doing its job. When it doesn’t, you have a findability problem, not a content problem — and no amount of new articles fixes that.

Which is the quiet thesis of everything we build: a knowledge base that’s slow or unsearchable is a knowledge base nobody uses. Pages should load in well under a second, and search should return the right thing on the first try — for customers and for the support agent looking up the answer while the customer waits. Speed isn’t a luxury feature here. It’s the difference between self-service and a second tab full of “still loading.”

What goes in a SaaS knowledge base

The content types that pull their weight, customer-side:

Getting-started guides — the first-run path, account setup, the do these three things first article. The most-read page on any help centre.
Feature documentation — one article per feature, what it does and how to use it. The backbone of the KB.
Troubleshooting and error guides — the “X isn’t working” articles. These are the highest-deflection content you’ll write, because they catch people at the exact moment they’d otherwise file a ticket.
How-to / task guides — how to export your data, how to invite a teammate. Short, specific, screenshot-heavy.
FAQs — billing, plans, limits, the can I do X questions. Boring, load-bearing, endlessly searched.
Video walkthroughs — for the workflows that are genuinely easier to show than to write. Used sparingly; video is expensive to keep current when the UI changes.
Release notes and changelog — what shipped, what changed. Doubles as a trust signal that the product is alive.

The internal wiki holds a different set — runbooks, decision records, onboarding docs, postmortems. We list those in the internal knowledge base post and go deep on writing a single great article in how to write a knowledge base article.

How to create a self-service knowledge base

The seven steps, minus the filler the SERP turns into 3,000 words.

Pick the platform first. Help-centre tool for the customer KB; a wiki for the internal one. This is the load-bearing decision, and most guides save it for last. Decide who the KB is for, then pick the tool shaped for that reader. Our how to build a knowledge base post covers the platform-first discipline in detail.
Mine your support tickets. Your next 30 articles are already written — they’re the 30 most-repeated questions in your support queue. Sort tickets by frequency. That’s the content plan; you don’t have to invent one.
Outline a flat structure. Categories the way a customer thinks (Getting started, Billing, Integrations, Troubleshooting), not the way your org chart thinks. Five to eight top-level categories is plenty. A 47-section taxonomy on day one is how KB projects die.
Write the articles short. One question, one answer, one screenshot. Title each article as the question the customer would search (“How do I reset my password?”), not the feature name. People search problems, not nouns.
Make search the front door. Most people skip the navigation and type. If search is unreliable, the KB is unreliable. Test it on typos and approximate phrasings before you launch, not after.
Put the KB where customers already are. Link it from the app, the in-product help widget, the footer, the onboarding emails. The best help centre nobody can find deflects nothing.
Measure deflection and prune. Watch search-success rate and ticket volume. Update the articles people actually read; archive the ones nobody opens. A small, current KB beats a large, stale one every time.

The hard parts are steps 5 through 7 — findability and the upkeep habit. The writing is the easy bit. (It is always the writing that gets all the credit and none of the blame.)

SaaS knowledge base examples worth stealing from

You don’t need to invent the shape. The best SaaS help centres are public — go read them. A few worth studying:

Stripe’s documentation — the gold standard for developer-facing docs: copy-pasteable code, ruthless structure, search that actually works. If your product has an API, this is the bar.
Slack’s Help Center — task-shaped articles titled as the questions people ask, with suggested searches and tight internal linking. A masterclass in titling articles like search queries.
Notion’s Help & Support — a clean category structure and short, screenshot-led articles for a product with an enormous surface area.

The pattern across all three: simple navigation, a search box that finds things, articles titled as customer questions, and content that’s obviously kept current. None of them win on article count. They win on the reader finding the answer and closing the tab — which is the only review a help centre ever gets.

For the internal side of the examples question, the internal knowledge base post sketches what each internal artefact looks like, and the AI knowledge base post covers the answer-from-the-docs layer that’s becoming standard in 2026.

Things people actually ask

What is a SaaS knowledge base? A cloud-hosted, searchable library of help articles that lets customers solve problems on their own — feature docs, setup guides, troubleshooting, and FAQs. Its job is deflection: answering a question before it becomes a support ticket. Most SaaS companies also run a second, internal knowledge base for their own team.

What’s the difference between a customer and internal knowledge base? Audience and writing standard. The customer (or self-service) KB is public, polished, and beginner-friendly, and it lives in help-centre software. The internal KB is for employees — operational, terse, wiki-shaped. Running both in one tool usually serves neither audience well; see our internal knowledge base post for the team side.

How do I create a self-service knowledge base? Pick the platform, mine your support tickets for the 30 most-asked questions, outline a flat customer-shaped structure, write short single-question articles titled as search queries, make search the front door, link the KB everywhere customers already are, then measure deflection and prune. The findability and upkeep steps are the hard ones; the writing is the easy one.

What should a knowledge base for customer service include? Getting-started guides, per-feature documentation, troubleshooting and error articles, task how-tos, billing and plan FAQs, and a current changelog. Troubleshooting content deflects the most, because it reaches people at the exact moment they’d otherwise contact support.

What are good SaaS knowledge base examples? Stripe’s documentation (developer docs), Slack’s Help Center (task-titled articles), and Notion’s Help & Support (clean structure at scale) are three public examples worth studying. The common thread is findability, not volume — simple navigation, real search, and articles titled as the questions customers ask.

How do you measure if a SaaS knowledge base is working? Deflection rate, not article count. Track search-success rate (searches that end in an article view) and the ratio of help-centre visits to new tickets. Rising deflection means the KB is doing its job; flat deflection with growing content means you have a findability problem, not a content gap.

Should the customer help centre and the internal wiki be the same tool? Usually not. The two have different readers, writing standards, and URL needs. A few tools will technically host both, but the public surface ends up compromised. Most teams of any size land on a help-centre tool for customers and a wiki for the team — and let the wiki feed the help centre.

What software should I use for a SaaS knowledge base? For the customer help centre: Zendesk Guide, Intercom, Document360, HelpScout, or GitBook. For the internal wiki: Confluence, Notion, or Raccoon Page. They’re different categories of tool on purpose; the knowledge base software roundup breaks down the wiki side.

A SaaS knowledge base is two jobs wearing one name: the help centre your customers read, and the wiki your team writes from. Get the split right and the public KB stays answerable while the internal one stays honest. Get it wrong and you ship a help centre that opens with “Prerequisites.”

If the internal side — the place your support and engineering teams keep the real answers — is slow, scattered, or somewhere nobody opens, that’s the part we built. Raccoon Page Free is three users, one space, a hundred pages, and no card; pages load in 50-150ms and the keyboard does the rest. Already have a wiki full of half-answers? The ten-minute Confluence import or the Notion import is the shortest path to one your team will actually open — right before they stop asking each other in Slack.