Teams mit mehreren Produkten oder Marken brauchen mehrere Help-Center-Instanzen unter einer Verwaltung. Die Anforderung ist häufig im DACH-Mid-Market, wo eine SaaS-Holding zwei oder drei Brands betreut, oder wo ein Tech-Unternehmen B2C- und B2B-Linien parallel führt.
Dieser Artikel deckt welche KB-Tools Multi-Brand sauber unterstützen (Document360 mit Projects, Zendesk Multi-Brand, Help Scout Multiple Sites), und liefert den häufig übersehenen Punkt: Multi-Brand löst das Branding-Problem, nicht das Pflege-Problem. Drei Marken bedeuten dreimal die Maintenance-Schuld.
Was Multi-Brand wirklich bedeutet
Drei verschiedene Anforderungen können hinter "Multi-Brand" stecken.
Erstens: vollständig separate Help Centers pro Brand mit eigenem Theme, eigener Domain, eigener Artikel-Basis. Das ist der harte Fall, der echte Multi-Brand-Unterstützung verlangt.
Zweitens: ein Help Center mit kategorienbasierter Trennung der Brands, gemeinsame Domain und gemeinsames Theme, aber unterschiedliche Artikel-Sets. Das ist der einfache Fall, den jedes Tool kann.
Drittens: ein Help Center mit konditionellem Theming basierend auf URL oder Login. Mittelschwierig, oft via Custom-Code lösbar.
Tools mit echter Multi-Brand-Unterstützung
Document360 mit Projects: jedes Project ist ein vollständig separates Help Center mit eigener URL, eigenem Theme, eigener Artikel-Basis. Verwaltung über ein zentrales Dashboard. Pricing skaliert mit Project-Anzahl. Stärkste Option im DACH-Mid-Market.
Zendesk Multi-Brand: separate Help Centers für jede Brand, eigene Theming-Optionen, eigene Domains. Verfügbar ab Suite Professional. Inkludiert maximal 5 Brands, mehr per Quote.
Help Scout Multiple Sites: in jedem Help Scout Plan ein Docs-Site, in höheren Plans 2 (Standard), 3 (Plus), 5 (Pro) Sites. Schöner mid-market-tauglicher Sprung.
HappySupport: jeder Workspace ist ein vollständiger Help Center, Multi-Workspace-Verwaltung im Standard-Plan inkludiert.
Confluence: nicht für Multi-Brand gebaut, theoretisch über mehrere Spaces lösbar, aber das Theming und URL-Setup sind suboptimal.
Intercom Articles: keine eigentliche Multi-Brand-Funktion. Workaround über mehrere Workspaces, was die Lizenzkosten multipliziert.
Das Pflege-Multiplier-Problem
Hier ist der Punkt, den die meisten Vergleichsartikel überspringen. Wer drei Brands mit drei Help Centers betreibt, hat dreimal die Maintenance-Schuld. Jeder Artikel-Update muss in drei Help Centers gepflegt werden (wenn der Inhalt geteilt ist) oder dreimal mit unterschiedlichem Brand-Bezug geschrieben werden.
Konkret: ein Produkt-Release, das alle drei Brands gleichermassen betrifft, erzeugt drei Artikel-Update-Aufgaben statt einer. Wenn das Support-Team ein gemeinsames ist, ist das eine dreifache Arbeitslast für dieselbe Information. Wenn das Support-Team brand-spezifisch ist, müssen drei Teams parallel auf dem Laufenden gehalten werden.
Das Pflege-Multiplier-Problem ist der häufigste Grund, warum Multi-Brand-Setups nach 12 bis 18 Monaten zerbrechen. Ein Help Center wird gut gepflegt, die anderen verfallen, der Effekt ist sichtbar in der Customer-Experience.
Wann Multi-Brand wirklich nötig ist
Erstens: rechtlich-getrennte Entitäten, die separate Brand-Identitäten pflegen müssen. Zweitens: unterschiedliche Produkt-Linien mit komplett verschiedenen Audiences. Drittens: B2C- und B2B-Linien, die unterschiedliche Ton- und Detail-Tiefen brauchen. Viertens: White-Label-Setups, wo Kunden ihren eigenen Brand auf einem White-Label-Help-Center sehen.
Wann ein Help Center mit Kategorien reicht
Erstens: zwei oder drei verwandte Produkte derselben Brand. Zweitens: ein Hauptprodukt mit Add-on-Modulen. Drittens: ein zentrales Help Center, das in Kategorien für unterschiedliche Customer-Segmente strukturiert ist (Trial-Kunden, SMB-Kunden, Enterprise-Kunden).
In diesen Fällen erspart die Single-Help-Center-Lösung das Pflege-Multiplier-Problem und ist meist die bessere Wahl.
Strategie für DACH-Mid-Market
Praktisch: erst prüfen, ob wirklich Multi-Brand nötig ist, oder ob eine kategorisierte Lösung reicht. Bei echtem Multi-Brand-Bedarf: Pflege-Strategie vor Tool-Auswahl klären. Wer macht die Updates für jeden Brand. Wie wird Content über Brands hinweg geteilt, ohne dreifache Pflege.
Wer aktuell Multi-Brand mit klassischen Tools betreibt und das Pflege-Multiplier-Problem spürt, sollte eine Doku-Automatisierung in Betracht ziehen, die Content-Updates aus Code-Diffs auf alle Brand-Instanzen verteilt.
HappySupport im Kontext
HappySupport unterstützt Multi-Workspace im Standard-Plan, ohne Tier-Sprung. Jeder Workspace ist ein vollständiges Help Center mit eigenem Theme und eigener Domain. Wichtiger: HappySupport-Artikel werden bei Produkt-Änderungen automatisch geflaggt, sodass Multi-Brand-Pflege nicht zur dreifachen manuellen Schuld wird. Der Code-Diff trifft alle relevanten Workspaces gleichzeitig.
Mehr zur Architektur in selbst-aktualisierende Wissensdatenbank, zum Pflege-Modell in Help Center aktuell halten und zum Aufbau in Help Center aufbauen in einer Woche.
