Knowledge Base / Help Center

Category Description

Knowledge base and help center software enables organizations to publish structured, searchable collections of articles, guides, and FAQs for self-service use by customers or internal team members. The core value proposition is deflecting repetitive support inquiries by giving end-users a place to find answers without contacting a human agent. Content is organized hierarchically into categories and collections, surfaced through full-text search, and maintained by a team of editors with varying permission levels. These tools differ from general-purpose wikis and document editors in that they are explicitly designed around the reader experience: discoverability, navigation, and content feedback are first-class concerns, not afterthoughts.

Example Implementations

Help Scout Docs
GitBook
Notion (help center use case)

Target Audience

The primary buyers are small-to-midsize software companies, SaaS products, and digital service businesses that receive recurring customer support inquiries and want to reduce ticket volume. The typical user breakdown involves a small team of content editors (product managers, support leads, or technical writers) who create and maintain articles, administrators who configure branding and access settings, and a much larger audience of read-only end-users — customers, prospects, or internal employees — who consume the content via a publicly accessible or authenticated web portal.

Core Requirements

Article creation and editing: Editors must be able to create, edit, and delete articles using a rich-text editor that supports at minimum: headings, bold/italic/underline, ordered and unordered lists, inline code and code blocks, hyperlinks, and inline image embedding. Editors must be able to save drafts without publishing them.
Article publishing and unpublishing: Editors must be able to explicitly publish an article to make it visible to readers, and unpublish it to hide it without deleting it. Unpublished articles must not be accessible to end-users.
Hierarchical content organization: Articles must be organized into at minimum two levels of hierarchy: collections (top-level groupings) and articles within those collections. The system must allow editors to create, rename, reorder, and delete collections. Articles must be reorderable within a collection, and collections must be reorderable relative to each other.
Full-text search: End-users must be able to search across all published article content from a search bar prominently displayed on the help center. Search results must display the article title and a snippet of matching content. Search must return results in real time or near-real time (results visible without a manual form submission).
Public help center site: The help center must be accessible as a standalone, browsable web site — not merely a list of links. The site must display collections, articles within collections, and the search bar without requiring end-users to create an account or log in (for public-mode help centers; see also requirement 7).
Custom domain support: Administrators must be able to configure a custom domain (e.g., help.yourcompany.com) for the public-facing help center. The system must serve the help center at that domain. A default subdomain on the platform's own domain must also be available as a fallback.
Access control for the help center: Administrators must be able to configure the help center in at least two modes: fully public (accessible to anyone without authentication) and restricted (requiring end-users to authenticate before viewing content). Both modes must be supported; the distinction between modes must be configurable per help center site.
Article satisfaction ratings: End-users must be able to indicate whether a given article was helpful (at minimum a binary yes/no or thumbs up/down). This feedback must be recorded and visible to editors or administrators in some form.
Article-level analytics: Editors or administrators must be able to view, for each article: total views over a selected time range. The system must also surface failed searches (search queries that returned no results) in aggregate so editors can identify content gaps.
Branding and visual customization: Administrators must be able to configure the help center's visual identity including: uploading a logo, setting a primary brand color, and setting the site title. These changes must be reflected on the public-facing help center without requiring a code deployment.
Custom CSS support: Administrators must be able to inject custom CSS that applies to the public-facing help center, enabling visual customization beyond the built-in theming options.
Multiple collections per article: An article must be associatable with more than one collection, so that the same article can appear in multiple contextually relevant locations without duplicating content.
Content versioning / edit history: The system must retain a history of edits to each article, showing at minimum: who made the change and when. Editors must be able to view prior versions of an article.
Embeddable search widget: The system must provide a mechanism to embed the help center's search or article access into an external web page or application (e.g., a JavaScript snippet or iframe). Embedded access must surface article content inline without redirecting the user to the standalone help center site.
Image and file attachment uploads: Editors must be able to upload images directly into articles. Uploaded images must be hosted and served by the platform; editors must not be required to use external image hosting. File attachments (non-image) are not required (see Scope Boundaries).
Internal/private articles: Editors must be able to mark individual articles or entire collections as visible only to authenticated internal users (i.e., members of the organization's account), separate from the publicly accessible help center content. This allows a single help center deployment to serve both external and internal audiences.
Multi-site support: The platform must support creating more than one distinct help center site within a single organization account, each with its own domain, branding, content, and access settings. The minimum required number of sites per account is two.
Editor and admin management: Administrators must be able to invite team members by email, assign them roles (at minimum: administrator and editor), and revoke access. Editors must be able to create and manage content but must not be able to change billing, account settings, or other editors' roles.

Cross-Cutting Requirements

Multi-tenancy: The application must support multiple independent organizations (tenants), each with isolated data.
Authentication: Users must authenticate with email/password at minimum. SSO and OAuth are not required.
Role-based authorization: The application must support at least three roles — administrator, manager, and standard user — with distinct permission levels appropriate to the category.
Data persistence: All user data must be persisted across sessions in a database.
Web application: The application must be accessible via a web browser. Native desktop or mobile applications are not required.
Concurrent users: The application must support multiple users within the same tenant using the application simultaneously without data corruption or loss.
Responsive design: The web application must be usable on both desktop and mobile browsers. A native mobile app is not required.

Scope Boundaries

AI-generated article drafting is not required. Writing assistance features that use LLMs to generate or expand article content are not table stakes for the category.
AI-powered conversational search / chatbot is not required. An AI assistant that answers end-user questions in natural language using article content (beyond standard keyword search) is not required.
Git-based content workflows are not required. The ability to sync article content with a Git repository, manage changes via pull requests, or write content in a local editor and push via version control is not required.
OpenAPI / Swagger rendering is not required. Automated generation of interactive API reference documentation from an OpenAPI spec is not required.
Multilingual / localization support is not required. The ability to maintain separate translated versions of articles or auto-translate content is not required.
Content translation workflows are not required. Tooling to manage translation assignments, review translated drafts, or integrate with localization services is not required.
Help desk / ticketing integration is not required. Native features that allow end-users to submit support tickets, or that route article feedback to a shared inbox, are not required.
Live chat integration is not required. A built-in chat widget that connects end-users with support agents is not required.
File attachments (non-image) are not required. The ability to attach downloadable files (PDFs, spreadsheets, etc.) to articles is not required.
Video hosting is not required. Native video uploads and hosting within the platform are not required. Embedding externally hosted videos via URL is encouraged but not required.
SEO metadata configuration per article is not required. Controls for setting per-article meta titles, descriptions, or Open Graph tags are not required.
Sitemap generation is not required. Automatic generation and hosting of an XML sitemap for the help center is not required.
Content review / approval workflows are not required. A formal workflow requiring another editor or admin to approve an article before it can be published is not required.
Article expiration or scheduled publishing is not required. The ability to set a future publish date or an automatic expiration date for articles is not required.
Feedback response / community comments are not required. A mechanism for editors to reply to article ratings or for end-users to leave open-text comments is not required (only a binary rating is required).
User-generated content submission is not required. End-users must not be able to create or submit articles.
SSO / SAML for end-user authentication is not required. Restricting help center access via enterprise SSO is not required; a platform-managed login is sufficient.
Salesforce, Zendesk, or CRM integrations are not required. Native data sync with third-party support or CRM platforms is not required.
Adaptive / personalized content is not required. The ability to display different article content to different authenticated end-users based on their profile or entitlements is not required.
In-product onboarding flows or interactive tours are not required. Guided walkthroughs or tooltips built on top of the help center platform are not required.
Changelog or release notes publishing is not required. A dedicated module for communicating product updates separate from help articles is not required.

Spec Metadata

Version: 1.0
Created: 2026-03-16
Last Updated: 2026-03-16
Status: Draft