Knowledge base software: what it costs

Knowledge base software is sold as one category and behaves like three different products. A public help center, an internal wiki and a product documentation site sit under the same heading in every catalogue, and once you look at the permissions, the search and the invoice, they have almost nothing in common.

Picking the wrong shape is the expensive mistake, and it is rarely obvious during the trial. The bill for the second year is what tells you, by which point the content has been written and moving it is a project.

Every price below was read on the vendor’s own pricing page on 5 September 2026, and every one of them will drift. Read the model, not the number.

Knowledge base software in numbers

Six figures worth carrying into a vendor conversation, all read on 5 September 2026.

$0 to $799 a month covers the entire realistic range for a team of ten, depending only on which unit the vendor charges for
$0.75 to $0.99 is what an AI resolution costs at the two vendors that publish the rate: Help Scout charges $0.75, Intercom charges $0.99
$55 per agent per month is the entry price of a knowledge base bundled into a full support suite, on Zendesk Suite Team billed annually
$65 per site per month plus $12 per editor is what a documentation product costs when readers are free, on GitBook Premium billed annually
$249 a month flat is where dedicated knowledge base tooling starts when it charges by user tier rather than by seat, on Helpjuice for up to 30 users
One vendor in five publishes no price at all. Document360 replaced its pricing table with a configuration questionnaire

That spread is not about features. It is about who the vendor decided to count.

The three products behind one category name

What separates them is not the feature list. It is who reads the content, because that decides who the vendor charges you for.

A public help center is attached to a support tool. Customers read it, support agents write it, and the whole thing exists to stop a question from becoming a ticket. Its search is tuned for people who do not know your vocabulary, and its analytics answer one question: which articles kept a ticket from being opened.

An internal wiki, the shape most notes and wiki tools take, is read by employees and written by everyone. Permissions are the hard part, not publishing. The content is messier by nature, half of it is out of date within a year, and the tool’s real job is making the current version findable next to the stale one.

A product documentation site is read by people integrating with you. It lives next to a repository, it versions with releases, and it is usually written in Markdown by people who will not accept a rich text editor.

	Public help center	Internal wiki	Documentation site
Who reads it	Customers, unauthenticated	Employees	Developers and integrators
Who writes it	Support team	Everyone, unevenly	Engineering and technical writers
What the bill counts	Support agents	Every employee	Sites plus editors
Search has to handle	Words customers use, not yours	Stale versus current	Exact API names and code
Editor people expect	Rich text	Rich text	Markdown, in a repository
Versioning	Rarely needed	Rarely needed	Per release, non-negotiable
Common failure	Nobody updates it after launch	Permissions sprawl	Docs drift behind the release

A tool built for one of these does the other two badly, and the demo will not show you that. An internal wiki asked to serve customers gives you an authentication wall you did not want. A help center asked to hold engineering documentation gives you an editor that mangles code blocks.

Most companies past thirty people end up owning two of the three. That is not a procurement failure. The audiences want different things, and one tool serving both usually means the internal content is too polished to stay current or the public content is too raw to publish.

What the bill is actually counting

Knowledge base software charges in six different ways, and the gap between those models is far larger than the gap between feature lists.

Tool	What it charges for	Price on 5 September 2026
Zendesk	Per support agent	Suite Team $55/agent/month, Suite Professional $115/agent/month, billed annually
Help Scout	Per user, with a free tier	Free for 5 users and 1 Docs site; Standard $25, Plus $45, Pro $75 per user/month; extra Docs sites $20/month each
Intercom	Per seat, plus each AI resolution	Essential $29, Advanced $85, Expert $132 per seat/month; Fin at $0.99 per resolution
Helpjuice	Flat tier by user count	$249/month up to 30 users, $449 up to 100, $799 unlimited
GitBook	Per site, plus editors	Premium $65/site/month annually plus $12 per user; Ultimate $249/site/month
Notion	Per member, wiki-first	Free for individuals; Plus $10, Business $20 per member/month; AI agents at $10 per 1,000 credits
Document360	Quote only	No public prices, priced per configuration after a sales conversation

Per agent is the model that hides the least. You are already paying for those people, the knowledge base rides along, and the cost of adding an article is zero. The catch is that everyone who writes has to be a support seat, so the product manager who wants to fix one paragraph either gets a $55 seat or sends it to someone who has one.

Per user with a free floor is what most small teams should start on. Help Scout’s free tier carries five users and one Docs site, which is a complete public help center at no cost, and the jump to $25 a user only arrives when the support team grows.

