The article-maintenance math nobody budgets for
Every help-center article is accurate the day it ships and decaying by the next release. Teams fund the writing and never the upkeep — and customers pay the difference.

The article said "Settings → Billing." That button had lived under "Account" for three releases. The rep pasted the link anyway, the customer replied "that's not there," and a ticket self-service should have closed came back around — reopened, escalated, now costing several times what it should have.
Nobody wrote that article to be wrong. It was accurate the day it shipped. Then the product moved and the words didn't.
Content doesn't age gracefully; it rots
Every knowledge base is a snapshot of a product that no longer exists. Each release renames a menu, each pricing change dates a screenshot, each policy update quietly contradicts a paragraph three articles deep that nobody remembers writing. The decay is invisible because it's silent — an article doesn't throw an error when it goes stale. It just starts handing wrong answers to people who trusted it.
And the failure doesn't look like failure. It looks like a customer quietly giving up.
In Gartner's data, self-service often fails not because the answer doesn't exist, but because the customer can't find content relevant to their issue. "Can't find it" and "found it, but it's wrong" produce the same shrug. Both end with the person opening a ticket, or worse, not.
That's the ceiling everyone is building against. A knowledge base that's a fifth out of date isn't quietly operating at eighty percent of its value — it's dragging an already-low number lower, one silently rotten article at a time.
The bill arrives as churn, not tickets
The comforting read is that a stale KB just pushes volume back to the queue — annoying, but survivable. The data says the cost runs deeper than a reopened ticket.
When self-service fails a younger customer, more than half say they go on to use the product or service less. That's not a support metric. That's revenue. The maintenance you skipped didn't only create a ticket; it taught a customer that looking things up here is a waste of time — and that lesson sticks long after the article gets fixed.
Why nobody budgets for it
Here's the math that never makes it into the plan: creation is a project, maintenance is a mortgage.
A team will happily fund a "build out the help center" sprint. It's visible, it's finite, it ships. What it won't fund is the part where every one of those articles becomes a standing liability the moment it's published — a promise that has to be re-checked every time the product moves underneath it.
When ServiceNow's support org got serious about knowledge, it produced over ten thousand new articles in a single year. That's a triumph of creation — and a maintenance obligation that compounds forever. Every article you were proud to write is one more thing that can go quietly wrong. Upkeep gets skipped because it has no launch date, no demo, and no KPI. There is a metric for articles published. There is almost never one for articles still true.
A knowledge base is the only asset a support team celebrates building and then refuses to maintain.
The result is a library that looks impressive in the CMS and lies to customers in production. Sheer volume of content becomes a vanity metric of its own — a big number that says nothing about whether any of it is accurate today.
Maintenance as a byproduct, not a cleanup
The teams that get this right stop treating accuracy as a quarterly cleanup and make it a side effect of the daily work. That's the whole premise of Knowledge-Centered Service: the person who just solved the ticket fixes the article while the fix is fresh, so the content evolves at the speed the product does instead of drifting behind it.
The payoff isn't abstract.
KCS adopters report case deflection of up to half through self-service — but only because the content is trustworthy enough that customers keep coming back to it. Deflection like that isn't bought with more articles. It's bought with articles people can rely on, which means it's bought with maintenance.
So budget the upkeep as a line item, give someone the mandate and a metric that counts accuracy rather than output, and treat every published article as a subscription you've committed to, not a purchase you've completed. Because the alternative isn't a smaller knowledge base. It's the same one, quietly going wrong. For why raw content volume flatters a team, read deflection is a vanity metric; to score your self-service honestly rather than by article count, the benchmarks are a better starting point.