Article metadata
- Title
- e.g. Can't connect to office wifi on a personal phone
- Audience
- e.g. End user / service desk agent / engineer
- Applies to
- e.g. Windows 11 and macOS 14+; corporate and personal devices
Knowledge Base Article Template
Knowledge bases fail because articles are written for the author. The reader is stuck, mildly annoyed, and scanning, which means the fix belongs at the top and the explanation, if any, at the bottom.
What you get
- An article structure that puts the resolution first
- Separate templates for user-facing and agent-facing articles
- A quality checklist covering the things that make articles unusable
- Review metadata, so stale articles are visible
How to use this template
- 1
Put the fix first. Readers are stuck and scanning. Resolution steps go at the top; background, cause, and context go at the bottom for the minority who want them.
- 2
Write the title as the user's words. People search for 'can't connect to wifi', not 'wireless authentication failure remediation'. Title articles with the symptom as a user would describe it, and add the technical term as a keyword.
- 3
Give every article a review date and an owner. An article describing a system two versions out of date is worse than no article, because the reader follows it and ends up more confused. Visible review dates let readers judge how much to trust it.
What's inside
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Related templates
More free templates IT teams use alongside this one.
Service Desk
Get templateIT Service Catalog Template
A service catalogue written in IT's language lists systems. One written in the requester's language lists outcomes ('I need access to the finance system', not 'ERP permission provisioning') and that distinction decides whether anyone uses it.
Service Desk
Get templateTicket Priority Matrix
A priority matrix only earns its place if two different agents classify the same ticket the same way. This one defines impact and urgency as countable things (how many people, and whether work has already stopped), so the grid produces one answer instead of a conversation.
DevOps & SRE
Get templateRunbook Template
A runbook is read by a tired person at 03:00 who did not write it and does not know this service. That single constraint rules out most of what people put in runbooks: architecture background, rationale, and anything written in prose when it could have been a command.
Frequently asked questions
How should a knowledge base article be structured?
+
Symptom, then the quick fix, then second-line steps, then how to get help, with any explanation of cause last. Readers are stuck and scanning, so anything before the resolution steps gets skipped or causes them to leave.
How do you know if a KB article is good?
+
Give it to someone who does not know the answer and watch them follow it without assistance. Every pause or question is a defect. Authors cannot self-assess this because they unconsciously fill gaps the reader cannot.
How often should knowledge base articles be reviewed?
+
Every six to twelve months, and immediately after any change to the system described. Make the review date visible to readers so they can judge how much to trust instructions that may have gone stale.