Knowledge base

Build a knowledge base around the product, not around a help desk.

A digital-product knowledge base does not need hundreds of articles. For a small seller, the useful knowledge is usually concentrated around the product itself: how to start, what is supported, what changed, what is currently broken and how the seller has approved answers to recurring buyer questions.

Quick answer

Start with one compact source of truth per product: current version, quick start, compatibility, known issues and approved Q&A. Expand only when real buyer questions prove that more documentation is needed. Keep the knowledge tied to the product and version so search or AI retrieval cannot mix unrelated or outdated answers.

What matters most

  • A small, current knowledge base is better than a large stale one.
  • Organize knowledge by product and version before adding more articles.
  • Use approved source material for buyer answers.
  • Make unknown information explicit instead of filling gaps with guesses.
  • Grow the knowledge base from real unresolved buyer questions.

Start with the five support facts buyers need most

Most digital products can begin with five blocks: current version, quick start, compatibility, known issues and approved answers. These cover what the buyer has, how to begin, whether their environment is supported, whether a problem is already known and what the seller has already answered.

That structure is intentionally smaller than a traditional company help center. The product is the organizing unit.

Separate source material from generated answers

If you use AI or search to answer buyer questions, the approved documentation should remain the source of truth. The generated answer is a way to retrieve and explain that source, not a replacement for it.

This distinction matters when the question is not covered. A system that is allowed to improvise beyond the source can sound helpful while being wrong about your product. A grounded system should be able to return an unknown outcome.

Use product and version boundaries

A generic knowledge base can accidentally retrieve an answer from the wrong product or an obsolete release. Keep content scoped tightly enough that the retrieval context matches what the buyer is actually using.

When a new version ships, review which sources and approved answers remain valid. Do not assume that every old answer should follow the product forever.

Let buyer questions decide what to document next

You do not need to predict every possible support question before launch. Publish the core knowledge, then watch what buyers ask that cannot be answered from it. Those unresolved questions are a prioritized documentation backlog created by real demand.

Approve broadly useful answers and leave one-off account-specific cases out of the reusable knowledge base. This keeps the knowledge clean and relevant.

Keep maintenance cheaper than support

A knowledge base only saves time if it stays easier to maintain than answering customers manually. Avoid unnecessary article sprawl. Prefer updating one current product fact over duplicating the same fact in six articles.

A permanent support page with compact structured knowledge can be enough for many small digital products.

Practical checklist

  1. Create one knowledge scope per product.
  2. Publish current version and quick-start instructions.
  3. Add compatibility and known issues.
  4. Add the documents or text that buyer answers are allowed to use.
  5. Create a clear unknown fallback.
  6. Review unresolved buyer questions and approve only broadly reusable answers.
  7. Review the knowledge whenever the product version changes.

Frequently asked questions

How many articles should a digital product knowledge base have?

There is no useful minimum. Start with the smallest set of current information that resolves real buyer questions. Expand from demand rather than from an article-count target.

Can a knowledge base just be one page?

Yes. For a focused digital product, one well-structured current support page can be easier for both the seller and buyer than a large multi-article help center.

What is the difference between approved knowledge and an AI answer?

Approved knowledge is the source material the seller controls. An AI answer should retrieve or summarize that material for the buyer. If the source does not support an answer, the system should not invent one.

SupportKeep

Turn the support system into one permanent buyer-facing page.

Keep the current version, compatibility, known issues and seller-approved buyer answers together. If approved sources do not support an answer, SupportKeep says it is not documented instead of guessing.