A knowledge base only works if people can find answers without asking anyone. Many first attempts stall: too many categories, articles that try to cover everything, or a tool that is hard to maintain once the launch excitement is gone.
We at eniston have seen teams ship useful help centers, internal wikis and client portals in days rather than months. The difference is rarely fancy features. It is a clear purpose, a small structure, and a habit of keeping articles short. This guide walks through seven steps, with concrete category trees you can copy, and a launch checklist at the end.
For a broader overview, see our earlier post on what knowledge base software is and how it can help your company. This article is the practical follow-up: how to create a knowledge base from scratch.
Before you open an editor, write down three answers in one sentence each:
Who is this for? Customers, your own team, or a specific client?
What should they achieve without contacting you? Reset a password, finish onboarding, find a process, or hand a project over.
Where will they open it? A public help subdomain, a password-protected client portal, or an internal wiki behind login or IP restriction.
Those three answers decide the category tree, whether search engines should index it, who gets edit rights, and which access rules you need. Mixing audiences in one knowledge base usually creates confusion. If you need both a public help center and an internal wiki, plan two separate workspaces rather than one crowded tree.
You do not need a blank page. Pull the last few weeks of support tickets, chat transcripts, onboarding questions and Slack threads. Group them into themes such as "account", "billing", "how do I…", "error messages" and "process".
Aim for a short first catalog, not a complete encyclopedia:
list the 10–20 questions that come up most often,
mark which ones already have a good answer somewhere (email templates, Notion pages, PDFs),
and note which ones need a screenshot or a short video.
This audit becomes your first article backlog and stops you inventing categories before you know what people ask.
Most knowledge bases work best with five to eight top-level categories and a few subcategories where needed. More than that, and readers stop browsing. Use categories and subcategories as the main navigation, not a deep folder maze. The three structures below are starting points you can adapt.
Getting started
Account and billing
How-to guides
Integrations
Troubleshooting
FAQ
What's new / release notes (optional)
Under Troubleshooting, keep one article per symptom when you can. Our post on why you need a troubleshooting guide and how to create one covers the article pattern in more detail.
Start here (Day 1)
Company and policies
Tools and access
Team processes
How we work (meetings, communication)
HR and people
Engineering / product / marketing (role-based sections as needed)
Put a single "Start here" article at the top with links to the first-week essentials. That pattern pairs well with onboarding; we wrote more about that use case in our earlier piece on successful employee onboarding with a knowledge database.
Welcome and how to use this portal
Project overview
How to update content / use the CMS
Brand assets and guidelines
Troubleshooting
Contacts and escalation
Handover / go-live checklist
Agencies often need one portal per client. In that case, use a separate workspace for each client rather than one shared tree. We describe that model in how agencies can run a separate help center for every client.
Do not wait for the perfect structure to finish writing. Ship a small set of high-traffic articles first. A useful default for each article is:
Title as a question or task ("How do I reset my password?", not "Passwords")
One-sentence answer at the top for scanners
Steps in order, with screenshots where a UI click is easy to miss
Related articles at the bottom
When to contact support so readers know the limit of self-service
Keep each article focused on one job. If you catch yourself writing "and also…", split it. A rich text editor is enough for headlines, lists, images, video embeds and code; see creating and editing articles.
Optional AI drafting (the Enhanced add-on in eniston) can speed first drafts. Treat it as a helper, then have someone who knows the product review every article. Our post on crafting a knowledge base with AI assistance covers that workflow.
Once the first articles exist as drafts, configure the knowledge base so it feels like part of your product or company:
Workspace. In eniston, a workspace holds documentation for one product, website or app. Create one per audience when content or access rules differ. See create and manage workspaces.
Appearance. Upload your logo and favicon, set brand colors, and choose a theme. Custom CSS is available if you need a closer match (appearance settings).
Custom domain. Point something like help.yourcompany.com at the workspace with a CNAME; SSL is handled for you (custom domain).
Access rules. Public help centers stay open. Internal wikis and client portals usually need restricted access: frontend authentication, an IP allowlist, or a workspace / category password.
SEO. For customer-facing docs, fill in titles and descriptions and allow indexing. For private documentation, use the SEO settings to keep search engines out.
Setup itself should not take long. We designed eniston so you can sign up and get started within a minute; the time usually goes into writing, not into configuration.
A knowledge base dies when only one person can edit it. Invite subject-matter owners early: support for troubleshooting, product for feature how-tos, HR for policies, the client contact for a portal.
On our Business plan, team collaboration is included without per-user pricing, so you can invite editors without watching the seat count. Roles such as Read-only, Editor, Extended Editor and Admin let you give write access where it belongs. For why that model matters as teams grow, see knowledge base software without per-user pricing.
Agree on two ownership rules: every category has a named owner, and every published article has a review date (for example every 90 days, or after each major release). Version history helps when several people edit the same piece: published articles keep recent versions, so a bad change is recoverable.
Launch is not "publish everything". Launch is "make the first useful set findable, then improve from real usage".
Before you announce the knowledge base:
the top 10–20 articles from your audit are published and linked from a clear homepage,
search returns those articles for the phrases people already use,
related-article links connect the main journeys (sign-up → first action → common error),
feedback or ratings are enabled,
the custom domain and SSL look correct on mobile and desktop,
access rules match the audience (public, password, login or IP),
for EU-facing products, hosting, DPA and cookie questions are checked against a GDPR-compliant knowledge base checklist.
After launch, review article statistics monthly: views, poor feedback, and searches with no results. Those signals tell you what to write next. Ticket deflection usually follows once the empty-search list shrinks.
Use this as a one-page go-live list:
Purpose and audience written down
Ticket / chat audit done (top questions listed)
Category tree limited to 5–8 top levels
First 10–20 articles published with one job each
Homepage or "Start here" article points to the essentials
Branding, logo and theme applied
Custom domain connected (if customer-facing)
Access rules set and tested with a non-admin account
SEO indexing on or off on purpose
Owners and review dates assigned
Feedback / ratings enabled
Soft launch to a small group, then announce
You do not need an enterprise project to create a knowledge base. With eniston you can start a 30-day trial with no payment information required, set up a workspace, and publish your first articles the same day. Plans are flat (no per-user fees): Plus at €8 per month with 2 workspaces, Business at €28 per month with 10 workspaces and team collaboration, plus optional add-ons such as extra workspaces (€9 one-time) or the Enhanced AI editor (€6 per month). See pricing. Made and hosted in Germany / the EU.
Creating a knowledge base is less about the perfect tool and more about a repeatable process: define the audience, mine real questions, keep the structure small, write short articles, invite owners, and launch with a checklist. The three category trees above cover the common cases (SaaS help center, internal wiki, client portal). Adapt them, ship a useful first version, and improve from search and feedback.
If you want to try this flow in a live workspace, start your free 30-day trial. No payment details are required, and you can have a branded help center or internal wiki ready to share within a minute of signing up.
Our knowledge base software offers a great variety of features to manage your knowledge articles. Try eniston for free for 30 days. No credit card required.
