Online-Dokumentation sind die öffentlichen, im Browser erreichbaren Hilfeinhalte, mit denen Kunden und Interessenten Antworten finden, ohne ein Support-Ticket zu eröffnen. Gut gemacht fängt sie 30 bis 60 Prozent der wiederkehrenden Supportanfragen ab und wird zu einer relevanten Fläche für organische Suche. Schlecht gemacht wird sie ein ansehnlicher Bestand an Artikeln, die still falsch sind, die mobile Nutzer nicht navigieren können und denen im Team niemand vertraut. Der Unterschied zwischen beiden Ergebnissen liegt fast nie am Editor oder an der Hosting-Plattform. Er liegt an der Pflegedisziplin nach dem Start.
Dieser Leitartikel behandelt die drei Aufgaben, die Online-Dokumentation verlangt: Inhalte erstellen, die echte Kundenfragen beantworten, sie so hosten, dass sie schnell laden und ranken, und sie korrekt halten, während sich das Produkt ändert. Die meisten Guides zum Thema behandeln die erste Aufgabe und hören dann auf. Die Pflegedimension trennt Dokumentation, die sich bezahlt macht, von Dokumentation, die zur Belastung wird.
Was Online-Dokumentation tatsächlich bedeutet
Online-Dokumentation sind Hilfeinhalte, die auf einer öffentlichen Fläche erscheinen und die Kunden über die Suche, einen Hilfe-Link im Produkt oder eine direkte URL erreichen. Sie überschneidet sich mit Wissensdatenbanken, Help Centern und Produktdokumentation, ist aber breiter als jedes davon. Zu den Kategorien zählen kundenseitige Help Center, öffentliche Wissensdatenbanken, Produktdokumentation für Endnutzer, API-Referenzen für Entwickler-Zielgruppen und Schritt-für-Schritt-Anleitungen für Abläufe.
Der wirtschaftliche Fall ist geradlinig. Der Customer Service Benchmark Report von SuperOffice beziffert die Kosten einer Self-Service-Interaktion auf rund zehn Cent gegenüber acht bis dreizehn Dollar für ein bearbeitetes Ticket. Eine Wissensdatenbank, die 40 Prozent der Kundenfragen ohne Ticket beantwortet, spart dem Support-Team spürbar Personal. Die Falle: Die Knowledge-Centered-Service-Methodik nennt eine nutzbare Lebensdauer eines typischen Wissensartikels von rund sechs Monaten. Online-Dokumentation, die nicht aktiv gepflegt wird, wird binnen eines Jahres zur Fehlinformationsfläche, und die Fehlinformation wirkt verbindlich, weil sie auf der eigenen Domain der Marke liegt.
Die drei Aufgaben: erstellen, hosten, pflegen
Die meisten Dokumentationsprojekte stecken 70 Prozent des Aufwands ins Erstellen, 20 Prozent in Hosting-Entscheidungen und 10 Prozent in die Pflege. Die Aufteilung gehört meist umgedreht.
Erstellen
Den Artikel schreiben. Festlegen, wer die Zielgruppe ist, welche Frage sie beantworten will, wie detailliert es sein soll, was wegfällt und welche anderen Artikel verlinkt werden. Das ist die Aufgabe, in der KI-Entwurfswerkzeuge inzwischen weitgehend gut sind, auch wenn die Architekturentscheidungen (was weggelassen wird, welche Nutzertypen bedient werden) weiterhin menschliches Urteil brauchen.
Hosten
Den Artikel auf eine URL bringen, die schnell lädt, in der Suche rankt, mobil funktioniert, das Branding des Teams unterstützt und sich in den restlichen Support-Stack einfügt. Das ist die Aufgabe, um die Anbieter von Dokumentationsplattformen konkurrieren.
Pflegen
Den Artikel korrekt halten, während sich das Produkt ändert, Richtlinien aktualisiert werden, das Team wächst und Kundenerwartungen sich verschieben. Diese Aufgabe entscheidet, ob die Dokumentation nach zwei Jahren noch nützlich ist. Sie wird in der Bewertung untergewichtet und im Betrieb überbezahlt.
Wie du Online-Dokumentation erstellst
Gute Online-Dokumentation startet bei echten Kundenfragen, nicht bei internen Funktionslisten. Zwei Muster erzeugen zuverlässig Dokumentation, die Kunden wirklich nützlich finden.
Werte Support-Tickets für die ersten 20 Artikel aus
Zieh die Tickets der letzten 90 Tage, gruppiere sie nach Anliegen und sortiere nach Häufigkeit. Die 20 häufigsten Anliegen werden die ersten 20 Artikel. Das klingt offensichtlich und passiert selten. Die Alternative (ein Artikel pro Produktfunktion) erzeugt einen Bestand, der die Funktionsliste spiegelt und sehr wenige der Fragen beantwortet, die Kunden tatsächlich stellen. Siehe wie man eine SaaS-Wissensdatenbank aufbaut für das operative Muster.
Schreib zur konkreten Frage, nicht zum allgemeinen Thema
Artikeltitel, die genau die Formulierung enthalten, nach der ein Kunde suchen würde ("Wie kündige ich mein Abo?" statt "Abo-Verwaltung"), ranken besser und konvertieren besser. Der Kunde sucht die Antwort, nicht die Kategorie. Wissensdatenbank-Artikel schreiben behandelt die konkreten Muster, die funktionieren.
Nutze Medienvielfalt, wo sie ihre Kosten verdient
Videotutorials, Screenshots, GIFs und bebilderte Schrittanleitungen helfen jeweils anderen Lerntypen und anderen Fragetypen. Der Preis ist, dass Medien schneller veralten als Text. Ein Screenshot einer Oberfläche von vor sechs Monaten wirkt selbstbewusst falsch, wenn sich die Oberfläche geändert hat, auf eine Weise, wie veralteter Text es nicht tut. Nutze Medien anfangs großzügig, verfolge dann, welche Artikel am schnellsten abdriften, und pass die Mediendisziplin entsprechend an.
Strukturiere zum Überfliegen, nicht zum Lesen
Kunden überfliegen zuerst und lesen dann. Nutze H2- und H3-Überschriften als Entscheidungspunkte, führe jeden Abschnitt mit der Antwort an und stell die stützenden Details in den Fließtext. Aufzählungen und nummerierte Schritte für Abläufe.
Wie du Online-Dokumentation hostest
Die Hosting-Entscheidung teilt sich in drei ehrliche Optionen. Jede hat Abwägungen.
Auf einer Dokumentationsplattform bauen
Document360, Help Scout Docs, Intercom Articles, Zendesk Guide, GitBook, Mintlify, HappySupport. Diese Plattformen übernehmen Hosting, Editor, Suche, Analytics, Themes und einfache Integrationen. Die Preise reichen von 20 USD pro Nutzer und Monat bei manchen Tools bis zu 500 USD pauschal pro Monat bei anderen. Am besten für Teams, die die Dokumentationsfläche als Produktmerkmal behandeln wollen und nicht als Projekt. Der Preis ist Plattformbindung: Ein späterer Wechsel bedeutet Neuaufbau.
Auf einem Static-Site-Generator bauen
Docusaurus, MkDocs, Sphinx, Nextra, VitePress. Diese Werkzeuge erzeugen statisches HTML aus Markdown-Quelldateien in einem Git-Repository. Kostenlos oder günstig, voll anpassbar, keine Anbieterbindung. Am besten für entwicklungslastige Teams, die ohnehin in Markdown und Git arbeiten. Der Preis ist Betriebsaufwand: Suche, Analytics, Theming und Zugriffssteuerung muss das Team selbst verdrahten.
Als Teil der Marketing-Website bauen
Manche Teams legen Hilfeinhalte auf die Hauptseite unter einen /docs- oder /hilfe-Pfad, mit dem CMS, auf dem die Website läuft. Günstig und integriert. Der Preis ist meist ein schlechterer Editor für das Content-Team, eine schlechtere Suche und schlechtere Analytics als bei einem dafür gebauten Werkzeug.
Wie du Online-Dokumentation korrekt hältst
Die Pflegedimension ist der Ort, an dem die meisten Projekte scheitern und an dem die Zeitersparnis aus Self-Service über Supportanfragen wegen falscher Informationen wieder abgezogen wird.
Bau einen Rhythmus, der an Produkt-Releases hängt, nicht am Kalender
Quartalsweise Prüferinnerungen fangen etwas Veraltung und übersehen das meiste. Dokumentation sollte geprüft werden, wenn das Produkt ausliefert, nicht in fester Taktung. Teams mit wöchentlicher Auslieferung brauchen einen wöchentlichen Prüfprozess. Der GitLab DevSecOps Report findet, dass 65 Prozent der Teams wöchentlich oder häufiger ausliefern, eine Quartalsprüfung ist also für den größten Teil des Jahres falsch.
Schau jede Woche in die Suchanalytik
Das wirksamste Pflegesignal ist die Sackgassensuche: Ein Kunde hat etwas ins Suchfeld getippt und keine Treffer bekommen, oder Treffer bekommen und keinen angeklickt. Jede Dokumentationsplattform mit brauchbarer Analytik zeigt das an. Ein wöchentlicher Blick auf die häufigsten Sackgassensuchen erzeugt eine Liste zu schreibender oder zu korrigierender Artikel, die direkt darauf abbildet, was Kunden wirklich wissen wollen.
Binde Inhalte wo möglich an den Produktzustand
Das verlässlichste Pflegesignal ist die Beobachtung des dokumentierten Systems. Doku bei wöchentlichen Releases aktuell halten behandelt das operative Muster: Jede Codeänderung löst eine Prüfung gegen den Dokumentationsbestand aus, und Artikel, die die geänderte Fläche berühren, werden vor dem Release zur Prüfung markiert. Genau das macht HappyAgent für kundenseitige Hilfeinhalte, dasselbe Muster findet sich in Mintlify für an Code gebundene Entwicklerdokumentation.
Tool-Kategorien und wo sie passen
Tools für Online-Dokumentation teilen sich in vier praktische Kategorien.
Kundenseitige Help-Center-Plattformen
Document360, Help Scout Docs, Intercom Articles, Zendesk Guide, Freshdesk Knowledge Base, HappySupport. Für Support- und Customer-Success-Teams gebaut. Stark bei kundenseitiger Optik, SEO, Anbindung von KI-Suche und Deflection-Analytik. Siehe den Vergleich beste Help Center Software für den tieferen Blick.
Plattformen für Entwicklerdokumentation
Mintlify, GitBook, ReadMe, Redocly, Docusaurus. Für entwicklungsgetriebene Doku-Teams gebaut. Stark bei Markdown, OpenAPI-Anbindung und Git-Abläufen. Weniger stark bei Deflection-Analytik oder kundenseitigem Chat. Siehe die besten KI-Dokumentations-Tools für den tieferen Blick.
Interne Team-Wikis
Confluence, Notion, Guru, Slite, Tettra. Für interne Teams gebaut. Werden manchmal genutzt, um über einen öffentlichen Bereich kundenseitige Dokumentation zu hosten, was bei SEO und Suche gegenüber dafür gebauten kundenseitigen Werkzeugen meist Abstriche bedeutet.
Allgemeine CMS
WordPress, Webflow, eigene Umsetzungen auf Next.js oder ähnlich. Genutzt von Teams, die Dokumentation in die Marketing-Website einbetten wollen. Stark bei Markenintegration, schwach bei dokumentationsspezifischen Funktionen (Artikelhierarchie, Suchanalytik, Ticket-Anbindung).
Häufige Fehler
Drei wiederkehrende Fehler kosten Teams mehr als jede Toolwahl.
Den Start als Ende des Projekts behandeln
Der Start ist der Anfang der Arbeit, nicht das Ende. Ein Dokumentationsbestand ohne Pflegedisziplin verfällt schnell. Plan laufende Investition ein, kein einmaliges Projekt. Die Pflegefalle der Dokumentation behandelt, warum das der häufigste Fehlermodus ist.
Mobil ignorieren
Mobiler Traffic auf Hilfeinhalte macht typischerweise 30 bis 50 Prozent des Gesamtverkehrs aus, bei Endkundenprodukten oft mehr. Dokumentation, die mobil nicht funktioniert (lange, nicht umbrechende Tabellen, falsch beschnittene Screenshots, Navigation hinter Hover-Zuständen), verliert die halbe Zielgruppe lautlos.
Die Suchanalytik auslassen
Sackgassensuchen sind das nützlichste Rückmeldesignal in der Online-Dokumentation, und die meisten Teams schauen nie ins Suchprotokoll. Schon eine wöchentliche Fünf-Minuten-Prüfung erzeugt eine wirksame Liste zu korrigierender Inhalte.
Was du messen solltest
Vier Kennzahlen decken das Nützliche ab.
Ticket-Deflection-Rate
Der Anteil der potenziellen Tickets, die über Self-Service gelöst werden. Schwer exakt zu messen, Näherungen sind das Verhältnis von Artikel zu Ticket in Nutzerpfaden und Umfragen, ob der Artikel die Frage beantwortet hat.
Sackgassen-Suchrate
Der Anteil interner Suchen, die keine Treffer oder keinen angeklickten Treffer ergeben haben. Sollte im Zeitverlauf sinken, während Inhalte Lücken schließen.
Anteil aktueller Artikel
Der Anteil der Artikel, die in den letzten N Tagen geprüft wurden, wobei N der Release-Taktung entspricht. Teams mit wöchentlicher Auslieferung sollten wöchentliche Aktualität anstreben, Teams mit quartalsweiser Auslieferung längere Fenster.
Zeit bis zum Fund
Wie lange ein Kunde sucht, bis er die Antwort erreicht (oder aufgibt). Gemessen über Suchanalytik und Verhaltensverfolgung auf der Seite. Eine sinkende Zeit bis zum Fund ist das sauberste Signal dafür, dass die Dokumentation besser wird.
Der Ansatz von HappySupport für Online-Dokumentation
HappySupport ist für die kundenseitige Fläche der Online-Dokumentation gebaut, mit der Pflegedimension als primärem Designziel statt als nachträglichem Gedanken. HappyRecorder erfasst Abläufe beim Anlegen des Artikels als DOM- und CSS-Selektoren, was jedem Artikel eine strukturierte Bindung an das laufende Produkt gibt. HappyAgent GitHub Sync liest das Produkt-Repository, verknüpft Codeänderungen mit betroffenen Artikeln und macht sichtbar, was zu prüfen ist, bevor Kunden auf eine veraltete Seite stoßen. Das Ergebnis ist Online-Dokumentation, die im Tempo der Produktauslieferung korrekt bleibt statt im Tempo, in dem das Support-Team manuell prüfen kann. Für Teams mit wöchentlicher Auslieferung ohne eigenes Doku-Team siehe wie selbstaktualisierende Help Center funktionieren und das Playbook für Dokumentation bei wöchentlichen Releases.
Demo buchen