Help Center aktuell halten: Doku-Updates bei jedem Release

Damit dein Help Center aktuell bleibt, koppelst du Doku-Updates an das Release statt an den Kalender: Finde heraus, welche Artikel eine Änderung betrifft, sortiere sie nach Wirkung auf Nutzer und korrigiere die kritischen, bevor das Release live geht. Alles Weitere in diesem Leitfaden dient dazu, diese drei Schritte so günstig zu machen, dass du sie jede Woche durchziehen kannst.

Der Leitfaden behandelt Ablauf und Release-Checkliste, die Übergabe an den Support, agile Dokumentation und Docs as Code, Dokumentationsschulden, Kosten und Aktualitätskennzahlen. Unsere Empfehlung für SaaS-Teams, die oft ausliefern, ist HappySupport: Es liest deine Commits und schlägt vor, welche Hilfeartikel aktualisiert oder neu geschrieben werden sollten, und dein Team prüft jeden Vorschlag, bevor etwas veröffentlicht wird.

Warum hinkt die Dokumentation bei wöchentlichen Releases hinterher?

Die Dokumentation hinkt hinterher, weil die Änderung in einem System passiert und die Doku in einem anderen lebt. Eine Entwicklerin benennt ein Menü um, merged den Pull Request, das Release geht raus. Nichts in diesem Ablauf sagt der Person, die das Help Center betreut, dass Schritt drei eines viel gelesenen Artikels jetzt falsch ist. Also bleibt er falsch, bis es jemand merkt, meistens ein Kunde. Das ist ein Signalproblem, kein Fleißproblem: Niemand kann einen Artikel reparieren, von dem er nicht weiß, dass er kaputt ist.

Fünf Arten, wie ein einziges Release einen Artikel bricht

Jede dieser Änderungen braucht eine andere Art von Prüfung. Deshalb kann ein Release mehrere Artikel auf einmal brechen:

• Geänderte Navigation. Aus „Einstellungen, dann Team“ wird „Organisation, dann Mitglieder“. Jeder Artikel, der den alten Pfad beschreibt, führt jetzt in eine Sackgasse.
• Umbenannte Buttons und Beschriftungen. Aus „Exportieren“ wird „Bericht herunterladen“. Leser suchen nach dem alten Wort oder nach einem Button, den es nicht mehr gibt.
• Veraltete Screenshots. Die Oberfläche ändert sich, das Bild nicht. Der Leser sieht im Artikel einen anderen Bildschirm als im Produkt und verliert das Vertrauen in beides.
• Neue oder umsortierte Schritte. Die alten Schritte wirken plausibel, also folgen Leser ihnen und scheitern auf halbem Weg. Meistens geben sie sich zuerst selbst die Schuld.
• Entfernte oder zusammengelegte Funktionen. Der Artikel beschreibt etwas, das es nicht mehr gibt. Das ist die irreführendste Variante, weil sie mit voller Überzeugung falsch ist.

Was wir in 44 SaaS-Help-Centern gefunden haben

In 44 SaaS-Help-Centern, die wir zwischen dem 2. August und dem 15. September 2026 gecrawlt haben, wurden die meisten Help Center nicht im Tempo ihrer Produkte gepflegt. Das Artikelalter stammt aus dem Änderungsdatum in der Sitemap und misst, wann ein Artikel zuletzt geändert wurde, nicht ob er stimmt. Die Methode beschreiben wir im Help Center Audit zu veralteten Artikeln.

In 15 von 36 Help Centern mit Datum war die Mehrheit der Artikel älter als sechs Monate. Alter allein beweist nicht, dass ein Artikel falsch ist: Ein stabiler Artikel zur Rechnungsstellung kann jahrelang stimmen. Bei einem Produkt, das jede Woche ausliefert, hat ein Artikel, der sechs Monate nicht angefasst wurde, aber rund 26 Releases überlebt. Die Wahrscheinlichkeit, dass keines davon seine Bildschirme verändert hat, ist gering.

Für DACH-Teams kommt etwas hinzu: 22 der 44 Help Center sind mehrsprachig. Wer auf Deutsch und Englisch dokumentiert, hat jede Änderung zweimal nachzuziehen, und die zweite Sprache fällt in der Praxis meist zuerst zurück. Mehr dazu im Leitfaden zur mehrsprachigen Wissensdatenbank.