Per resolution is the only model where the vendor is paid when the software works. Intercom charges $0.99 each time its AI agent closes a conversation without a human, Help Scout charges $0.75. That is honest and it is also unbudgetable: a good month of self-service produces a bigger invoice than a bad one, and the number moves with your traffic rather than your headcount.

Flat tiers by user count are cheap in the middle and cliff-shaped at the edges. Helpjuice at $249 a month for 30 users is expensive for a team of four and cheap for a team of twenty-eight. The number to check is not today’s headcount, it is the one that crosses the next tier.

Per site separates readers from writers, and for anything public that is the model that scales. GitBook’s published pages carry unlimited page views, so growth in traffic costs nothing and growth in the writing team costs $12 a head.

Per member, wiki-first is what you get when the knowledge base is a feature of a workspace rather than a product. Notion at $10 a member is cheap for internal documentation and awkward for a customer-facing help center, because the whole company is on the invoice whether they write anything or not.

Quote only tells you something before you get the number. Document360 removed public prices in favour of a configuration questionnaire, which means the price is set by what the seller learns about you. That is not automatically bad, but the first number you hear is an opening position, and budgeting before a sales call becomes impossible.

Zoho Desk sits slightly outside this table because it prices by region: the free tier carries three agents, and the knowledge base appears from the Standard plan upwards, but the figure shown depends on where you open the page from. Any vendor whose price changes with your IP address needs a written quote before comparison.

What it costs at three sizes

Four products, priced for three shapes of team. Annual billing where the vendor offers it.

	3 people, public help center	12 people, help center plus internal wiki	40 people, documentation and support
Help Scout	Free tier, $0	Standard, $300/month	Pro, $3,000/month
Zendesk Suite Team	$165/month	$660/month	$2,200/month
GitBook Premium	$65/month plus 2 editors, $89	$65 plus 11 editors, $197	$65 plus 39 editors, $533
Notion Business	$60/month	$240/month	$800/month

Two things this table shows that a feature comparison never will. Products priced per reader-facing seat get expensive at a speed that has nothing to do with how much documentation you have, and products priced per site stay nearly flat while the company triples.

What matters is where your writers and your readers sit. If ten people read and two people write, buy a model that charges for the two.

The feature list that actually differs

Almost everything advertised in this category is present everywhere. The list below is the short one: features that genuinely separate products, and the tier they usually sit behind.

Feature	Present in	Usually gated behind
Public help center	Every tool	Nothing
Rich text editor	Every tool	Nothing
Article analytics	Every tool	Nothing
Custom domain	Most tools	The first paid tier
Search analytics with zero-result reporting	Some tools	Mid tier
Multiple sites or brands	Some tools	Mid tier, or priced per site
Multilingual with per-language workflow	Fewer tools	Top tier or a per-language fee
Article versioning and scheduled review	Fewer tools	Top tier
Granular permissions beyond admin and editor	Fewer tools	Top tier
SSO and audit log	Most tools	Top tier or enterprise
Redirects you control	Fewer tools	Varies, often missing
Self-service export in an open format	Fewer tools	Varies, often missing

Real differences live in the bottom three rows, and they are the ones no demo covers. Redirects and export decide what leaving costs. Permissions decide whether the tool survives contact with a company of forty.

Multilingual, and what it costs

Translation is the single most reliable way to double the price of a knowledge base, and the pricing model rarely says so on the front page. Where the tool has no workflow of its own, a dedicated translation tool ends up carrying it.

Three patterns show up. Some vendors treat each language as a separate site or workspace, which multiplies whatever the per-site price is. Some include languages but bill translation as an AI feature by the word or by the credit. Some support languages only from the top tier, which is a tier jump rather than a line item.

Establish these before committing, if more than one language is even possible later:

Is a language a new site on the invoice, or a variant of one article?
Does search work inside one language, or does a German query return English articles?
Can a translated article be marked stale when the source article changes?
Does the URL structure carry the language, and is it the structure you want indexed?

Fixing the last one later is expensive. A help center that puts languages on query strings rather than paths starts every language from zero in search, and changing it means redirecting every article you have.

Permissions, and where private knowledge bases break

Public help centers have one permission: published or not. Internal knowledge bases have a permission model, and that is where wiki tools quietly become unusable at forty or fifty people.

