Who Should Own the Knowledge Base: Customer Success, Support or Product?

Who should own the knowledge base has one durable answer: a single named editor, in Support at most B2B SaaS companies, who holds the standard, the taxonomy and the publish button, while Product and Customer Success write into it. Shared ownership of a help centre is the same as no ownership. Nothing shared has a calendar slot, a definition of done or a name against it when an article is wrong.

We read 4,978 public G2 reviews of five customer success platforms and 33,600 Reddit posts from r/CustomerSuccess, r/SaaS, r/sales and r/startups covering May 2024 to September 2026. 97 of those reviews (1.9%) mention documentation. Inside r/CustomerSuccess, 117 posts mention documentation, 72 mention a knowledge base and 38 mention a help center. In the threads that name a cause, the cause is a missing trigger, not the wrong team holding the asset.

Two design mistakes sit under almost every stale help centre. The knowledge base gets treated as a project with a launch date instead of a surface with a monthly maintenance cost, so nobody budgets the hours. And the update is triggered by a customer complaint instead of by the release that caused it, which means each article stays wrong for as long as it takes somebody to get annoyed enough to say so.

Four knowledge base ownership models come up in these conversations, and headcount decides between them more than philosophy does. Under about 30 employees the owner is whoever writes well and has the product in their hands. Between 30 and 200 it is a named Support editor with contributor duties written into Product and Customer Success roles. Above that it becomes somebody's whole job.

Customer Success owning the knowledge base is the model that reads most plausible on a slide. A CSM knows what customers misunderstand and has the wording. The problem is the shape of the work: a CSM writes for the accounts in front of them this quarter, so the help centre fills up where the loud customers are and stays empty everywhere else. Support sees the question in the customer's own words, at volume, across the whole base.

One boundary is worth setting at the same time, because it decides what the knowledge base is for. If customers cannot tell a product question from an account question, the help centre absorbs both and neither gets answered well. When should customers contact a CSM instead of support covers how to draw that line without sending people in circles.

A knowledge base goes stale after a product release because the release carries no list of the articles it invalidates. Screenshots are the first casualty and the most expensive one, since a single navigation change can break a hundred images at once, in articles written by six different people over three years.

The same pattern appears on the vendor side of our review corpus, where buyers of customer success platforms describe documentation running behind the product they are paying for. A reviewer who is two releases behind cannot tell whether they have found a bug or an old article, which is the exact confusion your own customers are in.

The invalidation list is what turns that table into a habit instead of a policy. A release ticket that cannot be closed until its list is empty, or waived by a named person, puts the maintenance cost in the same sprint as the change that created it. Nobody has to remember anything.

A knowledge base owner spends most of a normal week on maintenance, not on authoring. A workable budget is four hours of triage and edits, two hours of new articles and one hour of measurement, which is why the duty collapses when it is bolted onto a full ticket queue with no protected time.

1. 1

   Clear the invalidation lists from last week's releases

   Open every release that shipped, work through its list of broken articles, and fix or waive each line. An empty list with a name against it is the record that the release was documented.

2. 2

   Read the site search log for queries that returned nothing

   Search terms with no result are the cheapest article ideas anyone will ever hand you, because a customer typed them while stuck. Write down the top five with their counts.

3. 3

   Tag last week's escalated tickets known-answer or unwritten

   A known-answer escalation is one where a published article would have resolved it without edits; everything else is unwritten. That share is the number you take to the next planning meeting.

4. 4

   Rewrite the two or three articles with the worst outcomes

   Low helpful votes, a high ticket rate from people who read them, a high exit rate. Fix what exists before writing anything new; a wrong article costs more than a missing one.

5. 5

   Publish what Product and Customer Success drafted

   The editor's job here is the standard: one task per article, the customer's words in the title, dated screenshots, no internal jargon, a visible last-reviewed date.

6. 6

   Send three lines to Support, Customer Success and Product

   What changed, what is now wrong, what you need from them next week. This note is what stops the knowledge base becoming invisible to the people who are supposed to feed it.

Measure a knowledge base on two numbers: the share of escalated tickets whose answer already existed, and the share of published articles never reviewed since the feature they describe last changed. Page views and article counts tell you nothing about either. Both numbers below can be produced by hand in an afternoon with a ticket export and a release log.

The editor role is being staffed elsewhere in the industry. In a Gartner survey of 321 customer service and support leaders conducted in October 2025 and published in February 2026, 58% said they plan to upskill agents into knowledge management specialists. That survey covers customer service and support, not customer success, and the two should not be relabelled as each other, but it is the clearest published signal in 2026 that the editor duty is turning into a role with a title.

The agreement is one page naming the editor, the contributors, the trigger and the review cycle. It exists because the answer to who should own the knowledge base has to survive a reorganisation, a resignation and a quarter where everybody is busy. Write it down, put it where new joiners find it, and review it when the org chart moves.

The last line matters more than it looks. A team that has no trusted internal reference invents one in Slack threads, and Slack threads are unsearchable six months later. Practitioners describe exactly this in the corpus: getting customer feedback to product from CS, sales and support is the sibling problem, and the same fix applies, which is a named owner and a trigger rather than goodwill.

One last sequencing note. Fix the trigger before you commission a rewrite. A team that rebuilds 200 articles without an invalidation list will be back in the same position within three releases, and the second rebuild is harder to get funded than the first. If the help centre is carrying onboarding as well, customer onboarding best practices covers what belongs in a guided flow rather than an article, and the customer success scorecard gives you somewhere to record the two measures each quarter.

GainTrace does not publish your help centre, and a knowledge base is not something it replaces. What GainTrace does is supply the Customer Success half of the evidence an editor needs: which accounts keep raising the same question, which ones stall at the same step, and whether support load on an account is rising before a renewal. Triage groups repeat issues across accounts so the editor writes against a ranked list instead of a hunch, and customer health shows the support and usage trend behind each account. The writing is still somebody's job.