Warum sich der Rückstand aufschaukelt

Hier ein eigenes Rechenbeispiel mit offengelegten Annahmen, keine Messdaten. Angenommen, ein Team liefert 50 Releases im Jahr aus und jedes Release ändert drei dokumentierte Bildschirme. Das sind 150 Artikelprüfungen im Jahr, bevor überhaupt ein neuer Artikel entsteht. Hat das Help Center 100 Artikel, muss jeder Artikel anderthalbmal im Jahr angeschaut werden, nur um korrekt zu bleiben. Die meisten Teams prüfen ihr Help Center bestenfalls quartalsweise, also wächst die Lücke mit jedem Release, das ohne passendes Doku-Update rausgeht.

Wie sieht ein Ablauf für Doku-Updates bei wöchentlichen Releases aus?

Ein Ablauf, der mit wöchentlichen Releases mithält, hat drei Teile: Erkennen, Priorisieren und Aktualisieren. Für den Anfang braucht keiner davon neue Software, und die manuelle Version zeigt dir, wo dein eigentlicher Engpass liegt.

Erkennen: wissen, was sich geändert hat, bevor die Leser es merken

Erkennen heißt, dass der Release-Prozess eine Liste der sichtbaren Änderungen liefert, bevor oder während sie ausgeliefert werden.

Die einfachste Form ist ein fester 15-Minuten-Termin mit der Entwicklung am Tag vor jedem Release, mit genau einer Frage auf der Agenda: Was hat sich in diesem Release an der Oberfläche geändert? Die Antwort ist eine kurze Liste geänderter Bildschirme, Abläufe und Beschriftungen, und sie bestimmt die Doku-Arbeit der Woche.

Priorisieren: nicht jede Änderung braucht ein Doku-Update

Wer jede Oberflächenänderung als Doku-Notfall behandelt, brennt die Person aus, die sie abarbeitet. Ein einfaches Raster hält die Arbeit verhältnismäßig:

• Kritisch, vor dem Release aktualisieren: neue Pflichtschritte, umbenannte Navigation, umbenannte Haupt-Buttons, entfernte Funktionen, die Artikel noch beschreiben.
• Standard, innerhalb eines Tages nach dem Release: verschobene Elemente auf demselben Bildschirm, neue optionale Einstellungen in einem dokumentierten Ablauf, geänderte Nebenbeschriftungen.
• Später, im nächsten Zyklus: neue Funktionen ohne bestehenden Artikel (die brauchen einen neuen Artikel, kein Update), reine Admin-Einstellungen, kleine optische Änderungen, die Beschriftungen und Schritte unberührt lassen.
• Keine Aktion: Backend-Änderungen, Performance-Arbeit, alles ohne sichtbare Oberfläche.

Für Beta-Funktionen, die sich jede Woche ändern, lohnt sich oft gar keine Schritt-für-Schritt-Anleitung. Eine kurze Erklärung im Produkt kostet weniger Pflege.

Aktualisieren: die Korrektur kleiner machen als das Problem

Wenn eine Korrektur bedeutet, jeden Screenshot von Hand neu aufzunehmen, zuzuschneiden und hochzuladen, frisst ein Release mit zehn betroffenen Artikeln einen Tag. Zwei Dinge verkleinern diese Arbeit: einen Ablauf in einem Durchgang neu aufzeichnen, statt ihn Bild für Bild nachzubauen, und zuerst auf Richtigkeit prüfen, erst danach auf Stil. Ein korrekter Artikel zum Release schlägt einen polierten eine Woche später.

Die Release-Checkliste für Dokumentation

Halte die Checkliste dort, wo die Entwicklung ohnehin arbeitet, im Issue-Tracker wie Jira oder GitHub Issues, nicht in einem separaten Doku-Werkzeug:

