How to Build a Self-Service Knowledge Base
How to build a self-service knowledge base that people actually use: choosing topics from ticket data, article structure, a writing template, categories, visibility and maintenance.
A self-service knowledge base is a collection of articles that lets customers or employees find answers without opening a ticket. Done well, it reduces repetitive work for the support team and gives requesters an immediate answer at any hour. Done poorly, it becomes a forgotten folder of outdated pages. The difference lies in how topics are chosen, how articles are written and how the base is maintained.
Start from your tickets, not from a blank page
The best source of topics is the questions people already ask. Export or review the last two or three months of tickets and look for:
- questions that appear many times ("How do I reset my password?");
- requests that follow the same steps every time ("How do I request a new laptop?");
- problems with a known workaround ("The report is blank? Clear the filter");
- answers that agents copy and paste.
Rank the candidates by frequency. Ten well-written articles covering the most common questions are worth more than a hundred covering rare cases.
Choose a simple structure
Group articles into categories that match how requesters think, not how your organization is structured. Customers do not know your department names; they know their problem.
| Audience | Example categories |
|---|---|
| Customers | Getting started, Account and login, Billing and invoices, Troubleshooting |
| Employees | Access and passwords, Equipment, Software, HR and benefits, Travel and expenses |
Five to eight categories are enough for most knowledge bases.
Write one article per question
Each article should answer a single question, and the title should be that question, in the requester's words. "How do I download an invoice?" is better than "Invoice management module overview".
A template that works
Title: How do I [do the thing]?
Short answer (1-2 sentences): what to do, in plain words.
Before you start: requirements, permissions, what you need at hand.
Steps:
1. ...
2. ...
3. ...
If it does not work: the most common problems and what to do.
Still need help? Link to open a ticket in the right category.
Writing tips
- Answer first. Many readers stop after the first paragraph; make sure it helps.
- Use numbered steps for procedures, one action per step.
- Use the words people use. If customers say "bill", do not write only "invoice".
- Add screenshots only where they help, and update them when the interface changes.
- Avoid internal jargon and abbreviations.
- Keep it short. If an article covers several questions, split it.
Decide who can read what
Not every article should be public. Common visibility levels:
| Visibility | Use for |
|---|---|
| Public | General questions anyone may have |
| Signed-in requesters | Account-specific procedures |
| Internal (employees) | Company policies and internal procedures |
| Staff only | Agent procedures, troubleshooting scripts, escalation contacts |
Staff-only articles are a powerful tool in themselves: they turn the knowledge of experienced agents into documentation that new agents can follow.
Put the knowledge base where people look
An article nobody finds does not reduce tickets. Make articles visible:
- publish them in the support portal, next to the button to open a ticket;
- link articles in replies ("you can find the steps here for next time");
- link from your product or intranet where the question usually arises;
- include them in onboarding material for new employees.
Keep it up to date
Outdated articles are worse than none: they generate tickets and damage trust. Set simple rules:
- every article has an owner;
- when a process or screen changes, updating the article is part of the change;
- review the most-read articles every quarter;
- when an agent notices that an article is wrong, they fix it or flag it immediately.
Measure the effect
You cannot measure tickets that were never opened, but you can observe trends:
- volume in categories covered by articles, compared with before;
- share of tickets where agents answer with an article link;
- questions in tickets that still have no article.
If a category keeps growing after you published articles, read the tickets: maybe the article is hard to find, unclear or does not solve the real problem.
Example: first month plan
| Week | Action |
|---|---|
| 1 | List the top 15 questions from ticket data; assign owners |
| 2 | Write the top 5 articles with the template; review with an agent |
| 3 | Publish in the portal; start linking in replies |
| 4 | Write the next 5; review volume in covered categories |
In Luradesk
Each company using Luradesk has its own knowledge base stored in its own database. Articles are written in Markdown, organized into categories, saved as draft or published and assigned a visibility level: public, requesters, internal or staff. Published articles appear in the company's service portal. Note that this is separate from the articles you are reading now, which are written by the Luradesk team.
Small and accurate beats big and stale
Choose topics from real tickets, write one short article per question with the answer first, organize by the requester's point of view, control visibility, place articles where people look and keep them current. A small, accurate knowledge base beats a large, outdated one.