Teams, die nach einer "Dokumentations-Plattform" suchen, wollen meist eines: ein einziges System für interne Doku, kundenseitige Hilfeartikel, Entwicklerdokumentation und API-Referenz an einem Ort. Das Versprechen lautet einfachere Anbieterverwaltung, geringere Gesamtkosten und eine einheitliche Suche über alles. Die praktische Realität ist, dass die meisten Teams, die konsolidieren wollen, binnen achtzehn Monaten wieder zwei oder drei Tools betreiben, weil jede Dokumentationsdomäne wirklich andere Zielgruppen, redaktionelle Stimmen und Aktualisierungstakte hat. Dieser Beitrag definiert, was eine Dokumentations-Plattform tatsächlich ist, wann Konsolidierung die richtige Entscheidung ist und wann getrennte Tools das vereinheitlichte System schlagen.
Was ist eine Dokumentations-Plattform?
Eine Dokumentations-Plattform ist ein einziges System, das mehrere Dokumentationsarten erstellt, hostet und pflegt, unter einem Produkt, einer Abrechnungsbeziehung und idealerweise einem Suchindex. Der Unterschied zu einem Einzweck-Tool ist die Breite: Eine Dokumentations-Plattform versucht, interne Teams, externe Kunden, Entwickler und API-Nutzer aus einer Codebasis zu bedienen. Durchgängige Plattformen wie Mintlify, GitBook und Document360 gehören in diese Kategorie. Tools wie Docusaurus (nur Entwicklerdoku), Help Scout Docs (nur Kundenhilfe) und Notion (nur interne Doku) sind bewusst Einzweck-Tools.
Das Marketingwort lautet "All-in-one". Die technische Realität ist ein Tool, das sich mit wechselndem Erfolg in benachbarte Anwendungsfälle gedehnt hat. Der Customer Service Benchmark Report von SuperOffice beziffert die Kosten einer Self-Service-Interaktion auf rund 0,10 USD gegenüber 8 bis 13 USD für ein bearbeitetes Ticket. Eine Dokumentations-Plattform, die kundenseitige und interne Doku in einem System zusammenführt, kann die Gesamtkosten von Self-Service senken, aber nur wenn die Plattform beide Aufgaben wirklich beherrscht. Die meisten tun das nicht.
Die vier Dokumentationsdomänen
Dokumentation zerfällt in vier Domänen mit unterschiedlichen Zielgruppen, unterschiedlichen redaktionellen Standards und unterschiedlichen Aktualisierungstakten. Eine Plattform, die alle vier abzudecken beansprucht, muss jede davon gut beherrschen und nicht nur passabel.
Interne Produktdokumentation
PRDs, Design-Entscheidungen, Sprint-Notizen, Team-Wikis, Onboarding-Doku. Zielgruppe ist das Entwicklungs- und Produktteam. Autor ist der Produktmanager oder die Entwicklungsleitung. Der Aktualisierungstakt ist täglich, die meisten Inhalte werden binnen sechs Monaten aufgegeben. Tools: Notion, Confluence, Slite, Tettra.
Kundenseitige Hilfeartikel
Anleitungen, Fehlerbehebungsartikel, FAQ, Videotutorials. Zielgruppe ist der Endkunde. Autor ist das Support-Team oder ein technischer Redakteur. Der Aktualisierungstakt ist wöchentlich oder monatlich, die Lebensdauer der Inhalte bemisst sich in Jahren. Tools: Document360, Help Scout, Helpjuice, HappySupport.
Entwicklerdokumentation
SDK-Guides, Integrationstutorials, Codebeispiele, Architekturübersichten. Zielgruppe ist der externe Entwickler oder Partneringenieur. Autor ist das Developer-Relations-Team oder die Entwicklung. Der Aktualisierungstakt folgt dem Release-Zyklus des Produkts. Tools: Mintlify, Docusaurus, GitBook, MkDocs, Sphinx.
API-Referenz
Endpunkt-Dokumentation, Parametertabellen, Authentifizierungsabläufe, Antwortbeispiele. Zielgruppe ist der API-Nutzer. Autor ist das Entwicklungsteam oder DevRel. Quellformat ist OpenAPI oder eine ähnliche Spezifikationsdatei. Der Aktualisierungstakt ist jede Codeänderung. Tools: ReadMe, Redocly, Stoplight, Mintlify.
Dokumentations-Plattform gegen Einzweck-Tool
Eine Dokumentations-Plattform beansprucht, mehrere Domänen in einem Produkt zu bedienen. Ein Einzweck-Tool beherrscht eine Domäne gut und bindet benachbarte Tools über Such-Syndizierung, geteilte Sitemaps oder gemeinsames Branding an. Die Abwägung ist auf beiden Seiten real.
Plattformen gewinnen bei Anbieterverwaltung und Gesamtkosten, wenn das Team klein und der Dokumentationsbedarf überschaubar ist. Eine Abrechnungsbeziehung, ein Admin-Team, ein Suchindex. Die Integrationssteuer von drei getrennten Tools (SSO konfigurieren, Nutzerlisten synchronisieren, vier Rechtesysteme verwalten) entfällt.
Einzweck-Tools gewinnen bei der Qualität, wenn das Team groß ist und jede Domäne eine eigene verantwortliche Person hat. Das Team für Entwicklerdoku wählt Mintlify, weil MDX-first zum Workflow passt. Das Support-Team wählt Help Scout, weil der Doku-Editor neben dem Ticketsystem sitzt. Das interne Produktteam wählt Notion, weil das Team ohnehin dort lebt. Jedes Tool ist in seiner Domäne führend. Die Integrationssteuer ist real, aber begrenzt.
Wann eine einzige Plattform Sinn ergibt
Drei Bedingungen kippen die Entscheidung zugunsten einer vereinheitlichten Dokumentations-Plattform.
Kleines Team, enger Rahmen
Teams unter 20 Personen, die interne Doku und ein kleines kundenseitiges Help Center schreiben, können alles in GitBook, Document360 oder sogar Notion mit öffentlicher Veröffentlichungsschicht betreiben. Der Integrationsaufwand mehrerer Tools wiegt in dieser Größe schwerer als der Qualitätsgewinn pro Tool.
Gemischte Autorenschaft
Wenn dieselben Menschen interne und kundenseitige Doku schreiben, was in frühen SaaS-Phasen üblich ist, reduziert ein einzelnes Tool mit einem Editor und einem Rechtemodell das Umschalten zwischen Kontexten. GitBook ist hier der stärkste Kandidat, weil der visuelle Editor für Produktmanager funktioniert und der Git-Sync für Entwickler.
Eine Kernzielgruppe
Wenn das Produkt entwicklerorientiert ist und der Kunde ebenfalls Entwickler (DevTools, Infrastruktur, APIs), kann eine entwicklerorientierte Plattform wie Mintlify beide Zielgruppen bedienen. Kundenhilfe und Entwicklerdoku fallen zu einer Seite zusammen, weil der Kunde Doku genauso liest wie der Ingenieur.
Wann getrennte Tools eine einzelne Plattform schlagen
Drei Signale sprechen dafür, die Dokumentationsdomänen in getrennten Tools zu belassen.
Unterschiedliche Aktualisierungstakte
Interne Produktspezifikationen ändern sich täglich. Kundenseitige Hilfeartikel monatlich. Entwicklerdoku pro Release. Eine einzelne Plattform, die alle drei bedienen muss, läuft entweder im schnellsten Takt (und überfordert die kundenseitige Redaktion) oder im langsamsten (und lässt die Entwicklerdoku veralten). Getrennte Tools lassen jede Domäne im eigenen Takt laufen.
Unterschiedliche Autorengruppen
Wenn das Support-Team die Kundendoku schreibt, das Produktteam die internen Spezifikationen und die Entwicklung die Entwicklerdoku, gehen redaktionelle Stimme und Konventionen auseinander. Alle drei in dasselbe Tool zu zwingen erzeugt entweder einen Stilstreit oder uneinheitliche Dokumentation unter einer URL. Die Frage der Zuständigkeit wiegt schwerer als die Toolfrage.
Unterschiedliche Compliance-Anforderungen
Interne Doku kann sensible Kundendaten enthalten und SOC-2-Kontrollen erfordern. Kundenseitige Doku ist öffentlich und hat diese Anforderung nicht. Entwicklerdoku kann exportkontrollrechtliche Aspekte haben. Eine einzelne Plattform muss die strengste Anforderung für alle Inhalte erfüllen, was meist bedeutet, für den leichtesten Anwendungsfall Enterprise-Preise zu zahlen.
Wie du eine Dokumentations-Plattform bewertest
Fünf Fragen schneiden durch das Marketing.
Welche Domänen beherrscht die Plattform wirklich, statt sie nur abzudecken?
"Abgedeckt" heißt, eine Funktion steht im Produktkatalog. "Beherrscht" heißt, ein echtes Team betreibt diese Domäne seit einem Jahr auf der Plattform und ist zufrieden. Verlange von Anbietern zwei Kundenreferenzen pro Domäne, nicht eine. Das kundenseitige Help Center ist die Domäne, bei der Plattformen am häufigsten Qualität auslassen.
Wie sieht die Pflegedisziplin aus?
Dokumentation veraltet. Die Knowledge-Centered-Service-Methodik des Consortium for Service Innovation nennt eine nutzbare Lebensdauer eines typischen Support-Wissensartikels von rund sechs Monaten. Der GitLab DevSecOps Report fand heraus, dass 65 Prozent der Teams wöchentlich oder häufiger ausliefern. Eine Dokumentations-Plattform ohne Antwort darauf, wie sie veraltete Inhalte erkennt und markiert, verpflichtet das Team zu einem manuellen Audit-Laufband. Unser Beitrag zu veraltender Dokumentation rechnet die Kosten durch.
Wie fühlt sich der Editor für jede Autorengruppe an?
Lass einen Entwickler die Plattform mit einer echten Markdown-Datei ausprobieren. Lass einen Support-Agenten sie mit einem echten Hilfeartikel ausprobieren. Lass einen Produktmanager sie mit einem echten PRD ausprobieren. Die Plattform, die in allen drei Fällen gewinnt, ist selten. Die Plattform, die in zweien gewinnt, ist brauchbar. Die Plattform, die in einem gewinnt, ist ein Einzweck-Tool mit Plattform-Etikett.
Wie funktioniert die Suche über die Domänen hinweg?
Eine echte Dokumentations-Plattform hat einen Suchindex über alle Inhalte mit Rechtefilterung. Eine, die nur so tut, hat pro Domäne eine eigene Suche mit einer Meta-Suchschicht darüber. Teste es: Suche nach einem Begriff, der in zwei Domänen vorkommt, und schau, ob die Treffer sauber zusammenlaufen oder als zwei getrennte Listen zurückkommen.
Wie sieht der Rückweg zu getrennten Tools aus?
Die meisten Teams, die konsolidieren, entkonsolidieren später wieder. Die Plattform, die bei der Frage gewinnt "wenn wir eine Domäne in ein spezialisiertes Tool migrieren müssen, wie sieht der Export aus?", ist die Plattform, die über den realistischen Ausgang nachgedacht hat. Markdown-Export in ein Standardformat ist die Untergrenze. Erhalt der Git-Historie ist die Obergrenze.
Der Ansatz von HappySupport
HappySupport ist ein Einzweck-Tool und keine Dokumentations-Plattform, und dieser Fokus ist Absicht. Das kundenseitige Help Center ist die Dokumentationsdomäne, die am schnellsten verfällt, weil die Zielgruppe keine Bearbeitungsrechte hat und das Support-Team das kleinste Budget. Die Chrome-Erweiterung HappyRecorder erfasst Produkt-Workflows als DOM- und CSS-Selektoren in dem Moment, in dem ein Hilfeartikel geschrieben wird. Wenn ein Entwickler eine UI-Änderung ausliefert, vergleicht das System die gespeicherten Selektoren mit dem laufenden Produkt und markiert jeden Artikel, der nicht mehr passt. Die GitHub-Sync-Schicht HappyAgent liest das Produkt-Repository, verknüpft Codeänderungen mit betroffenen Help-Center-Artikeln und macht sichtbar, was zu prüfen ist, bevor Kunden auf eine veraltete Seite stoßen. Entwicklerdokumentation, interne Produktspezifikationen und API-Referenz gehören in Tools, die für diese Domänen gebaut sind. Das kundenseitige Help Center ist das, was HappySupport übernimmt, und es übernimmt es, indem es Pflege als Systemeigenschaft behandelt statt als Autorenaufgabe. Siehe wie selbstaktualisierende Help Center funktionieren und Help Center gegen Wissensdatenbank.
Demo buchen