Access control here does not fail by being too weak. It fails by being too manual. Every new page inherits from somewhere, somebody overrides it once for a good reason, and eighteen months later nobody can say who can read the salary bands.

Three questions separate a tool that survives that from one that does not:

Do permissions inherit from a structure, or are they set per page? Inheritance from a space or a section is maintainable. Per-page permissions are a spreadsheet nobody keeps.

Is there a report of who can see what? Without one, an access review is a person clicking through pages, which means it does not happen.

What happens when somebody leaves? Pages owned by a deactivated account should not become orphaned or, worse, become invisible.

Companies with a compliance obligation have a fourth: an audit log showing who read what and when. That feature sits at the top tier almost everywhere, so check the price of that tier before choosing the product rather than after the auditor asks. The security and compliance shelf is where tools that treat this as a first-class feature live.

Search is the whole product, and it is the part nobody demos

Vendor demos show the editor. That is the part you use for two weeks. Search is the part that decides whether anyone reads what you wrote.

Three things separate search that works from search that returns nothing.

It has to handle the customer’s vocabulary, not yours. The article is called “Configuring outbound SMTP relays” and the person types “emails not sending”. If the tool only matches on words present in the text, that search fails and the ticket gets opened. Synonym lists, and increasingly semantic matching, are what close that gap.

It has to survive typos and partial words. Most site search returns zero results for a single transposed letter, which reads to the visitor as “this help center has nothing”.

It has to report what failed. The report worth having is not the list of popular articles, it is the list of searches that returned nothing or where nobody clicked a result. That list is your content backlog, written by the people who needed the answer.

Test all three in the trial with your own words, not the vendor’s sample content. Import twenty real articles and have somebody who does not work on the product try to find five answers.

The four numbers worth reporting

Most knowledge base analytics screens are page-view counters with a chart on top. Four numbers actually tell you something, and three of them need to be assembled rather than read off a dashboard.

Deflection rate. Sessions that read an article and did not open a ticket, divided by sessions that read an article. Some tools calculate it, most do not. Where it is missing, the workable proxy is ticket volume for a topic before and after the article that covers it went live.

Zero-result search rate. Searches returning nothing, divided by all searches. Anything above a few percent is a content gap or a vocabulary gap, and the search log tells you which.

Article-to-ticket ratio. Tickets on a topic divided by article views on the same topic. A high ratio on a topic you have documented means the article exists and is not answering the question.

Staleness. Share of published articles not edited or reviewed in twelve months. This is the number that predicts whether the whole investment decays, and almost no tool shows it by default.

Set those four up in the first month. A knowledge base without them is a folder of documents that nobody can defend at budget time, and an analytics tool will not supply them either: these numbers come from the help center’s own search and ticket logs.

What AI answers changed, and what they did not

Almost every tool in this category now advertises an AI layer. Described accurately, it is a retrieval system that reads your articles and writes a sentence back, and it knows nothing you have not published.

That has one consequence that gets skipped in every pitch. AI knowledge base tools amplify whatever your content already is. Thin articles produce confident thin answers, and a contradiction between two pages produces an answer that picks one at random. Teams that expected the AI layer to compensate for neglected documentation get the opposite: the neglect becomes quotable.

Billing is the second consequence. AI tools for self-service automation are almost never included in the base price. They arrive as a per-resolution charge, a credit pack or a higher tier, and the usage is driven by your customers rather than by you.

Before turning on help center automation, find the answer to four questions in writing:

What counts as a billable event: a question asked, an answer given, or a conversation the customer confirmed as resolved?
What happens when the credits run out, a hard stop or an overage rate?
Can you cap monthly spend, and does the cap degrade to human support or to nothing?
Does the answer cite the article it came from, so a wrong answer can be traced to a fixable page?

Run the arithmetic before switching it on. At $0.99 a resolution, two thousand deflected conversations a month is $1,980, which is more than most of the subscriptions in the table above. That can still be the cheapest option, because the same two thousand conversations handled by people cost far more. It just needs to be a decision rather than a surprise.

Self-service AI tools are worth having. They are worth having second, after the twenty articles that cover your twenty most common tickets exist and are correct.

Writing articles that both people and AI answers can use

Structure that makes an article easy to skim also makes it easy for a retrieval system to quote correctly. Costs nothing, changes a lot.

Answer in the first two sentences. Put the resolution at the top and the background underneath. Retrieval systems take the passage nearest the question, and readers who arrived from search are not reading an introduction.

