Start a knowledge base with tickets you already answer. Pull 90 days of closed tickets, list the 20 problems that repeat most, and give each article a writer, a reviewer, and an audience. Review articles when you use them, retire what goes stale, and measure use honestly.
That's how to create a knowledge base on a small IT team. It comes from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) a small IT team can run alone. Software choice and the article template are in our knowledge base software guide.
Key takeaways
Cambridge Dictionary defines a knowledge base as "a collection of information about a particular subject." On a helpdesk, it's short articles that answer what your queue asks more than once.
With a knowledge base, a fix is written once and sent as a link instead of retyped in every reply. The Knowledge-Centered Service (KCS) method, from the Consortium for Service Innovation, captures every solved issue: "If the issue is worth solving, it is worth saving." Its reason: "we cannot predict the future value of an experience." KCS also says "we should not create articles in anticipation of demand." Our view: a small team without that habit should build its starter list from what repeats, then capture one-offs as they are solved.
Upkeep is harder. One r/sysadmin member who runs a small team wrote: "No one updates it. People keep asking the same questions in Slack instead of checking the wiki." On a small team, the lead has to own the habit.
Sort 90 days of closed tickets by category, then read the resolution notes in the biggest ones. Tickets that share a symptom and a fix form one topic. List the top 20 and publish each when it's ready.
Example: a Wi-Fi category splits into Chromebooks that forgot the network and one dead access point. Only the first repeats, so it makes the starter list; capture the other fix when that ticket closes.
Common mistake: one article per category, mixing fixes that don't belong together.
The writer is the technician who closed the most tickets on that topic. The reviewer, a second technician, follows the steps on a real device. Working alone? You're the reviewer: rerun the steps a day later, and have one future reader try each user article. That's a usability check, not an independent review.
Example: whoever reset the most passwords writes that article; a teacher tries the user version.
Common mistake: three approvers on a two-line fix.
KCS names five audiences, from Internal to Public, and lets you limit customers to validated articles. Per-client access is a separate setting in your tool.
Common mistake: a public article with server names, admin steps, or one client's setup in it.
Search the knowledge base before writing. KCS creates a new article only when none already covers the issue, so update a match instead. Otherwise, shape the ticket's resolution with the template in our knowledge base software guide. After publishing, search with words from a real ticket and confirm the article comes up.
Example: a user wrote "printer says offline." If that search misses the mapping article, put those words in its title.
Common mistake: retyping the fix in every reply. Send the link with one of our ticket response templates.
Make the writer the article's owner. Anyone who finds a broken step sends the owner the link, and the owner fixes it or asks a second technician to test. KCS queues a flagged article "for rework."
Make every use a review, too. Purdue University IT asks technicians to "review articles for accuracy anytime they share an article."
Our view: add a backstop date for articles nobody opens. The University of Missouri's Division of IT sets the next review date "for maximum of 1 year" and suggests staggering dates.
Example: stagger the 20 review dates so one or two fall due each month.
Common mistake: one review day for all 20 articles, which nobody finishes.
Retire an article when it's no longer relevant or has been replaced. KCS: "Archiving an article is better than deleting it," because deleting breaks the link to tickets that used it.
Example: a new VPN client retires the old VPN article. One r/sysadmin member described a rule: a change ticket "cannot be closed without the doc updates have been marked as complete."
Common mistake: leaving a replaced article live next to its successor, so search returns both.
| Audience | Who it covers | Example use |
|---|---|---|
| Internal | People inside your organization | Clear an account lockout |
| Within a domain | One group, such as networking | Restore the core switch config |
| Partners | Trusted non-employees | A contractor's site access steps |
| Customers | Customers or users, typically signed in | One client's VPN steps |
| Public | Anyone | Set up school email on a phone |
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
A live walkthrough tailored to your team.
Searches and page views "don't have a one-to-one relationship to issues pursued and resolved," KCS notes. One r/sysadmin member reported that in five years, "the number of times a user clicked on a suggested article instead of opening a ticket is zero."
Track five numbers:
Example
Say 12 of last month's tickets were on user-facing topics, and 9 got a reply with an article link. Your links-sent rate is 9 ÷ 12 = 75%.
How this works in SherpaDesk
You can turn a solved ticket into an article with Create KB. Each article carries one of five publish levels. Three are Private: Tech/Admin Only, All Users, and Account Specific. Account Specific Portal and Public Portal are public and need no login. You can set a default level and inactivate articles you retire.
In a ticket reply, you can look up a public article and attach it; private articles don't show in that lookup. Your support portal can show articles, and you can create a portal per account.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin.
Base Camp is $45 per agent per month ($40 billed annually). The first agent is free, forever, and the trial is 14 days free with no card.
Knowledge Base In SherpaDesk →
Who this isn't for
Customer-support teams building a public help center at scale.
They differ by purpose. TechTarget calls a database information "set up for easy access, management and updating." A knowledge base is a collection of information about a subject, written as articles a person follows to solve a problem. Tickets live in a database; repeating answers go in the knowledge base.
Cambridge Dictionary defines it as "a collection of information about a particular subject." In IT support, it's the short articles your technicians and users search for fixes and how-tos. Each article has an audience, from your own staff to the public, that decides who can read it.
Good knowledge base articles usually solve one problem each. KCS: "Generally, there should be one KCS article per resolution and cause." Its checks ask if an article is unique, complete, and clear, with a fitting title, working links, and the right audience.
It depends on who reads the articles. Technician notes, end-user how-tos, and a client-facing help center can sit in one tool or several. Our knowledge base software guide compares tools for IT teams and MSPs. Check that a technician can send an article from a ticket reply.
Start with 20 candidates from your most repeated tickets of the last 90 days, publishing each as it passes review. In KCS training, students bring their "top ten current issues" to practice on. After that, capture new fixes as tickets bring them, not ahead of demand.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.