How to structure a customer knowledge base
Structure your knowledge base around the tasks customers want to complete. Start with a small set of clear categories, prioritize questions that block progress, and give each article one job.
Start with customer tasks, not your org chart
Export or review a recent sample of support conversations. Group them by the thing the customer was trying to do: invite a teammate, find an invoice, configure an integration, or recover access. Your internal team names rarely make good category names.
For a vertical SaaS business, mix universal tasks such as account access with the workflows specific to your product. A gym management product might need “Memberships” and “Class bookings”; a charging platform might need “Start a session” and “Payments.” Use the language your customers use.
Use a small, task-based starting structure
The following is a starting point, not a required taxonomy. Split a category when customers cannot distinguish its contents; combine categories when each holds only one isolated question.
| Category | Questions it should answer |
|---|---|
| Getting started | What do I need? How do I reach the first useful result? |
| Account & access | How do I sign in, manage permissions, or recover access? |
| Core workflows | How do I complete the jobs I bought the product for? |
| Billing & plans | Where are invoices? What happens when I change plans? |
| Integrations | How do I connect a tool, test it, and disconnect it? |
| Troubleshooting | What does this error mean? What is the safe next step? |
Choose the first articles by impact
Prioritize issues that block activation, a payment, or a frequent core task. Use actual question frequency and the cost of getting stuck. An obscure setting can wait while customers cannot accept an invitation.
- List repeated questions from support and onboarding.
- Mark the customer task and affected role.
- Estimate frequency from the evidence you have.
- Give an owner to the highest-impact gaps.
- Publish a useful first set, then expand from real demand.
The kit’s content-audit CSV gives you columns for priority, owner, status, source, locale, and review date.
Give every article one destination
Keep one canonical article for each answer. If a question appears in multiple workflows, link to that answer rather than maintaining contradictory copies. Give articles stable URLs and add related links to the prerequisite and next task.
A category is a browsing route, not a substitute for search. Test common customer phrases, including synonyms that do not match the product’s UI labels.
Assign ownership before you launch
A product or operations lead can coordinate the library, but each article needs someone who can verify the underlying behavior. Add a backup owner, a last-verified date, and a review trigger such as a product release, policy change, or recurring failed search.
For multiple languages, track each translation against the source article’s latest revision. Updating the English version does not update the translated answer.
Test the structure with real tasks
Give someone unfamiliar with the structure five common questions and ask them to find the answer. Note confusing labels and unnecessary clicks. After launch, compare searches, reads, and support contacts to find where the structure or the content needs work.
Page views alone do not prove resolution. Combine behavior with feedback and the support conversations that still happen.
Common questions
How many categories should a knowledge base have?
There is no universal number. A practical first draft is four to seven task-based categories. Test the labels against real customer questions and split or combine them as the library grows.
Should FAQs and how-to articles be separate?
Use FAQs for short decisions and rules, and how-to articles for a sequence of actions. Link between them instead of repeating the same answer in multiple places.
Take the next step.
Get the template and practical files that go with this guide.
Get the free Launch Kit