Knowledge base for SaaS: what your product docs actually need

Why SaaS documentation is a different problem

A static company FAQ can be written once and left alone. SaaS docs cannot. Every release changes a screen, renames a setting or adds a feature, and an article that was correct last month now generates tickets. Most SaaS companies also run more than one product, edition or white-labeled brand, serve customers in several languages, and increasingly have their documentation read by AI assistants rather than by people browsing a sidebar.

That combination — high change rate, multiple audiences, multiple languages and machine readers — is what separates a knowledge base for SaaS from a generic wiki or a help desk's bundled FAQ module. Use this checklist when you evaluate any vendor, not only Multibase:

• Release workflow: article version history, review and approval before publishing, scheduled publishing for launch day, and automatic redirects when a slug changes.
• Self-service deflection: AI answers synthesized from your articles with source citations, plus search analytics that show what users failed to find.
• Localization: per-language drafts that are published independently, so one slow translation does not block a release.
• Multiple products: a separately branded portal, domain and navigation per product or edition, managed from one account.
• Gated content: articles visible only to logged-in customers or specific customer groups.
• AI and agent access: a machine-readable way for assistants such as Claude or Cursor to search and read your docs.
• Predictable pricing: a bill that does not climb every time you hire a support agent or add a brand.

Keeping docs in step with every release

The cheapest support ticket is the one prevented by an article that was updated before the release went out. In Multibase, a release-day workflow looks like this:

1. Draft the updated articles in the block editor while the feature is still in development. Version history keeps the current live text intact until you publish.
2. Send the drafts through the review workflow — reviewers comment and approve before anything goes live.
3. Schedule publishing for the release date and time, so the docs and the product ship together.
4. If a feature was renamed, change the article slug. Multibase creates a redirect from the old URL, so links from emails, the app and search engines keep working.
5. Add a changelog entry and mark the key articles as featured, so returning users find what changed.

Deflecting tickets with AI answers and Gap Finder

SaaS users want an answer, not a list of ten links. The reader-facing AI chat in Multibase synthesizes an answer from your published articles, streams it, and cites the source articles so users can verify it. When confidence is low, it falls back to regular search instead of guessing.

Point your app's Help link at the portal and AI answers become the first line of support. On paid plans, Gap Finder closes the loop: failed and weak searches, ranked by frequency, become one-click article drafts, and analytics show article views, searches, AI usage and article ratings — so the docs team works on what is actually generating tickets.

AI queries are included in every plan — 100/mo on Starter, 1,000 on Growth, 5,000 on Scale and unlimited on Enterprise. Extra queries cost $20 per 1,000, and from Growth upward you can bring your own OpenAI or Anthropic key instead.

Localizing for global users

Each portal can publish content in 9 languages: English, Russian, Ukrainian, French, Serbian, Italian, Hungarian, Polish and Turkish. AI translation creates a draft per locale, which a reviewer checks and publishes on its own schedule.

That independence matters for SaaS. The English article ships on release day; the French and Italian versions follow as soon as they are reviewed, and nothing waits for the slowest language.

One portal per product, edition or brand

If you sell several products, or a white-labeled edition to partners, each one gets its own portal with its own custom domain (TLS is handled for you), logo, colors, fonts and custom CSS, with no "Powered by Multibase" footer on paid plans. All portals are managed from one account by the same team.

For customer-only documentation — enterprise setup guides, beta features, partner runbooks — reader groups restrict articles to logged-in readers. Authenticated readers are unlimited on every plan.

Running several brands of your own is covered in depth in the multi-brand documentation guide. If you host documentation for your customers' own end users, the multi-tenant knowledge base page covers that model.

Making your docs readable by AI assistants

Users increasingly ask Claude or an IDE assistant instead of opening your help center. Every Multibase portal is exposed as a public, read-only MCP (Model Context Protocol) endpoint with search_kb, get_article, list_categories and list_articles tools. Any MCP client that supports remote Streamable HTTP servers can then answer from your current docs instead of stale training data.

Only published, public articles are exposed, the endpoint is rate-limited, and MCP searches and reads appear in analytics with the source "MCP", so you can see how much of your audience now arrives through AI tools.

What it costs at each SaaS stage

Prices below assume annual billing; monthly billing is 20% more, and prices exclude VAT. Because pricing is flat, hiring support agents or adding writers within your plan's admin count does not change the bill.

Where Multibase is not the right fit

Multibase is a knowledge base, not a help desk: it has no ticketing and no live chat. If you want one vendor for tickets, chat and docs, a suite such as Zendesk or Intercom bundles them — at per-agent pricing. If your documentation is mainly developer API reference maintained in Git, a docs-as-code tool such as GitBook fits that workflow better.

Multibase is strongest for customer-facing product help across several products, brands or languages, where flat pricing and per-portal branding matter more than a bundled support suite.