Knowledge that stays inside one technician's head dies when they leave the company. A knowledge base is the insurance policy against know-how loss.
Why maintain a KB
- Self-service: users solve issues on their own by consulting public FAQs
- Speed: technicians find documented solutions instead of reinvestigating
- Onboarding: new technicians learn from existing documentation
- Continuity: knowledge survives when team members leave
Structuring the KB in GLPI
Recommended categories
- How-to: step-by-step tutorials (e.g. "How to reset an AD password")
- Troubleshooting: known issues and solutions (e.g. "Printer offline")
- Policies: rules and procedures (e.g. "Remote access policy")
- FAQ: frequently asked questions (public visibility)
Visibility
- Public: visible in the self-service portal (FAQs, basic tutorials)
- Technicians: visible only to support profiles
- Restricted: visible by specific entity or group
Engaging the team
- Set it as a KPI: "each technician should create 2 articles/month"
- Integrate it into the workflow: when closing a complex ticket, prompt for a KB article
- Gamify: contribution ranking by technician
- Review periodically: outdated articles lose credibility
Next step
Once the KB is populated, monitor the consultation rate vs ticket opening rate. If the KB is good, repetitive tickets should decrease.
