If your techs don't read the knowledge base and don't write in it, the fix isn't more content. It's a simple structure, a named owner, and a habit tied to ticket closure. You can start this month, and it doesn't cost much more than an hour of your time.
Why Techs Ignore the KB
Picture a tech who solves a recurring printer issue, writes the fix in a local note, and never shares it. The next tech hits the same issue a week later and spends an hour rediscovering what the first tech already knew. That's the real cost of a scattered KB: not the storage, but the repeat work.
My read is that techs avoid writing because they don't know where to put things, and they avoid reading because they don't trust the entries to be current. The answer is to make the system so simple that both actions feel like part of the job, not a separate task.
The Three Sections That Cover Most of What Techs Need
Start with three folders, or three categories in your wiki. That's it. Anything more and you're building a taxonomy nobody will maintain.
- "How we do things": standard procedures and client specifics. New tech checks here first: how to onboard a client, which client uses which vendor, the default password policy.
- "Fix it": symptom-led solutions from past tickets. Tag by symptom, not by ticket number. "Exchange error" is better than "Ticket 4421."
- "Policy": rules that matter, like security requirements and escalation paths. Short and unambiguous.
Keep each entry to one screen. If it's longer, it's a procedure that belongs in the first section, or it needs to be split. One screen is the rule that keeps the KB usable. My view: a short, rough entry that gets read beats a polished essay that doesn't.
One Owner, One Backup, One Monthly Review
A KB dies without an owner. Name a senior tech or service manager who approves entries, tags them, and prunes the outdated ones. Give that person a named backup for days off, and schedule a 30-minute review every month to clear out the stale stuff. Without a backup, the system fails the week the owner is on vacation. Leadership has to protect the owner's time or the KB becomes another thing that person does at 9pm.
The owner doesn't write every entry. They approve and clean. A junior tech can do the initial scrubbing, as long as the senior approves before it goes live.
Make It a Habit by Linking It to Ticket Closure
The habit is the hard part, and the best place to build it is where techs already are: at ticket closure. Add a "Did you check the KB?" step to the closure workflow, and make it a rule that any significant fix that isn't already in the KB gets a one-line entry before the ticket closes. Not full documentation. One line, like "Client X: VPN drop fixed, config set to auto. See entry #42."
That one-line entry is the core compromise. Requiring polished entries reduces writing, while rough notes risk inaccuracy, so the entry template must stay deliberately short. The one-line rule keeps it possible on a busy day.
When the System Fails (and How to Salvage It)
This approach fails in a few predictable ways. Techs may game the closure checkbox with "n/a" to skip the habit, and on high-volume days the step can get skipped. The manager has to watch for that and call it out. Not with a meeting, but with a quick "I see three tickets closed without a KB check today. What happened?"
It also fails when entries go stale and nobody prunes them. That's what the monthly review is for. If the KB gets abandoned after a busy month, don't relaunch a full project. Reset with a shorter entry template and a reminder that a one-line entry is enough.
What to Do Monday Morning
Start with the folder, not the fanfare. Create the three-section structure in whatever you already use: a shared drive, a wiki, or the ticketing tool's built-in KB. Then name the owner and the backup, and put the monthly review on the calendar for a standing slot. Send a one-paragraph announcement to the team: where the KB lives, what the three sections are, and that closure now includes a KB check.
That's it. One hour on Monday, and a habit that starts with the first ticket closed. The rest is a monthly review and a manager who watches for the skip.
mspoutpost.com/articles/an-internal-knowledge-base-your-techs-will-actually-use
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
