Companies often start with one knowledge base — either a customer-facing help center or an internal team wiki. As they grow, they realize they need both. But running two separate documentation platforms is expensive, fragmented, and hard to maintain.
The better approach: one platform, two portals.
External Knowledge Base
Your external KB is customer-facing. It's where users go when they have a question about your product. Its job is to deflect support tickets.
Key characteristics:
- Public access — anyone can read without logging in
- Branded design — matches your product's look and feel
- SEO optimized — articles should rank in Google for product-related queries
- AI chatbot — readers get instant answers without waiting for support
- Search analytics — know what customers are looking for
- Multi-language — serve global customers in their language
Content examples: getting started guides, feature tutorials, FAQ, troubleshooting, API documentation, release notes.
Internal Knowledge Base
Your internal KB is for your team. It's where employees find SOPs, policies, onboarding materials, and institutional knowledge. Its job is to prevent knowledge loss and reduce repetitive questions.
Key characteristics:
- Private access — only authenticated team members can view
- Role-based permissions — HR docs visible to HR, engineering docs to engineers
- Approval workflows — SOPs go through review before publishing
- Version control — every edit tracked with change notes
- Audit logs — who accessed what, when (compliance requirement)
Content examples: employee handbook, SOPs, runbooks, meeting notes, architecture decisions, vendor documentation, security policies.
When You Need Both
You need both when:
- Your support team needs internal troubleshooting guides that customers shouldn't see
- Your product docs reference internal architecture that should stay private
- You have content that starts internal and later gets published externally
- Different teams (support, engineering, HR) need different visibility rules
One Platform, Two Portals
FinalDoc supports this natively with mixed visibility. Within a single project, you can mark categories and articles as:
- Public — visible to everyone on your external portal
- Private — visible only to authenticated readers or team members
- Mixed — some categories public, others private, within the same portal
This means you maintain one knowledge base, one editor, one search index — but readers see only what they're authorized to see. Your support team sees everything. Customers see only public content.
Workflow Example
- Engineer writes an internal runbook for debugging payment failures
- Support manager realizes customers frequently ask about payment errors
- Writer creates a customer-facing version — simplified, without internal details
- Internal version stays private, customer version goes public
- Both live in the same project, both searchable by their respective audiences
Cost Comparison
| Approach | Cost | Maintenance |
|---|---|---|
| Two separate platforms | 2× license fees | 2× updates, 2× training, content duplication |
| One platform, two projects | 1× license, higher tier | Separate content trees, shared team |
| One platform, mixed visibility | 1× license | Single content tree, visibility per article |
Mixed visibility on a single platform is the clear winner for teams that need both internal and external documentation.
Getting Started
In FinalDoc, enable mixed visibility in Settings → General → Site Access. Set your default visibility, then override per-category or per-article. Private content is filtered from public search, public API responses, and the AI chatbot — so there's no risk of accidental exposure.