Service
Knowledge bases
When the answers to 'how do we do this' live in heads, Slack threads, scattered files, and old Confluence pages, every onboarding, every support case, every handover suffers. Structured knowledge is not a nice-to-have, it is insurance against the key-person bus factor.
The problem
Typical picture: an outdated Confluence with 300 articles, 60 of them truly relevant, nobody knows which. Next to that 20 SharePoint folders with Word documents from 2018. Slack threads with explanations that never made it into docs. One person who knows everything, currently on parental leave. An onboarding that officially takes 4 weeks and actually means 4 months of hands-on learning.
The real problem is rarely 'we need a better wiki'. The real problem is: nobody owns knowledge maintenance as a defined work area. The tools are there, the responsibility is not.
What helps: a clearly bounded knowledge area with owners, review rhythm, versioning, sensible search. For larger estates optionally a RAG layer with local LLM that cites answers from your documents, instead of hallucinating from the open web.
The solution
Phase 1: inventory existing knowledge. What is current, outdated, duplicate, or missing entirely. Structuring into clear categories with owners and review rhythm.
Phase 2: a lean knowledge architecture that the team actually uses: simple write templates, search paths, version indicators, expiry hints. Tool choice depending on your stack (Confluence, SharePoint, GitLab Wiki, Notion, optionally a small custom knowledge app).
Phase 3 (optional): RAG layer with local LLM (Ollama or vLLM), vector database (Qdrant or pgvector), embedding pipeline for the key documents. Results are citation-capable (shows source and section), hallucinations are bounded by score thresholds. GDPR-compliant on-prem, no cloud egress.
Typical use cases
- Support knowledge base: FAQs, troubleshooting blocks, escalation-ready workflow descriptions, with version status and owner
- Onboarding paths: per role a structured learning path with mandatory and optional modules, progress tracking
- Process documentation: every operational pipeline as a living document with owners and review date
- Code and Excel snippet library: reusable building blocks with examples and test data
- RAG with local LLM: staff ask in natural language, get answers from internal documents with citations
- Outdated-content detection: automatic flagging when articles have not been reviewed in 12 months
Concrete benefits
- Onboarding time cut in half or more: concrete learning paths instead of 'ask your colleague'
- Knowledge loss at staff turnover significantly reduced: knowledge is documented, not just in heads
- Support response times shortened: typical questions findable in seconds instead of minutes
- Audit fitness: auditors and reviewers see documented processes with owners
- Optional AI-ready: structured knowledge is the basis for RAG without hallucination risk, if relevant
How we work together
Knowledge inventory (1-2 days)
Where is knowledge documented today? What is current, outdated, duplicate? Who maintains what? Output is an inventory with concrete findings.
Architecture and minimal process
Categories, owner model, review rhythm, simple write templates. Tool choice depending on existing stack. No tool migration without clear reason.
Pilot with one topic area
Instead of 'everything new', a bounded area (one department, one product) as pilot. Lessons learned before broader rollout.
Scaling + optional RAG
Extension to further areas. If needed, RAG layer with local LLM for intelligent search over structured and unstructured content.
Frequently asked questions
Does this replace our ITSM wiki or Confluence?
Rarely. Usually we complement or restructure within the existing tool. A new tool only when the existing one structurally cannot carry it.
Can we throw ChatGPT at our docs?
Not without a contract and data-protection review. For truly sensitive content (customer PII, HR, tax, public-sector files) I build RAG with a local LLM on-prem. Nothing leaves the house, answers are traceable with citations.
What does a RAG setup for the internal knowledge base cost?
Pilot with 100-500 documents: 5-12 working days. Larger setups with incremental updates, multiple sources, audit logging: 15-30 days. Hardware on-prem (1 GPU, 24-48 GB VRAM) depending on model size.
What if the team still does not maintain the docs?
Then the tool is not the problem. Maintenance must be acknowledged as work time, not 'whenever you find a moment'. In the review meeting we see whether a defined weekly maintenance slot is realistic.
Can you help with the cultural side, not just the technical?
Partly. I am an engineer, not a change manager. But I can keep the maintenance process so lean that it does not fail on human discipline. For deeper culture work I point to specialists in my network.
Related services
Build or modernize a knowledge base?
Briefly describe the current situation: which tools, what is in there, what hurts most? You get an assessment with a realistic plan.