1. Sammle die sichtbaren Änderungen dieses Releases aus den Pull Requests, den Release Notes oder dem Termin vor dem Release.
2. Ordne jeder Änderung die Artikel zu, die den betroffenen Bildschirm, die Beschriftung oder den Ablauf erwähnen. Durchsuche das Help Center nach der alten Beschriftung, nicht nur nach dem Funktionsnamen.
3. Stufe jeden Artikel als kritisch, Standard, später oder keine Aktion ein.
4. Weise jeden Artikel einer namentlich benannten Person für diesen Produktbereich zu.
5. Aktualisiere kritische Artikel, bevor das Release live geht, und veröffentliche Artikel zu neuen Funktionen im selben Moment wie die Funktion.
6. Aktualisiere Standard-Artikel innerhalb eines Tages.
7. Klicke nach dem Release deine zehn meistbesuchten Artikel gegen das Live-Produkt durch.
8. Beobachte zwei bis drei Tage lang die Tickets. Jede Frage, die mehr als zweimal auftaucht, ist eine Doku-Lücke für den nächsten Zyklus.

Die Stichprobe in Schritt 7 lassen Teams am häufigsten weg, dabei zählt sie am meisten: Ein veralteter Artikel unter den meistbesuchten kostet mehr als zehn veraltete Artikel, die niemand liest.

Wer mehrsprachig dokumentiert, legt zusätzlich eine Frist für die Übersetzung kritischer Artikel fest. Ohne Frist bleibt die zweite Sprache dauerhaft ein Release zurück.

Was muss die Entwicklung vor einem Release an den Support übergeben?

Die meisten Teams haben keine kaputte Übergabe zwischen Produkt und Support, sondern gar keine, nur die Annahme, dass das Produktteam Bescheid sagt. Diese Annahme scheitert aus drei Gründen.

• Timing. Funktionen ändern sich bis zum Feature Freeze. Doku, die früher entsteht, wird neu geschrieben, Doku nach dem Launch kommt zu spät. Das nützliche Fenster ist kurz: vom Feature Freeze bis zum Release.
• Ungleich verteiltes Wissen. Die Entwicklung weiß, wie die Funktion funktioniert. Der Support weiß, was Nutzer dazu fragen werden. Ein guter Artikel braucht beides.
• Keine benannte Empfängerin. „Der Support findet das schon raus“ heißt, dass es niemand tut. Die Übergabe geht an eine Person: die Support-Leitung, eine erfahrene Agentin oder einen technischen Redakteur.

Die vier Fragen, die jede Release-Notiz für den Support beantwortet

Die Entwicklung beschreibt meist die Technik, der Support braucht die Wirkung auf Nutzer. Eine Übergabenotiz beantwortet vier Fragen:

1. Was hat sich geändert, in einfacher Sprache?
2. Welche Nutzer sehen es: alle, ein bestimmter Tarif, ein Kontotyp, eine bestimmte Konfiguration?
3. Was müssen Nutzer anders machen, falls überhaupt?
4. Welche bekannten Sonderfälle, Einschränkungen oder offenen Fehler werden Tickets erzeugen?

Dazu kommen zwei Listen: die bestehenden Hilfeartikel, die etwas Geändertes erwähnen, und die Themen, die einen neuen Artikel brauchen. Brechende Änderungen, also umbenannte Menüs, verschobene Einstellungen und geänderte Abläufe, gehören ausdrücklich genannt und nicht in einem Changelog versteckt. Ob Confluence-Vorlage, Pull-Request-Vorlage oder Slack-Nachricht ist zweitrangig, entscheidend ist die Gewohnheit. Mehr dazu im Artikel zur automatisierten Release-Dokumentation.

Das Release selbst zum Auslöser machen

Am häufigsten bricht ein simpler Schritt: Der Support weiß nicht, wann das Release passiert. Setze die Person, die die Doku verantwortet, auf dieselbe Release-Benachrichtigung wie die Entwicklung, ob GitHub-Release-Tag, Deploy-Hook oder Slack-Kanal. Bereite Artikel zu neuen Funktionen als Entwurf vor und veröffentliche sie, wenn das Release live geht.

Bleibt die Übergabe aus, braucht der Support einen Ersatzweg: Release-Tags direkt abonnieren und Tickets markieren, die durch Doku-Lücken entstanden sind. Über ein paar Monate zeigen diese Markierungen, welche Releases die meiste Support-Last erzeugen. Diese Belege brauchst du für das Gespräch darüber, wer in einem SaaS-Unternehmen die Dokumentation verantwortet.

Agile Dokumentation: was ändert sich an der Definition of Done?

Das Agile Manifest stellt „funktionierende Software über umfassende Dokumentation“, und viele Teams lesen darin die Erlaubnis, die Doku wegzulassen. So war es nicht gemeint. Jim Highsmith schreibt in der Geschichte des Manifests: „We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.“ Agile Dokumentation in diesem Sinne ist klein, aktuell und wird im selben Takt gepflegt wie das Produkt.

