---
title: "Who Should Own the Knowledge Base? Support, CS or Product"
description: "Who should own the knowledge base: four ownership models, the release trigger that stops articles going stale, and the two numbers that prove it is working."
topic: "Playbooks & Operations"
author: "Raj Bheda, Co-founder, GainTrace"
audience: "Head of Customer Success, Head of Support"
published: 2026-09-18
modified: 2026-09-18
source: https://gaintrace.com/explore/playbooks/who-should-own-the-knowledge-base
---

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

*The help centre nobody has updated since March*

**Short answer:** Who should own the knowledge base comes down to one named editor, in Support at most B2B SaaS companies between 30 and 200 people, who holds the standard and the publish button while Product and Customer Success write into it. Ownership of the asset is rarely the real problem. Help centres go stale because no release names the articles it breaks, so attach that list to the release ticket.

**Key takeaways**

- Name one editor with a job title and a protected block in the week. Shared ownership of a help centre is the same as no ownership, because nothing shared has a calendar slot or a definition of done.
- Put the list of articles a release breaks into the release ticket, written by the people shipping it. The article is wrong from the moment the code merges, not from the moment a customer complains.
- Support is the right owner between roughly 30 and 200 employees, because Support sees the question in the words the customer used. Customer Success is the model that reads best and works least often.
- Measure two things: the share of escalated tickets whose answer already existed, and the share of articles never reviewed since the feature they describe last changed. Both are countable by hand in an afternoon.
- Schedule the retirement pass. Deleting articles is the only part of knowledge base maintenance nobody ever volunteers for, and a contradictory help centre costs more than a thin one.

Who should own the knowledge base is the question that surfaces the week after somebody notices the help centre still shows a navigation menu that changed in March. Support says Product should write it, because Product built it. Product says Support is the team that hears customers get stuck. Customer Success has been answering the same question by email for months and has the best material of anyone, unpublished, in a folder.
This page is for the Head of Customer Success or Head of Support who has to settle it and make the answer stick. It gives the four ownership models that come up, the one release trigger that stops articles going stale, the two measures that tell you whether the knowledge base is earning its keep, and the one-page agreement that survives the next reorganisation.

## Who should own the knowledge base at a B2B SaaS company?

> **The invalidation list:** The invalidation list is the set of help centre articles a release breaks, written by the people shipping the release and attached to the ticket before it merges. Ownership arguments stall because the cost of a stale article lands on whoever answers the next ticket, weeks later and in a different team. The invalidation list moves that cost back onto the change that caused it, on the day it is cheapest to pay.

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.

> "One responsibility I'm unsure about is ownership of the help center. Historically, I've managed it myself, but since we're hiring for customer success and potentially customer support, I'm not yet sure how to divide this responsibility."
>
> — r/CustomerSuccess, 2026

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.

## Which four knowledge base ownership models are on the table?

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.

| Model | Who writes | Who edits and publishes | Best for | Fails when |
| --- | --- | --- | --- | --- |
| Founder or PM owned | The person who built the feature | The same person | Under 30 employees, before a support team exists | The first support hire arrives and nobody hands the duty over, so it decays quietly for a year |
| Support owned, named editor | Support agents, from resolved tickets; Product for anything new | One named Support editor with a protected weekly block | 30 to 200 employees, which covers most B2B SaaS | The editor carries a ticket queue as well and the queue always wins on a bad week |
| Customer Success owned | CSMs, from the questions their own accounts repeat | A CSM who has been given the extra title | Rare: only where Customer Success also runs tier-one support | Coverage follows the loudest account, because CS work is account-shaped and a help centre is product-shaped |
| Dedicated knowledge manager | Everyone, drafting against a template | A full-time knowledge manager | Above 200 employees, or any multi-product company | Contributors stop contributing because a specialist exists, and the specialist has never used the feature under pressure |

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.