One question per article. An article covering four loosely related things gets retrieved for all four and answers none of them well.

Say the version and the date. “As of March 2026, on plan X” lets both a reader and a model know whether the answer still applies. Undated instructions are the main source of confidently wrong AI answers about products.

Use tables for anything with limits. Numbers in a table survive extraction. The same numbers in a paragraph come out mangled.

Name the thing the way customers name it. If customers say “invoice” and the interface says “billing document”, the article needs both words in it, once each, without contorting the sentence.

Keep one canonical page per fact. Two pages with different figures for the same limit produce a coin flip, in search and in an AI answer alike.

Self-hosted and open source, honestly

Free-to-licence knowledge base software exists, it is real software, and the cost moves rather than disappearing.

You save the subscription. You pay instead for hosting, upgrades, backups, TLS certificates, the search index and the person who owns all of it. At small scale that person is a founder doing it at night, which is the most expensive engineering time in the company.

Products in the developer tools shelf make this easy to underestimate. Self-hosting is a reasonable choice under two conditions: there is already a platform team running other services, or a data residency rule makes hosted products genuinely unavailable.

Outside those two the arithmetic rarely favours it, and the failure mode is specific and common. The knowledge base runs on an unpatched version for two years because upgrading it is nobody’s job.

Migration, step by step

Documentation software collects switching costs quietly, more so than most categories in the catalogue. A year of articles, images, redirects and internal links is a genuinely difficult thing to move, and vendors know it.

Four questions, answered before the contract rather than during the migration:

What format comes out? Markdown or HTML files you can read without their software is the answer you want. A JSON blob keyed to internal identifiers is technically an export and practically a hostage situation.

Do images come with it? Attachments are frequently excluded from exports and hosted on the vendor’s domain. When you leave, every image in every article breaks.

Do the URLs survive? If your help center sits on your own subdomain, you control the redirects. If it sits on theirs, every link anyone ever shared dies on the day you cancel.

Is the export self-service? An export that requires a support ticket is an export the vendor can slow down at exactly the moment you want it fast.

When the move actually happens, the order that avoids a dead month:

Export everything and put it in version control before touching the new tool, so there is a copy that belongs to you
Import into the new tool with the old one still live and public
Rebuild the URL map article by article, including the ones nobody links to
Put the redirects in place and test twenty of them by hand
Switch the domain, and keep the old subscription for one billing cycle
Watch the zero-result search rate for two weeks, because a broken import shows up there first

Skipping step one is the mistake that turns a migration into a rewrite. Google’s guidance on site moves with URL changes applies to a help center exactly as it does to a website, and the redirect map is the part that decides whether the search traffic survives.

Seven mistakes that cost the most

Buying the shape rather than the audience. A wiki bought for customers, or a help center bought for engineering documentation
Counting seats today. Every model in the table above has a boundary; the question is where you will be in eighteen months
Turning on AI before the content exists. It makes the gaps quotable rather than filling them
Publishing on the vendor’s domain. Cheap at signup, expensive at every point afterwards
No named editor. Knowledge bases decay through nobody’s decision, not through a bad one
Writing forty articles nobody asked for. The support log is the backlog; anything else is guessing
Never running the export. The first time you try it should not be the week you are leaving

A trial that tells you something

Two weeks is enough to judge knowledge base software if you spend it on the right things. Most trials are spent admiring the editor.

Import twenty real articles, including the two longest and the one with the most screenshots
Have someone outside the team search for five answers using their own words, and record what they typed
Break the search deliberately: typos, plural forms, the competitor’s word for your feature
Publish one article, then edit it and confirm how long the public version takes to update
Run the export on day two, not day thirteen, and open what comes out
Add a second writer and check what that did to the invoice
Turn on the AI layer, ask it three questions your documentation does not answer, and read what it says
Set a permission on one page and try to read it from an account that should not see it
Check what the help center looks like on a phone, since most people reading it are holding one
Measure the page weight of a published article, because a help center that loads slowly on mobile data gets abandoned mid-search

The pass mark is not “we liked it”. It is that nothing on this list produced a surprise you would have discovered in month four.

Where knowledge base software sits next to everything else

A knowledge base is not a support channel, it is the thing that keeps a channel from filling up. It works when it is fed by the tickets you already answer and read by people who arrived through search.

That makes the ordering fairly clear. Get the twenty highest-volume answers written before choosing a platform, because the content decides which shape you need.