Das übliche Problem ist nicht zu wenig Dokumentation, sondern ein Wasserfall-Ablauf mitten im agilen Team: Doku wird nach dem Sprint geschrieben, als Lieferobjekt abgenommen und nach Freigabe veröffentlicht. Die Verzögerung ist eingebaut und summiert sich Release für Release. Gerade in Unternehmen mit ausgeprägter Freigabekultur verlängert jede zusätzliche Abnahmestufe den Rückstand.

Doku-Auswirkung in die Definition of Done

Ergänze jedes Ticket, das die Oberfläche berührt, um ein Feld: Doku-Auswirkung: keine / Update nötig / neuer Artikel nötig. Das Ausfüllen kostet im Planning Sekunden. Eine Story ist erst fertig, wenn die Auswirkung bewertet und, bei kritischen Fällen, erledigt ist. Mit diesem einen Feld ist Doku keine Überraschung am Sprint-Ende mehr, sondern eine priorisierte Liste, die schon existiert, wenn der Sprint endet.

Dazu gehören zwei praktische Regeln. Schreibe oder aktualisiere den Artikel, wenn die Oberfläche fertig ist, ausgelöst durch den Merge und nicht beim Sprint-Start, denn alles davor dokumentiert ein bewegliches Ziel. Und verlange keine Freigabe der Entwicklung für Doku-Updates: Entwickler geben Code frei, und jede zusätzliche Prüfschleife fügt dem Rückstand Tage hinzu.

Nicht jede Doku muss im Sprint entstehen. Zeitkritisch sind Artikel, die auf geänderte Bildschirme verweisen, und Artikel zu neuen Funktionen. Konzeptartikel veralten langsamer und laufen als eigenes Backlog-Item.

Rollen für Dokumentation in agilen Teams

Verteilte Verantwortung schlägt eine einzelne Verantwortliche, denn sonst wird aus einer Krankheitswoche ein Rückstand über drei Releases.

• Die Entwicklung markiert Änderungen. Sie trägt die Doku-Auswirkung in Tickets und Pull-Request-Beschreibungen ein. Die Artikel schreibt sie nicht.
• Eine Doku-Verantwortliche je Produktbereich hält diesen Bereich nach jedem Release aktuell. Oft ist das eine Produktmanagerin oder ein erfahrener Support-Mitarbeiter für diesen Bereich.
• Die Support-Leitung sichert die Qualität. Sie prüft, was sich in jedem Zyklus geändert hat, eskaliert kritische Updates und verfolgt die Aktualität. Ihre Aufgabe ist, den Zustand jedes Artikels zu kennen, nicht alle selbst zu schreiben. Ist sie zugleich die einzige Autorin, hilft der Leitfaden, wie du ein Help Center ohne Doku-Team pflegst.

Auch Customer Success gehört dazu: Wer einen Ablauf im Kundengespräch erklärt oder einen Workaround findet, hält ihn direkt als Artikel fest. Sonst geht dieses Wissen mit der Person.

Continuous Documentation, lebende Dokumentation und Docs as Code

Continuous Documentation ist Doku-Arbeit, die von Produktänderungen ausgelöst wird statt von einem Zeitplan. Wie bei Continuous Integration ist der Auslöser ein Merge oder ein Release, und der Umfang beschränkt sich auf das Geänderte. Das heißt nicht, dass eine Maschine dein Help Center schreibt, sondern dass der Auslöser automatisch kommt und Menschen prüfen und schreiben, statt zu suchen.

Lebende Dokumentation beschreibt das Ergebnis: Doku, die sich mit dem Produkt verändert, statt einmal geschrieben und eingefroren zu werden. Die Knowledge-Centered-Service-Methode (KCS) macht denselben Punkt für Support-Wissen mit ihrem Solve Loop, der Wissen beim Lösen eines Problems festhält, und ihrem Evolve Loop, der es über die Zeit verbessert. Für Produktdoku heißt das: festhalten, solange das Wissen frisch ist, und echte Änderungen die Überarbeitungen auslösen lassen.

Wo Docs as Code passt

