Per-KB Pricing Model

Master this essential documentation concept

Quick Definition

A subscription pricing structure where costs are calculated based on the number of separate knowledge bases or documentation instances created.

How Per-KB Pricing Model Works

graph TD A[Organization Account] --> B[KB 1: Product Documentation] A --> C[KB 2: Internal IT Handbook] A --> D[KB 3: Customer Support Portal] A --> E[KB 4: Developer API Docs] B --> B1[💰 Billable Unit] C --> C1[💰 Billable Unit] D --> D1[💰 Billable Unit] E --> E1[💰 Billable Unit] B1 --> F[Monthly Invoice Calculation] C1 --> F D1 --> F E1 --> F F --> G{Pricing Tier Check} G -->|Within Plan Limit| H[Standard Rate Applied] G -->|Exceeds Plan Limit| I[Upgrade Tier or Pay Overage] H --> J[Total Monthly Cost] I --> J style A fill:#4A90D9,color:#fff style F fill:#F5A623,color:#fff style J fill:#7ED321,color:#fff style H fill:#B8E986,color:#333 style I fill:#FF6B6B,color:#fff

Understanding Per-KB Pricing Model

The Per-KB Pricing Model is a cost structure used by documentation platforms that charges organizations based on the number of discrete knowledge bases they create, rather than by user seats, page views, or storage consumed. This approach gives documentation teams clear visibility into costs as their documentation ecosystem grows across products, teams, or clients.

Key Features

  • Each knowledge base is treated as an independent, billable unit regardless of its size or content volume
  • Costs scale linearly with the number of documentation instances, making budgeting straightforward
  • Teams can often mix knowledge bases across departments, products, or external portals under one account
  • Pricing tiers typically bundle a set number of KBs, with overage charges or tier upgrades for additional instances
  • Access controls, branding, and settings are usually configurable per knowledge base independently

Benefits for Documentation Teams

  • Predictable cost forecasting as new products or projects require dedicated documentation spaces
  • Encourages clean separation of documentation by product line, audience, or department without cost ambiguity
  • Scales naturally for agencies or consultancies managing documentation for multiple clients
  • Avoids per-seat pricing penalties when large teams need read access without contributing content
  • Simplifies procurement conversations since costs are tied to tangible deliverables rather than abstract usage metrics

Common Misconceptions

  • More pages do not equal more cost — the pricing unit is the knowledge base container, not the content inside it
  • A single knowledge base is not limited to one product; teams can organize multiple topics within one KB to manage costs
  • Per-KB pricing does not restrict the number of contributors or editors unless combined with a per-seat model
  • Creating a knowledge base for testing or staging purposes still counts toward your billable KB count on most platforms

Real-World Documentation Use Cases

SaaS Company Managing Multi-Product Documentation

Problem

A growing SaaS company has three distinct products with different user audiences, requiring completely separate documentation portals with unique branding, navigation, and content — but managing them under one account for billing simplicity.

Solution

Adopt a Per-KB Pricing Model platform that allows three separate knowledge bases under one organizational account, each with independent branding and access settings, billed as three KB units.

Implementation

1. Audit all existing documentation to identify natural product boundaries. 2. Create one knowledge base per product (e.g., KB1: Core Platform, KB2: Mobile App, KB3: Analytics Suite). 3. Configure unique domains, logos, and color schemes per KB. 4. Assign dedicated content owners to each KB. 5. Monitor KB count against your pricing tier before launching new product lines.

Expected Outcome

Clean audience-specific documentation portals, predictable monthly costs tied to product count, and no cross-contamination of content between product lines.

Documentation Agency Serving Multiple Clients

Problem

A freelance documentation agency manages technical writing projects for five different clients, each requiring private, isolated knowledge bases that clients can access independently without seeing each other's content.

Solution

Use a Per-KB Pricing Model to create one knowledge base per client, treating each KB as a project deliverable billed to the client, with the agency's platform subscription cost factored into project pricing.

Implementation

1. Calculate the per-KB cost from your platform subscription and add it to client project quotes. 2. Create a new knowledge base upon contract signing for each client. 3. Set client-specific access permissions so each client only sees their own KB. 4. Archive or delete KBs when projects conclude to manage your active KB count. 5. Negotiate annual plans when client count stabilizes to reduce per-KB costs.

Expected Outcome

Scalable client management with clear cost attribution per project, professional isolated portals, and a pricing model that grows revenue as the client roster expands.

Enterprise IT Department Separating Internal Documentation

Problem

An enterprise IT department needs separate documentation spaces for HR policies, IT procedures, engineering runbooks, and onboarding guides — but a single monolithic wiki has made content governance and permissions unmanageable.

Solution

