Writing a Knowledge Base That Reduces Repeat Tickets

What a knowledge base is for

A support knowledge base is a collection of short articles that explain how to solve common problems or complete common tasks. Its goal is modest: let users answer routine questions themselves, and let support staff answer them consistently and quickly. When it works, fewer people raise a ticket for the same thing, and those who do get a more accurate reply.

It does not remove the need for a help desk. Some problems are unusual, some users prefer to talk to a person, and a fair number of apparently simple issues turn out to be something else. A knowledge base is best seen as one part of the user’s experience of support, not a replacement for people.

Choose topics from real tickets

The best source of topics is the ticket history. Look for questions that come up repeatedly: forgotten passwords, connecting to a wireless network or printer, setting up email on a phone, joining a video call, requesting access to a shared folder. A rough count by category shows where a good article would save most effort.

A few practical rules:

Start with the handful of most frequent issues rather than trying to cover everything.
Write for the problem as the user describes it, not as IT labels it. People search for “can’t print”, not “print spooler fault”.
Include things that are asked often but are not faults, such as how to request a new item. Those fit well alongside the service catalog.
Skip anything that carries real risk if followed wrongly, or that needs elevated access, and send those users to the help desk.

Structure that works

Consistency helps users scan an article quickly. A simple layout:

A clear title that states the problem or task, in everyday words.
A one- or two-sentence summary saying what the article solves and who it is for.
Before you start, listing anything needed, such as being on the company network or having a particular app installed.
Numbered steps, one action each.
What you should see, so the user can tell whether it worked.
If this does not work, saying how to contact support and what details to include.
Last reviewed, a date and an owner.

Numbered steps are one of the few places where a list is the right format, because order matters.

Writing the steps

Begin each step with a verb: “Open Settings”, “Select Network”, “Choose Save”.
Put one action in each step. If a step says “go to Settings, find Accounts and click Add”, the reader can lose their place.
Name things as they appear on screen, in the same words and capitalization. If the label differs between operating systems or versions, say so.
Avoid unexplained jargon and abbreviations. If a technical term is unavoidable, explain it once in plain words.
Say what a screenshot shows, and do not rely on it alone. Screenshots go out of date quickly and are hard to read for people using screen readers.
State warnings before the step they apply to, not after. If an action will sign the user out or delete something, say so first.
Keep the article short. If it runs to many screens, it probably covers more than one task.

An illustration

Here is a short example of the shape, with invented wording.

Title: My password has expired and I cannot sign in. Summary: This explains how to set a new password if your current one has expired. It applies to staff accounts. Before you start: You will need your phone if the organization uses a second sign-in step. Steps: 1. Go to the sign-in page. 2. Select “Forgot or expired password”. 3. Enter your work email address. 4. Follow the prompts to confirm your identity. 5. Choose a new password that meets the rules shown on screen. What you should see: A message confirming the change, after which you can sign in. If this does not work: Contact the help desk and tell us which step you reached and any message shown.

Keep security-related articles general. Do not publish internal details that would help an attacker, and have security staff review any article about authentication or access. If your systems use multi-factor authentication or single sign-on, describe the user steps without explaining the underlying configuration.

Make it findable

An article nobody finds does not reduce tickets. Practical steps:

Place the search box prominently on the portal or help page, and offer links to the most common articles.
Use titles and keywords that match what users type. Reviewing search terms that return no results shows what is missing.
Link from the ticket form: when someone selects a category, suggest relevant articles before they submit.
Let support staff link to articles in their replies, which also spreads awareness of what exists.

Keep it current

Out-of-date content does more harm than none, because users follow instructions that no longer match what they see and then lose faith in the whole resource. Basic upkeep includes:

Ownership. Each article has a named owner or team. Without one, nothing gets updated.
Review dates. Check articles at set intervals and after any relevant change to a system. This is where change control helps: a change that alters a screen should trigger an update to the article.
Retirement. Remove or archive articles for systems that no longer exist, in line with whatever your policies say on data retention schedules.
Feedback. A simple “Was this helpful?” option, with space for a comment, shows which articles confuse people.
Version awareness. If different groups use different versions of a tool, label the article accordingly.

Measuring whether it helps

It is tempting to claim a knowledge base has cut tickets by some figure. Be careful: ticket volumes move for many reasons, and a drop may mean users gave up. Reasonable indicators include how often articles are viewed, how many of those views end without a ticket, how often support staff use them, and the feedback ratings. Record a baseline of repeat tickets before you start, and treat any improvement as indicative rather than proven. Some of the numbers are covered under service desk metrics.

Common pitfalls

Writing from the technician’s point of view, assuming knowledge the user lacks.
Creating a large number of articles at once, then never reviewing them.
Letting duplicates build up, so users find three conflicting versions.
Hiding the route to a human, which frustrates people whose problem does not match any article.
Copying vendor documentation wholesale. It is often generic and does not reflect your own setup.

A small, accurate, well-maintained collection is more useful than a large, neglected one.