Docs as Code heißt nach der Definition von Write the Docs, Dokumentation mit denselben Werkzeugen zu schreiben wie Code: Issue-Tracker, Versionsverwaltung, Klartext-Markup, Code-Reviews und automatisierte Tests. Für Entwicklerdoku wie API-Referenzen, die neben dem Code liegen, ist das das richtige Modell: Der Pull Request, der einen Endpunkt ändert, aktualisiert die Referenzseite im selben Review. Unsere Übersicht zu Werkzeugen für automatische Code-Dokumentation behandelt diese Seite.

Help Center sind anders. Dort schreiben oft Support-Leute, und die Artikel beschreiben Klickpfade statt Funktionen. Ein Repository löst das Kernproblem ohnehin nicht: Die Komponentenänderung, die einen Button umbenennt, berührt nicht die Markdown-Datei, die Lesern sagt, dass sie ihn klicken sollen. Was ein Help Center von Docs as Code braucht, ist der Auslöser, nicht das Dateiformat. Die Codeänderung sollte eine Doku-Prüfung anstoßen, egal wo der Artikel liegt.

Dokumentationsschulden und technische Schulden

Ward Cunningham hat die Metapher der technischen Schulden 1992 geprägt, und Martin Fowlers Zusammenfassung bringt sie auf den Punkt: Der Mehraufwand, den neue Funktionen kosten, sind die Zinsen auf die Schuld. Dokumentationsschulden funktionieren genauso. Jedes Release ohne Doku-Update erhöht die Schuld, die Zinsen zahlst du in Tickets und verlorenem Vertrauen.

Dokumentationsschulden gibt es in vier Formen:

• Fehlend: Eine Funktion wurde ausgeliefert, und niemand hat etwas geschrieben.
• Veraltet: Der Artikel stimmte beim Schreiben, dann hat sich das Produkt weiterentwickelt. Das ist bei schnell ausliefernden Produkten die größte Kategorie.
• Falsch: Von Anfang an falsch dokumentiert, oft nach einer Spezifikation statt nach dem Live-Produkt.
• Verwaist: Die Funktion ist weg, der Artikel ist noch indexiert, und Suche und KI-Assistenten spielen ihn weiter aus.

Warum Dokumentationsschulden unsichtbar bleiben

Der Unterschied zu technischen Schulden ist das Signal. Technische Schulden zeigen sich in fehlschlagenden Tests, langsamen Builds und sinkender Velocity, und die Entwicklungskultur hat Rituale dafür. Dokumentationsschulden haben keinen roten Build. Ein Artikel, der einen nicht mehr existierenden Button beschreibt, wird tadellos angezeigt. Der erste Alarm ist ein Kunde, der ihm gefolgt ist.

Deshalb braucht der Abbau zwei getrennte Schritte. Erstens ein zeitlich begrenztes Aufholen: veraltete Artikel nach Tickets und Aufrufen ordnen, nicht nach Alter, und die Spitze der Liste korrigieren. Der älteste Artikel ist selten der dringendste. Zweitens eine strukturelle Änderung, damit die Schuld nicht nachwächst: die Definition of Done von oben plus ein Erkennungsschritt, der aus Codeänderungen eine Prüfwarteschlange macht. Ein Aufhol-Sprint ohne die strukturelle Änderung setzt nur den Kontostand zurück. Bei wöchentlichen Releases steigt er innerhalb von Monaten wieder.

Was kostet veraltete Dokumentation?

Die direkteste Kostenstelle sind Kontakte, die der Self-Service hätte abfangen sollen. Gartner berichtete 2019, dass Live-Kanäle im Schnitt 8,01 US-Dollar pro Kontakt kosten, Self-Service dagegen etwa 0,10 US-Dollar. Ein falscher Artikel verhindert kein Ticket, er verzögert es nur: Der Kunde verbringt Zeit im Help Center, scheitert und landet frustriert in der Warteschlange.

Ein Kostenmodell für deine eigenen Zahlen

Das ist unser eigenes Rechenbeispiel. Ersetze jede Annahme durch deine Daten.

• Annahme: 300 Tickets im Monat sind Wie-mache-ich-Fragen, die ein korrekter, aktueller Artikel beantwortet hätte.
• Annahme: Jedes kostet den Gartner-Durchschnitt für Live-Kanäle von 8,01 US-Dollar statt 0,10 US-Dollar im Self-Service.
• Ergebnis: 300 × (8,01 minus 0,10 US-Dollar) = 2.373 US-Dollar im Monat oder 28.476 US-Dollar im Jahr, bevor du die Stunden für die manuelle Artikelpflege mitzählst.

