# Zammad Wissensdatenbank Modul: Funktionen und Limits 2026 Zammads KB-Modul seit Version 3.0. Funktionen, Limits, für welche DACH-Teams es reicht und wann ein dediziertes Tool die bessere Wahl ist. Source: https://www.happysupport.ai/de/blog/zammad-wissensdatenbank-funktionen Published: 2026-06-04 · Updated: 2026-08-05 Author: Henrik Roth, Marketing Manager, HappySupport ## Summary - Zammad ist primär ein Ticketing-System, hat aber seit Version 3.0 (2019) ein integriertes Wissensdatenbank-Modul. - Artikel-Verwaltung mit Rich-Text-Editor identisch zum Ticket-Composer. - Verlinkung mit Tickets: per Shortcut ?? --- Zammad ist primär ein Ticketing-System, hat aber seit Version 3.0 (2019) ein integriertes Wissensdatenbank-Modul. Für DACH-Teams, die ohnehin Zammad als Helpdesk einsetzen, ist die Frage: reicht das KB-Modul, oder braucht es zusätzlich ein dediziertes Tool. Dieser Artikel deckt was das Modul kann, wo die Limits sind, und für welche Teams es ausreicht versus wann ein separates KB-Tool die bessere Wahl ist. ## Was das Zammad-KB-Modul kann Artikel-Verwaltung mit Rich-Text-Editor identisch zum Ticket-Composer. Kategorien-Hierarchie mit zwei Ebenen. Mehrsprachige Artikel im selben Modul. Sichtbarkeitsregeln: intern (nur Agents), kundenseitig (öffentlich oder nach Login). Kategoriebasierte Permissions seit Version 5.1. Verlinkung mit Tickets: per Shortcut `??` im Ticket-Composer wird ein KB-Artikel als Antwort eingebunden. Das ist die stärkste Funktion des Moduls, weil sie den Workflow zwischen Agent und KB direkt verbindet. Such-Integration: KB-Artikel sind in der globalen Zammad-Suche enthalten, Agents finden sie aus dem Ticket-Composer heraus. Versionierung: einfach, im Wesentlichen letzter Stand plus Modified-Datum. Anhänge: erlaubt, gleiche Storage-Engine wie Ticket-Anhänge. ## Wo das Modul an die Wand stößt Kein dediziertes Customer-Facing-UI. Die Public-Help-Center-Variante ist funktional, aber visuell minimalistisch. Theming ist begrenzt, Custom-CSS reicht für den eigenen Look, aber kein vollständiges Branding-Erlebnis wie bei Document360 oder HappySupport. SEO-Out-of-the-Box ist mittelmäßig. Sitemap wird nicht automatisch generiert, hreflang-Tags fehlen für Multi-Sprache, Canonical-Tags müssen manuell konfiguriert werden. Wer Zammads KB als externes Customer-Help-Center mit Google-Traffic betreiben will, baut sich technische Schulden auf. Keine umfangreiche Versionshistorie. Im Wesentlichen ist nur der letzte Stand in der Datenbank, plus Modified-Datum. Wer Compliance-getriebene Audit-Logs für Artikel-Änderungen braucht (Healthcare, regulierte Branchen), stößt an die Grenzen. Keine eigenständigen Analytics. Such-Anfragen, Klick-Raten, Conversion zu Tickets sind nicht prominent dokumentiert. Wer datengetrieben KB optimieren will, braucht externe Tools. ## Für wen das Modul ausreicht Kleine bis mittlere DACH-Teams, die Zammad ohnehin als Helpdesk haben und eine einfache interne plus externe FAQ-Basis brauchen. Anwendungsfall: Support-Team von 5 bis 30 Agents, KB-Volume unter 200 Artikel, einfaches Customer-Facing-Erlebnis ist okay, Google-Traffic auf KB-Artikeln ist nicht das primäre Ziel. Konkrete Bullet-Anforderungen, die Zammad-KB sauber abdeckt: - Interne Wissensbasis fürs Support-Team, mit Verlinkung in Tickets. - Einfache öffentliche FAQ-Seite mit zwei bis drei Kategorien. - Zwei oder drei Sprachen, ohne ausgefeilte SEO-Anforderungen. - Kategoriebasierte Permissions für unterschiedliche Sichtbarkeiten. ## Wann ein dediziertes KB-Tool sinnvoller ist Wenn das Help Center primär externes Customer-Facing-Tool ist, mit Google-Traffic als Wachstumshebel, brauchst du SEO-Out-of-the-Box, sauberes Theming, schnelles Suche-Erlebnis und idealerweise Doku-Pflege-Automatisierung. Konkrete Trigger für den Wechsel zu einem dedizierten Tool: - Über 500 Artikel im KB, oder schnelles Wachstum. - Externes Help Center als primärer Customer-Support-Kanal mit Deflection-Zielen. - Compliance-Anforderungen mit Audit-Logs. - Mehrsprachige Strategie mit hreflang und lokalisiertem Theme. - Brand-Awareness und Theme-Anforderungen, die über Zammads Theming hinausgehen. ## Das Pflege-Problem Zammad löst das Tooling, nicht das Pflegeproblem. Wenn das Produkt sich ändert, müssen die KB-Artikel angepasst werden. Ohne dedizierten Doku-Workflow ist Zammads KB in zwei Quartalen genauso veraltet wie eine alte Confluence-Installation. Optionen für die Pflege: dediziertes Doku-Team mit FTE-Aufwand, oder ein automatisierter Mechanismus, der KB-Artikel bei Produkt-Änderungen flaggt. HappySupport ist auf den zweiten Pfad spezialisiert. ## HappySupport im Kontext HappySupport ist kein Ticketing-System und ersetzt Zammad nicht. HappySupport sitzt neben Zammad als dedizierte Help-Center-Schicht für Kunden. Zammad bleibt das Ticketing-Backbone für Agent-Workflow, Eskalationen und SLAs. HappySupport übernimmt die Artikel-Ebene mit SEO-Out-of-the-Box, sauberer Customer-UI und automatischer Pflege. Mehr zur Architektur in [selbst-aktualisierende Wissensdatenbank](/blog/selbst-aktualisierende-wissensdatenbank), zur Vergleichs-Sicht in [Beste Wissensdatenbank-Software](/blog/beste-wissensdatenbank-software), und zur Help-Center-Aktualität in [Help Center aktuell halten](/blog/help-center-aktuell-halten). ## FAQ ### Was kann das Zammad-Wissensdatenbank-Modul? Artikel-Verwaltung mit Rich-Text-Editor identisch zum Ticket-Composer. Kategorien mit zwei Ebenen. Mehrsprachige Artikel. Sichtbarkeitsregeln intern/öffentlich. Kategoriebasierte Permissions seit Version 5.1. Stärkste Funktion: Verlinkung mit Tickets per ??-Shortcut, die Agents im Ticket-Workflow direkt KB-Artikel einbinden lässt. ### Wo stößt Zammads KB-Modul an die Wand? Minimalistisches Customer-Facing-UI, Theming nur über Custom-CSS. SEO-Out-of-the-Box mittelmäßig, Sitemap und hreflang fehlen. Keine umfangreiche Versionshistorie, im Wesentlichen nur letzter Stand. Keine prominenten Analytics für Such-Anfragen oder Klick-Raten. Wer KB als externes Help Center mit Google-Traffic betreibt, baut technische Schulden auf. ### Für welche Teams reicht Zammads KB-Modul? Kleine bis mittlere DACH-Teams mit 5 bis 30 Agents, die Zammad ohnehin als Helpdesk haben. KB-Volume unter 200 Artikel. Einfaches Customer-Facing-Erlebnis ist okay. Google-Traffic auf KB ist nicht primäres Ziel. Zwei bis drei Sprachen ohne ausgefeilte SEO-Anforderungen. Für interne Wissensbasis mit gelegentlicher Public-FAQ-Verlängerung ist es ideal. ### Wann lohnt sich ein dediziertes KB-Tool zusätzlich zu Zammad? Bei mehr als 500 Artikeln, wenn Help Center primärer Customer-Support-Kanal ist mit Deflection-Zielen, bei Compliance-Anforderungen mit Audit-Logs, bei mehrsprachiger Strategie mit hreflang und lokalisiertem Theme, bei Brand-Awareness-Bedarf der über Zammads Theming hinausgeht. In diesen Fällen sitzt das dedizierte KB-Tool neben Zammad, das für Ticketing bleibt. ### Wie pflege ich Zammads KB sauber? Zammad löst das Tooling, nicht das Pflegeproblem. Wenn das Produkt sich ändert, müssen die Artikel angepasst werden. Zwei Optionen: dediziertes Doku-Team mit FTE-Aufwand, oder ein automatisierter Mechanismus, der KB-Artikel bei Produkt-Änderungen flaggt. Ohne Pflege-Workflow ist Zammads KB in zwei Quartalen genauso veraltet wie eine alte Confluence-Installation.