Connect it to whatever handles conversations, since live chat tools that cannot surface an article will send the same question to a person every time.

Suite-shaped options sit on the customer support shelf and site-priced ones on documentation tools. Add the AI layer once the source material is worth quoting.

And read the pricing page the way you would read a contract, because it is one. The same five things a SaaS pricing page hides apply here in full, and the seat minimum in particular catches teams who thought they were buying a website.

Every knowledge base tool in our catalogue is listed on the same terms, with a nofollow link and no paid placement, which is the only claim we make about the ordering. Browse the catalogue and check the vendor’s own pricing page before you believe any number, including ours.

Questions people actually ask

How much should a knowledge base cost for a team of ten?

Anywhere from nothing to about $800 a month on 5 September 2026, for the same job, depending entirely on the model. Ten support agents on Zendesk Suite Team is $550 a month, and most of that is the help desk rather than the knowledge base.

Ten editors on GitBook Premium is $65 for the site plus $108 for the extra seats. Help Scout is free at five users and $250 a month at ten. Work out which unit you are buying before comparing any two numbers.

Is a wiki tool good enough for a customer-facing help center?

Usually not, for two reasons that have nothing to do with features. Wiki tools authenticate by default and their search is built for people who already know the internal vocabulary. Both are correct for employees and wrong for customers. If budget forces it, at minimum check that pages can be published publicly without a login and that they can be indexed by search engines.

Do I need separate tools for internal and external documentation?

Most teams past twenty people end up with two, and it is not a failure. The audiences need different permissions, different search behaviour and different editorial standards. One tool serving both usually means the internal content is too polished to stay current or the external content is too raw to publish.

What does an AI knowledge base tool actually add?

It reads your published articles and answers in a sentence instead of returning a list of links. Genuinely useful for questions your documentation already answers, useless for the ones it does not.

Treat it as a presentation layer over your content rather than a substitute for writing it. Billing is almost always separate from the base plan, at $0.75 to $0.99 per resolution.

How many articles does a help center need before launch?

Enough to cover the questions you actually receive, which is usually between fifteen and thirty for a young product. The number matters less than the coverage: pull the last two hundred support conversations, group them, and write the top twenty. Publishing forty articles that answer questions nobody asked is a common way to spend a quarter for nothing.

Should the help center live on my own domain?

Yes, on a subdomain you control, if the tool allows it. It keeps the search value on your side, it keeps shared links alive if you switch vendors, and it means the redirects are yours to write. Tools that only publish on their own domain are cheaper for a reason.

Who should own the knowledge base inside a company?

Whoever answers the tickets, with a named editor rather than a shared responsibility. Knowledge bases decay through nobody’s decision. The maintenance model that survives is small and dull: an article gets reviewed the next time somebody links to it in a ticket, and the person who linked to it is the one who fixes it.

Can I start with free tools and move later?

Yes, and the free tier of a documentation tool is a reasonable place to write the first twenty articles. Help Scout carries five users and a full Docs site at no cost. Just run the export before you have a hundred articles, so you find out what moving involves while it is still cheap to find out.

How do I stop the knowledge base going stale?

Attach review to a trigger rather than a calendar. The workable rule is that any article linked in a support reply gets read by the person who linked it, and fixed on the spot if it is wrong. Quarterly review sweeps get scheduled, moved and then cancelled; a rule attached to work that is already happening survives.

Does a public help center help search rankings?

It can, and for a narrow set of queries it is the only thing that will. Help center articles rank for problem-shaped searches that a marketing site cannot address without sounding odd, and those searches come from people who already own the product. Put it on a subdomain, let it be crawled, and give each article one question to answer.

How do I measure whether it paid for itself?

Compare ticket volume per customer, not ticket volume. A growing company with flat ticket numbers is deflecting successfully even when the raw count is unchanged. Then price the difference at what an hour of support costs you, and put that number next to the subscription.

What about multilingual support, when is it worth it?

When a language accounts for enough support volume to justify translating and then maintaining the translation, which is the part people forget. A translated article that stops tracking the original is worse than none, because it answers confidently and wrongly.

Start with the twenty highest-traffic articles in one additional language, and add a second only once the first stays current.

Can I use one knowledge base for both the AI agent and the help center?

Yes, and you should. Both read the same articles, and maintaining two sources is how the two start disagreeing. What differs is the writing: an article that answers in its first two sentences serves the retrieval system well and reads better for people too.

Knowledge base software: how to choose one