Für deine erste eigene Zahl markierst du zwei Wochen lang Tickets mit einer Ursache wie „Artikel fehlt“, „Artikel falsch“ oder „Schritte befolgt, hat nicht funktioniert“. Multipliziere die markierte Anzahl mit deinen Kosten pro Kontakt. Werte die Markierungen danach wöchentlich aus: Artikel, zu denen sich Tickets derselben Ursache häufen, kommen auf die Update-Liste.

Die Kosten, die in keinem Ticket-Report stehen

• KI-Antworten übernehmen den Fehler. Ein KI-Chatbot oder Assistent im Produkt, der aus deinem Help Center antwortet, wiederholt einen veralteten Artikel jedem Kunden, der fragt, und zwar mit voller Überzeugung. Mehr dazu in warum KI-Chatbots falsche Antworten geben und im Plädoyer für eine einzige Wissensquelle für deinen Chatbot.
• Leser hören auf, es zu versuchen. Kunden, die an einem falschen Artikel scheitern, gewöhnen sich an, das Help Center zu überspringen und gleich ein Ticket zu öffnen. Diese Gewohnheit überdauert die Korrektur.
• Das eigene Team umgeht das Help Center. Das echte Wissen wandert in Slack-Threads und in die Köpfe erfahrener Kolleginnen.

Warum scheitern manuelle Doku-Updates ab einer gewissen Größe?

Der manuelle Ablauf von oben beseitigt die schlimmsten Ausfälle. Mit wachsendem Produkt und höherem Takt bricht er aber auf vorhersehbare Weise.

Der Engpass einer einzelnen Verantwortlichen. Wenn eine Person alle Updates verantwortet, liegt die Warteschlange nach einem vollen Release oder einem Urlaub mehrere Releases zurück.

Prüfungen nach Kalender. Ein Quartals-Audit findet drei Monate Abweichung auf einmal, nachdem die Leser sie schon erlebt haben. Auch monatlich laufen vier Releases auf. Zu wöchentlichen Releases passt nur ein ereignisgesteuerter Takt.

Die Grenze der Erkennung. Eine Redakteurin kann nur reparieren, was sie als kaputt kennt. Steht in der Release-Notiz „Verbesserungen an der Einstellungsseite“ und die Änderung hat tatsächlich vier Menüpunkte umbenannt, kann niemand daraus die Liste veralteter Artikel ableiten.

Screenshot-Werkzeuge optimieren den falschen Schritt. Bildschirmrecorder, die Screenshot-Anleitungen erzeugen, beschleunigen das Erstellen. Die Pflege war aber immer der größere Aufwand, und ein Screenshot hat keine Verbindung zu dem Element, das er zeigt. Schnelleres Erstellen heißt mehr Fläche, die von Hand gepflegt werden muss. Mehr dazu, warum Screenshots in Hilfeartikeln veralten.

Löst ein eigenes Doku-Team das Problem?

Ein eigenes Doku-Team bringt einheitliche Sprache, bessere Struktur und eine klare Verantwortung für Qualität. Die Erkennung löst es allein nicht: Auch Redakteure brauchen jemanden, der ihnen sagt, welche Artikel eine Änderung betrifft. Ohne Änderungssignal wird ein größeres Team vor allem besser darin, zu reparieren, was Kunden schon gemeldet haben.

Wie aktualisierst du Dokumentation aus Codeänderungen?

Die strukturelle Lösung überlässt das Erkennen dem System, das ohnehin weiß, was sich geändert hat: dem Code-Repository. Jede sichtbare Änderung läuft durch einen Commit oder einen Pull Request. Liest der Doku-Prozess diesen Strom mit, existiert die Liste betroffener Artikel, bevor das Release rausgeht, und die Leute verbringen ihre Zeit mit Prüfen statt mit Suchen.

