How to Create a Knowledge Base That Reduces Support Requests

The single biggest mistake is guessing what to document. Your support queue already tells you exactly what people get stuck on — you just have to read it.

Pull your last few hundred tickets and group them by topic. You're looking for the questions that come up over and over: password resets, billing questions, "how do I export…", setup steps, a recurring error message. A handful of topics usually account for a large share of your volume. Those are your first articles.

Two quick ways to find them:

• Tags and subjects. If you tag tickets (and you should — see our support workflow guide), sort by tag frequency. The top tags are your top articles.
• Search the inbox. Search recurring phrases like "how do I", "can't", "error", "reset" and skim the results.

Write down the actual wording customers use. People search a help centre with the same words they'd put in a support email — "invoice" not "billing document", "log in" not "authenticate". Matching their language is half of being findable.

A flat pile of 40 articles is unusable. Give people a shape they can scan.

A simple, durable structure for a small team:

• Getting started — onboarding and first-time setup.
• How-to guides — task-focused, one job per article.
• Troubleshooting — symptom-led articles ("X isn't working").
• Billing & account — plans, invoices, cancellation, data.
• FAQ — short answers that don't justify a full article.

Keep it to a handful of top-level categories. If you find yourself wanting ten categories, you probably want five categories with sub-articles instead. In Disqua you can nest categories and keep some articles internal-only for your team, so your agents get their own runbook alongside the public help centre.

Help articles are not blog posts. The reader is stuck, slightly stressed, and wants to be done. Write for that person.

A reliable article template

1. A descriptive title that matches the search — "How to reset your password", not "Password management".
2. A one-line summary of what the article covers, so the reader knows they're in the right place.
3. Prerequisites, if any ("You'll need admin access").
4. Numbered steps, one action per step, in the order the reader does them.
5. A screenshot for anything visual.
6. A "what if it doesn't work" note linking to the relevant troubleshooting article.

Other habits that pay off: use the customer's words in headings, keep paragraphs short, link related articles at the bottom, and never bury the answer under three paragraphs of preamble. If an article tries to cover two jobs, split it in two.

Write for two readers

Every public article serves the customer reading it and the agent who'll link to it. Clear titles and a one-line summary help the agent confirm in a glance that this is the right article to send. That's why writing help content is best done by the people answering tickets — they know which phrasing actually resolves the question and which leaves the customer replying "but how do I…?" A short editing pass keeps voice and formatting consistent as more agents contribute.

A great article nobody finds deflects zero tickets. Findability comes from three places:

• Search. Your help centre needs real search, and your titles need to match real queries. Disqua's portal is searchable, so customers type a phrase and land on the article.
• Internal linking. Cross-link related articles so one good answer leads to the next.
• The reply itself. The highest-leverage habit is agents linking to articles in their answers. When the helpdesk and knowledge base share a workspace — as they do in Disqua — an agent can drop a link from the ticket instead of rewriting the same answer, and the next customer with that question finds it first.

You can also deflect proactively: surface relevant articles in a live chat widget before a conversation starts, and link the most common articles from your product UI.

Treat the knowledge base like a product, not a publication. The signals worth watching:

• Article views — what people are actually reading.
• "Was this helpful?" feedback — Disqua lets readers mark an article helpful, so you can see which answers land and which need work.
• Ticket volume per topic — if you publish a great article and tickets on that topic keep coming, the article is either hard to find or doesn't answer the real question.
• Searches with no result — gaps you should fill next.

Build maintenance into your routine. A simple rule: whenever you answer the same question for the second or third time, either write the article or update the existing one, then link it in your reply. Review your top ten articles quarterly so screenshots and steps don't drift out of date. A knowledge base maintained this way compounds — every month it deflects a little more, and your helpdesk queue gets a little lighter.