Most knowledge bases die. Someone creates them with good intentions, writes 20 articles, and six months later half are outdated, nobody can find anything, and agents go back to asking colleagues on chat. The problem is never the tool — it’s the process around it.
GLPI has a built-in knowledge base module. Making it work long-term requires less writing and more discipline.
What belongs in the KB
Not everything. The knowledge base is for solutions that agents use repeatedly — not for one-off fixes or project documentation. Good candidates:
- Recurring incident resolutions — "Outlook won’t connect after password change" with step-by-step fix
- Standard procedures — "How to onboard a new employee" checklist
- Known errors — "SAP login fails between 02:00-02:15 during nightly batch — this is expected, not an incident"
- Configuration references — VPN settings, printer driver versions, approved software list
Bad candidates: meeting notes, project plans, vendor contracts. Those belong in a document management system, not in the helpdesk KB.
Writing articles that get used
Structure matters more than prose
An agent with a user on the phone doesn’t read paragraphs. They scan for steps. Every KB article should follow the same structure:
- Symptom — what the user reports ("I can’t print")
- Cause — what’s actually happening ("Print spooler service stopped")
- Resolution — step-by-step fix (numbered, specific, with screenshots if needed)
- Applies to — which systems, which user groups, which locations
Title = the symptom, not the solution
Agents search for what the user tells them: "Outlook won’t open," not "Recreate Outlook profile." Title articles by symptom so they appear in search results when the agent types what they heard from the user.
One article per problem
Don’t combine "printer issues" into one mega-article. Split into: "Printer offline on Windows," "Printer driver installation for Mac," "Printer tray mismatch error." Shorter, findable, maintainable.
Keeping it alive
The biggest risk is decay. An article written for Windows 10 becomes wrong on Windows 11. A process changes but the KB article doesn’t. Two practices help:
- Review date on every article — GLPI supports an expiration/review date field. Set it to 6 months after creation. When it expires, the article appears in a review queue. Someone confirms it’s still accurate or updates it.
- Link articles to tickets — when an agent uses a KB article to resolve a ticket, they can link it. Articles that get linked frequently are clearly valuable. Articles that never get linked are either unfindable or irrelevant — both worth investigating.
Visibility control
GLPI’s KB supports different visibility levels:
- Public — visible to end users in the self-service portal (FAQ-style)
- Technician-only — visible only to agents (internal procedures, workarounds)
- Entity-scoped — visible only within specific entities (relevant for multi-entity setups)
Start with technician-only. Publish to end users only the articles that genuinely help them self-serve — not internal troubleshooting steps that would confuse them.