So arbeitet der Git Handoff von HappySupport. Er liest Commits und Pull Requests aus GitHub, GitLab oder Bitbucket, fasst die Änderungen zu Themen zusammen, findet die betroffenen Hilfeartikel und schlägt Aktualisierungen oder neue Artikel vor. Dein Team prüft und übernimmt jeden Vorschlag, bevor etwas veröffentlicht wird. Git Handoff ist ab dem Professional-Tarif enthalten, für 399 Euro im Monat bei jährlicher Abrechnung (479 Euro bei monatlicher Abrechnung), zzgl. MwSt.

HappySupport Git Handoff

Der Prüfschritt ist Absicht. Ein Diff zeigt, dass sich eine Beschriftung geändert hat. Er zeigt nicht immer, ob der Ablauf drumherum für einen Leser noch Sinn ergibt. Geprüfte Vorschläge behalten das Tempo, ohne eine Vermutung zu veröffentlichen.

Anleitungen so aufzeichnen, dass sie sich gegen das Produkt prüfen lassen

Die zweite Hälfte ist, wie Artikel überhaupt entstehen. Der HappyRecorder, eine Chrome-Erweiterung oder Windows-App, nimmt einen Klickpfad als Schritt-für-Schritt-Artikel auf, mit Screenshots plus den DOM- und CSS-Selektoren jedes Schritts. Jeder Schritt hängt an dem Element, das er beschreibt, statt nur an einem Bild davon. Ändert sich ein Ablauf, ist die Neuaufnahme ein Durchgang durch das Produkt, statt den Artikel Bild für Bild neu zu bauen.

Den Verfall erkennen, den Commits nicht erklären

Nicht jeder veraltete Artikel kommt aus einem Commit: Links verrotten, Artikel verwaisen. Der nächtliche Doku-Audit führt 46 Prüfungen über das gesamte Help Center aus. Drumherum stehen das Help Center selbst, ein KI-Chatbot, der nur aus deinen eigenen Artikeln antwortet und Quellen nennt, eine Ticket-Inbox und ein In-App-Widget, zu Pauschalpreisen: Starter 129 Euro, Professional 399 Euro und Scale 899 Euro im Monat bei jährlicher Abrechnung (bei monatlicher Abrechnung 155, 479 oder 1.079 Euro), jeweils zzgl. MwSt. (Preise). Die Daten liegen in der EU: Die Anwendung läuft bei Netcup in Nürnberg, Datenbank und Dateien liegen in Frankfurt, und die KI-Verarbeitung findet ebenfalls in der EU statt, über Microsoft Azure OpenAI in Schweden und Amazon Bedrock. Mehr zur Funktionsweise im Artikel zur selbst aktualisierenden Wissensdatenbank und zum GitHub Sync für das Help Center.

Wie misst du, wie aktuell deine Dokumentation ist?

Artikelanzahl und Abdeckung verdecken das Problem: Viele Artikel, von denen ein Teil veraltet ist, lassen Leser öfter im Stich als wenige, die alle stimmen. Verfolge stattdessen diese Werte:

• Aktualitätsquote: der Anteil der Artikel zu Kernabläufen (Registrierung, Onboarding, Abrechnung, die wichtigsten Workflows), die seit dem letzten Release geprüft wurden, das sie betroffen hat. Setze dein eigenes Ziel und beobachte den Trend. Ziel ist, dass Kernabläufe nie mehr als ein Release zurückliegen.
• Doku-Verzögerung: die Zeit zwischen dem Ausliefern einer Änderung und dem Erscheinen des passenden Artikels. Bei kritischen Artikeln ist das Ziel null: Veröffentlichung mit dem Release.
• Doku-bedingte Ticketquote: Tickets mit der Markierung „Artikel fehlt“ oder „Artikel falsch“ als Anteil aller Tickets. Damit wird Aktualität über das Kostenmodell oben zu Geld.
• Abdeckung ausgelieferter Änderungen: der Anteil sichtbarer Änderungen eines Releases, die ein Update, einen neuen Artikel oder ein ausdrückliches „keine Aktion“ bekommen haben.

Wer mehrsprachig dokumentiert, misst die Aktualitätsquote je Sprache. Sonst verdeckt die gepflegte Hauptsprache, dass die Übersetzungen hinterherhängen.

Vorsicht bei Änderungsdaten