> "Documentation is often too vague or difficult to navigate without having to reach out to the support team or our CSM."
>
> — Mid-Market reviewer, public G2 review

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](https://gaintrace.com/explore/customer-success/when-should-customers-contact-csm-vs-support) covers how to draw that line without sending people in circles.

## Why does the knowledge base go stale after every product release?

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.

> "I've always struggled with keeping product screenshots up to date in the knowledge base as the product evolves... my developer is about to add a new tab to our platform's left-side navigation menu, which will require me to replace at least 100 screenshots."
>
> — r/CustomerSuccess, 2025

> "In our small SaaS team, we ship UI updates pretty frequently. The product evolves fast, but our help center and documentation don't always keep up at the same speed."
>
> — r/CustomerSuccess, 2026

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.

> "On documentation they appear to be up to two major releases behind in some cases, and with one of those being look and feel, the aged documentation is almost useless. Updated documentation should be delivered with the release, not after."
>
> — Mid-Market reviewer, public G2 review

| Product change | What it invalidates | Who writes the update | Due |
| --- | --- | --- | --- |
| Navigation or layout change | Every screenshot on the affected path and the step wording around each one | Product, inside the release ticket | Before the release ships |
| Behaviour change to an existing feature | The article describing the old behaviour, which now reads to a customer as a bug report | Product, inside the release ticket | Before the release ships |
| New feature | The gap where the article should be, plus every article that lists what exists | Product drafts, the editor rewrites | Day of release |
| Pricing or packaging change | Every article naming a plan, a limit or an entitlement | Whoever owns packaging lists them, the editor rewrites | Before the change is announced |
| Deprecation | The article itself, every internal link to it and every support macro that pastes it | Product lists, the editor redirects | At announcement, not at removal |
| Fix for a documented workaround | The workaround article customers have bookmarked and are still following | Support, from the ticket that raised it | Within a week |

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.

> "One issue I keep running into is that support content starts strong, but over time it drifts away from the actual product... The hard part isn't creating docs it's keeping them trustworthy."
>
> — r/CustomerSuccess, 2026

## What does a knowledge base owner do in a normal week?

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. **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. **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. **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. **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. **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. **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.

> **Worked example:** A 60-person B2B SaaS company gave one Support lead a single protected day a week on the knowledge base. In month one she cleared 14 invalidation lists, rewrote 9 articles that the search log showed people were failing to find, and retired 23 that described features removed in 2025. Known-answer escalations, which she had counted by hand at 38% of escalated tickets in the baseline week, were 24% eight weeks later. These figures are illustrative; run the count on one week of your own tickets before you promise anybody a number.

## How do I measure whether the knowledge base is working?

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.

**Known-answer escalation share**

```
Known-answer escalation share = Escalated tickets whose answer already existed ÷ All escalated tickets × 100
```

Where:
- Escalated tickets: tickets that left tier one, counted across one full week so a quiet Monday cannot set the number
- Answer already existed: an article published before the ticket was raised that would have resolved it with no edits
- What good looks like: under 20%. One team that published its own count on r/CustomerSuccess in 2025 found 62% of its escalations were how-to questions its documentation already covered

**Stale rate**

```
Stale rate = Articles not reviewed since their feature last changed ÷ Published articles × 100
```

Where:
- Last changed: the date of the most recent release touching that feature, read from the release log and never from the article's own edit date
- Published articles: everything a customer can reach, including the ones nothing links to any more
- What good looks like: under 10%. Above 30%, the help centre is a liability: a customer who follows a wrong article loses more time than one who finds nothing

| Measure | How to get it | What it tells you | The trap |
| --- | --- | --- | --- |
| Known-answer escalation share | Tag one week of escalated tickets by hand | Whether the knowledge base is failing the people paid to use it | Agents tag generously once the number is used against them, so have the editor tag, not the agent |
| Stale rate | Join the article list to the release log, feature by feature | How much of the help centre is wrong right now | Counting edit dates instead of release dates makes a stale base look fresh |
| Zero-result search share | Export the site search log for 30 days | The articles you have not written yet | Misspellings and internal jargon inflate it, so group terms before counting |
| Deflection | Sessions that end with no ticket in the next 24 hours | Whether customers are getting answers without a human | It cannot see the customer who read the article, stayed confused and quietly left |

> "The bottleneck wasn't Tier 1 competency. It was Tier 0 (self-service) infrastructure."
>
> — r/CustomerSuccess, 2025

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.

## What goes in the agreement once you know who should own the knowledge base?

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 one-page knowledge base ownership agreement**
- [ ] One named editor with a job title, and a named deputy for holidays and notice periods.
- [ ] A protected block in the editor's week that the ticket queue is not allowed to take.
- [ ] Product writes the invalidation list into every release ticket, and the release is not done until that list is empty or waived by name.
- [ ] Customer Success sends the repeat question of the month, in the exact wording customers use, not a tidied-up version.
- [ ] A definition of done for an article: one task, the customer's words in the title, dated screenshots, a visible last-reviewed date.
- [ ] A quarterly retirement pass with a target number, because deleting is the part nobody schedules on their own.
- [ ] The known-answer escalation share and the stale rate published where the whole company can read them.
- [ ] A named owner for internal documentation too, or the internal wiki becomes a shadow help centre that contradicts the real one.

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](https://gaintrace.com/explore/playbooks/customer-feedback-to-product-from-cs-sales-support) is the sibling problem, and the same fix applies, which is a named owner and a trigger rather than goodwill.

> "We have hundreds of articles in our knowledge base. Many are outdated, some are contradictory, and it's hard to find anything. It's a huge problem for our customers and our support team."
>
> — r/CustomerSuccess, 2025

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](https://gaintrace.com/blog/customer-onboarding-best-practices) covers what belongs in a guided flow rather than an article, and the [customer success scorecard](https://gaintrace.com/tools/customer-success-scorecard) gives you somewhere to record the two measures each quarter.

## How does GainTrace help when nobody owns the knowledge base?

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](https://gaintrace.com/platform/triage) groups repeat issues across accounts so the editor writes against a ranked list instead of a hunch, and [customer health](https://gaintrace.com/platform/customer-health) shows the support and usage trend behind each account. The writing is still somebody's job.

## Frequently asked questions

### Who owns the help center in a SaaS company?

In most B2B SaaS companies between 30 and 200 employees, a named Support editor owns the help centre: they hold the standard, the taxonomy and the publish button. Product and Customer Success contribute drafts under that standard. Under 30 employees it is usually a founder or PM, and above 200 it becomes a full-time knowledge manager. What matters more than the team is that one person is named.

### Should customer success or support own the knowledge base?

Support, in almost every case. A CSM writes for the accounts in front of them this quarter, so a CS-owned help centre fills up where the loudest customers are and stays thin everywhere else. Support hears the same question at volume, in the customer's own words, across the entire base. Customer Success owning it makes sense only where CS also runs tier-one support.

### How often should knowledge base articles be reviewed?

Review by trigger, not by calendar. An article is due for review the moment a release touches the feature it describes, which is why the release ticket should carry the list of articles it breaks. On top of that, run a quarterly retirement pass to delete articles for features that no longer exist, and give every article a visible last-reviewed date so readers can judge it themselves.

### Who should write the documentation for a new feature?

The team shipping the feature drafts it, and the knowledge base editor rewrites it before publication. Product knows what the feature does and what it replaces. The editor knows the words customers use, the one-task-per-article standard and which existing articles now contradict the new one. Shipping a feature with no draft attached is how a knowledge base gets a permanent gap.

### How do I stop help center screenshots going out of date?

Treat a navigation or layout change as a release that cannot close until its screenshots are replaced, and keep a list of which articles use which screens so the scope is knowable in minutes. Practitioners in the 2026 corpus describe single UI changes invalidating 100 or more images. Cropping tightly to the control being described, instead of capturing the whole page, cuts how many images any one change breaks.

### Should the internal wiki and the customer help center have the same owner?

They need separate owners but one standard and one publishing calendar. The internal wiki carries process, escalation paths and things you would never say to a customer; the help centre carries tasks a customer performs. When the internal side has no owner, the team invents one in Slack threads, and a Slack thread cannot be found six months later by the person who needs it.

## How this was researched

We read 4,978 public G2 reviews of five customer success platforms (29,027 sentences, with the reviewer's role and company segment where G2 published it) and 33,600 Reddit posts from r/CustomerSuccess, r/SaaS, r/sales and r/startups covering May 2024 to September 2026. We counted reviews mentioning documentation (97, or 1.9%) and Reddit posts in r/CustomerSuccess mentioning documentation (117), a knowledge base (72) and a help center (38), then read every ownership thread in full. The named external figure is Gartner's February 2026 release of an October 2025 survey of 321 customer service and support leaders, which covers service and support rather than customer success. The four-model comparison, the invalidation list, the weekly routine and both formulas are our own analysis; the worked example uses illustrative figures.

## Sources

- [r/CustomerSuccess: In your organization, who is responsible for keeping the help center up to date?](https://reddit.com/r/CustomerSuccess/comments/1r98uql/)
- [r/CustomerSuccess: How do you keep product screenshots in the help center up-to-date with a fast-moving product?](https://reddit.com/r/CustomerSuccess/comments/1regr09/)
- [r/CustomerSuccess: What's your process for keeping support documentation accurate as products change?](https://reddit.com/r/CustomerSuccess/comments/1sufbez/)
- [r/CustomerSuccess: Why Your Tier 1 Is Drowning (first-contact resolution breakdown)](https://reddit.com/r/CustomerSuccess/comments/1q0hwo8/)
- [r/CustomerSuccess: Knowledge Base Managers: how do you keep screenshots and visual assets updated?](https://reddit.com/r/CustomerSuccess/comments/1i6manc/)
- [Gartner survey of 321 customer service and support leaders, October 2025, published February 2026](https://www.ndtahq.com/gartner-survey-finds-91-of-customer-service-leaders-under-pressure-to-implement-ai-in-2026/)

## Next steps

Name the editor this week, then put the invalidation list into your next release ticket and count your known-answer escalations. [Start free](https://app.gaintrace.com/auth/login) or [book a demo](https://gaintrace.com/booking).