Migrate to a Per-KB Pricing Model platform and create department-specific knowledge bases, using the per-KB structure to enforce ownership boundaries and simplify access control by department.

Implementation

1. Map existing documentation to four department categories. 2. Create four knowledge bases: HR Policies, IT Procedures, Engineering Runbooks, Onboarding Hub. 3. Assign department heads as KB administrators. 4. Migrate relevant content into each KB using export/import tools. 5. Set SSO-based access rules so employees only see department-relevant KBs. 6. Review KB count quarterly during budget planning.

Expected Outcome

Improved content governance, faster document retrieval, clear departmental ownership, and predictable IT documentation budget tied to the number of departments served.

Startup Scaling Documentation Alongside Product Launches

Problem

An early-stage startup began with a single product knowledge base but is launching two new product lines within the year. The team needs to plan documentation infrastructure costs ahead of each launch without surprise billing.

Solution

Use the Per-KB Pricing Model's transparent cost structure to build documentation launch costs into each product's go-to-market budget, creating a new KB for each product release.

Implementation

1. Confirm the per-KB cost in your current pricing tier. 2. Add KB creation as a line item in each product launch checklist. 3. Upgrade your pricing tier proactively when approaching the KB limit. 4. Use a staging KB for pre-launch documentation drafts and retire it before billing cycles reset. 5. Document your KB inventory in a shared spreadsheet to prevent accidental creation of redundant instances.

Expected Outcome

Zero billing surprises during rapid growth phases, documentation infrastructure that scales in lockstep with product launches, and a replicable process for each new product release.

Best Practices

✓ Audit Your KB Inventory Before Upgrading Tiers

Many teams accumulate unused or duplicate knowledge bases over time — test environments, abandoned projects, or experimental portals — that inflate their billable KB count unnecessarily. A regular audit ensures you only pay for active, valuable documentation instances.

✓ Do: Conduct a quarterly review of all active knowledge bases, archive or delete inactive ones, and maintain a KB inventory log with owner names, creation dates, and business justification for each instance.
✗ Don't: Don't create new knowledge bases impulsively for short-term experiments without a plan to retire them, and don't let orphaned KBs accumulate because deleting them feels like losing work.

✓ Consolidate Strategically Before Splitting Documentation

The temptation to create a new knowledge base for every new topic or project can quickly push teams into higher pricing tiers. Thoughtful consolidation — grouping related audiences or products into one KB using categories and sections — can reduce costs without sacrificing organization.

✓ Do: Evaluate whether a new documentation need can be served by adding a section or category to an existing KB before creating a new one. Use KB splits only when audiences, branding, or access controls genuinely require separation.
✗ Don't: Don't create separate knowledge bases purely for cosmetic organization when internal navigation structures like folders, tags, or categories can achieve the same result within one KB.

✓ Factor Per-KB Costs Into Project and Client Budgets

For agencies, consultancies, or internal teams running project-based documentation, each new knowledge base represents a real cost that should be attributed to the project or client it serves. Treating KB creation as a free action leads to budget overruns.

✓ Do: Calculate the marginal cost of each additional knowledge base under your pricing plan and include it explicitly in project budgets, client proposals, or departmental chargebacks so costs are transparent and recoverable.
✗ Don't: Don't absorb KB costs into a general overhead budget without attribution, as this obscures the true cost of documentation infrastructure and makes it harder to justify pricing tier upgrades.

✓ Use Staging and Production KBs Intentionally

Teams often create staging or draft knowledge bases to test layouts, review content before publishing, or train new writers — but these count toward your billable KB total. A clear policy on staging environments prevents unnecessary cost accumulation.

✓ Do: Designate one shared staging KB for all pre-production testing and content review, rotate its use across projects, and delete it at the end of each billing period if it is not needed continuously.
✗ Don't: Don't create a separate staging KB for every project or product, and don't leave staging KBs active indefinitely just because they might be needed again someday.

✓ Negotiate Annual Plans When KB Count Stabilizes

Per-KB pricing on monthly plans often carries a premium compared to annual commitments. Once your organization has a stable, predictable number of knowledge bases, locking into an annual plan can yield significant savings while guaranteeing your KB capacity.

✓ Do: Track your KB count over a rolling three-month period to identify stability, then negotiate an annual plan that accommodates your current count plus 20% growth headroom to avoid mid-year tier upgrades.
✗ Don't: Don't commit to an annual plan during periods of rapid growth or organizational change when your KB count is volatile, as you may end up paying for a tier that no longer fits your needs.

How Docsie Helps with Per-KB Pricing Model

Book a Demo

Build Better Documentation with Docsie

Join thousands of teams creating outstanding documentation

Book a Demo