Aktualisierungsdaten sind das billigste Aktualitätssignal und am leichtesten zu täuschen. In unserem Crawl hatten 28 von 44 Help Centern Datumsangaben, die gesammelt durch eine Migration oder einen Theme-Wechsel gesetzt wurden. Ganze Artikelbestände wirkten so am selben Tag frisch, ohne dass jemand sie gelesen hatte. Führe deine eigenen Prüfdaten, getrennt vom Änderungsdatum des Systems, und zähle einen Artikel erst als aktuell, wenn jemand ihn gegen das Live-Produkt geprüft hat. Dann zeige Lesern dieses Datum: 29 der 44 Help Center zeigten keines, und Leser müssen raten, ob die Schritte noch gelten.

Häufige Fragen

Diese Fragen stammen aus Suchanfragen und Prompts an KI-Assistenten zu diesem Thema. Jede Antwort steht für sich.

Wir liefern wöchentlich aus und die Doku liegt drei Releases zurück. Was tun?

Hör auf, nach Kalender aufzuholen, und kopple die Doku an das Release. Ergänze jedes Ticket, das die Oberfläche berührt, um ein Feld zur Doku-Auswirkung, halte vor jedem Release einen kurzen Termin mit der Entwicklung und korrigiere kritische Artikel vor dem Release, Standard-Artikel innerhalb eines Tages. Arbeite den Rückstand dann einmal ab, beginnend mit den meistbesuchten Artikeln und denen, die Tickets verursachen. Ist das Erkennen danach noch der Engpass, verbinde den Doku-Prozess mit deinem Code-Repository, sodass jede Änderung eine Liste betroffener Artikel zur Prüfung erzeugt.

Wie verhindern Teams, dass Dokumentation veraltet, während sich der Code weiterentwickelt?

Sie machen Codeänderungen zum Auslöser für Doku-Arbeit. Die Entwicklung markiert die Doku-Auswirkung in Tickets und Pull Requests, eine benannte Person je Produktbereich prüft die betroffenen Artikel bei jedem Release, und die Support-Leitung verfolgt die Aktualität und die Tickets, die durch Doku-Lücken entstehen. Teams, die oft ausliefern, ergänzen ein Werkzeug, das Commits und Pull Requests liest und betroffene Artikel vorschlägt, damit die Prüfwarteschlange vor dem Release existiert.

Womit halten Teams ihr Help Center aktuell, wenn sich das Produkt ständig ändert?

Die meisten Teams kombinieren einen Prozess mit einem Werkzeug. Der Prozess besteht aus einer Definition of Done mit Doku-Auswirkung, einer Release-Checkliste und verteilter Verantwortung. Die Werkzeuge reichen von Docs-as-Code-Setups für Entwicklerdoku über Recorder, die einen Ablauf als Schritt-für-Schritt-Anleitung aufzeichnen, bis zu Help-Center-Plattformen wie HappySupport, die Commits aus GitHub, GitLab oder Bitbucket lesen, die betroffenen Artikel finden und Aktualisierungen vorschlagen, die das Team vor der Veröffentlichung prüft.

Gibt es ein Werkzeug, das Anleitungen automatisch neu erstellt, wenn sich die Oberfläche ändert?

Manche Werkzeuge entwerfen das Update für dich, aber ein Mensch sollte es freigeben. Der Git Handoff von HappySupport liest Commits und Pull Requests, findet die betroffenen Hilfeartikel und schlägt aktualisierte oder neue Artikel vor, die das Team prüft und übernimmt, bevor etwas veröffentlicht wird. Vollautomatische Umschreibungen ohne Prüfung riskieren, eine selbstsichere Vermutung zu veröffentlichen, wenn sich ein ganzer Ablauf und nicht nur eine Beschriftung geändert hat.

Was ist der Unterschied zwischen Dokumentationsschulden und technischen Schulden?

Technische Schulden sind die Mehrkosten künftiger Änderungen, die durch Abkürzungen im Code entstehen. Dokumentationsschulden sind die Lücke zwischen dem, was das Produkt tut, und dem, was seine Doku sagt. Beide wachsen mit jedem Release. Der Unterschied ist die Sichtbarkeit: Technische Schulden zeigen sich in fehlschlagenden Tests und langsamerer Auslieferung, Dokumentationsschulden lösen keinen Alarm aus, bis ein Kunde einem falschen Artikel folgt. Sie treten als fehlende, veraltete, falsche oder verwaiste Artikel auf, und veraltete Artikel machen bei Produkten mit häufigen Releases den größten Teil aus.