Viele Teams sitzen zwei Wochen vor dem geplanten Launch vor einem halbfertigen Help Center und merken: Sie wissen nicht, was noch fehlt. Nicht weil sie nicht fleißig waren. Sondern weil niemand je aufgeschrieben hat, was vor dem Go-Live fertig sein muss.
Diese Checkliste ändert das. Neun Phasen, konkrete Aufgaben, keine Lücken. Wenn du alle Punkte abgehakt hast, ist dein Help Center bereit.
- Strategische Vorarbeit: Ziele, Zielgruppe, Metriken
- Inhaltsstruktur: Kategorien und Artikelplan
- Inhalte schreiben: Prioritätsliste und Qualitätsstandards
- Technisches Setup: Suche, AI, Integrationen, Zugangsdaten
- Analytics: Welche Metriken zählen und wie du sie einrichtest
- Team-Workflow: Wer aktualisiert was und wann
- Pre-Launch-Tests: Was vor dem Go-Live geprüft werden muss
- Launch-Tag: Die konkreten Aufgaben
- Die ersten 30 Tage: Monitoring und Iteration
Phase 1: Was muss ich vor dem Start strategisch klären?
Ein Help Center ohne klares Ziel ist ein Archiv. Niemand sucht darin, niemand pflegt es, und nach drei Monaten stimmt die Hälfte der Inhalte nicht mehr. Bevor du auch nur einen Artikel schreibst, brauchst du Klarheit über drei Fragen: Für wen baust du das? Was soll es leisten? Woran merkst du, ob es funktioniert?
- Definiere das primäre Ziel: Ticketvolumen reduzieren, Onboarding beschleunigen oder Self-Service-Quote erhöhen. Nur ein Ziel, nicht alle drei gleichzeitig.
- Beschreibe deinen typischen Nutzer in zwei Sätzen. Welche Vorkenntnisse hat er? Was frustriert ihn am meisten?
- Leg fest, welche Tickets du mit dem Help Center eliminieren willst. Schau dir dein Ticketsystem an und sortiere nach Häufigkeit.
- Bestimme drei Metriken für den Erfolg: z.B. Ticket-Deflection-Rate, Sucherfolgsrate, durchschnittliche Zeit bis zur Antwort.
- Lege ein realistisches Launch-Datum fest. Plane rückwärts: Welche Artikel müssen zum Go-Live fertig sein?
- Klär ab, wer das Help Center nach dem Launch betreibt. Ohne eine verantwortliche Person ist es in 90 Tagen veraltet.
Laut einer Studie von Forrester Research können Self-Service-Lösungen bis zu 67 Prozent der Supportanfragen abfangen, bevor sie ein Ticket erzeugen. Aber nur, wenn die Inhalte auf die tatsächlichen Fragen der Nutzer ausgerichtet sind.
Phase 2: Wie baue ich eine sinnvolle Inhaltsstruktur auf?
Die häufigste Struktur-Falle: Teams sortieren nach dem, was ihnen logisch vorkommt, nicht nach dem, was Nutzer suchen. Ergebnis: Nutzer finden nichts, schreiben ein Ticket und benutzen das Help Center nie wieder. Bau die Struktur um echte Nutzerfragen herum, nicht um dein Produktmenü.
- Exportiere deine Top-50-Tickets der letzten drei Monate. Das sind deine Kategorien.
- Fass ähnliche Fragen zu Themenblöcken zusammen. Typische Kategorien bei B2B SaaS: Erste Schritte, Konto und Abrechnung, Integrationen, Fehlerbehebung, Häufige Fragen.
- Begrenze dich auf maximal sieben Hauptkategorien. Mehr verwirrt.
- Schreib für jede Kategorie eine kurze Beschreibung (ein bis zwei Sätze), was dort zu finden ist.
- Leg die Artikeltiefe fest: Welche Themen brauchen einen ausführlichen Guide, welche reichen mit 200 Wörtern?
- Erstelle eine Artikelliste mit Priorität (P1 = vor Launch, P2 = erste 30 Tage, P3 = langfristig).
- Plane mindestens 10 P1-Artikel, bevor du live gehst. Weniger macht das Help Center wertlos.
- Prüfe, ob deine Struktur mobilfreundlich ist. Über 40 Prozent der Help-Center-Zugriffe kommen laut Statista vom Smartphone.
Phase 3: Wie schreibe ich Artikel, die Nutzern wirklich helfen?
Schlechte Help-Center-Artikel haben eins gemeinsam: Sie erklären, wie das Produkt gebaut ist, nicht wie Nutzer ihr Problem lösen. Schreib aus Nutzerperspektive. Jeder Artikel beantwortet eine konkrete Frage und führt zu einer konkreten Handlung.
- Schreib den Titel als Frage oder als Aufgabe: "Wie setze ich XY ein?" oder "XY einrichten: Schritt für Schritt."
- Fang jeden Artikel mit einem Satz an, der erklärt, was der Nutzer danach erreicht hat.
- Verwende nummerierte Schritt-für-Schritt-Listen für Anleitungen. Fließtext wird bei technischen Themen nicht gelesen.
- Füge Screenshots oder kurze Videos bei Schritten ein, die UI-Interaktion erfordern. Visuelle Hilfen reduzieren Rückfragen laut Nielsen Norman Group um bis zu 40 Prozent.
- Definiere einen Qualitätsstandard für alle Artikel: maximale Länge pro Abschnitt, Pflicht für Screenshots, Review vor Veröffentlichung.
- Lass jeden fertigen Artikel von jemandem lesen, der das Feature nicht kennt. Wenn er drei Fragen hat, überarbeite den Artikel.
- Schreib eine interne Notiz für jeden Artikel: Wann und wie wird er veralten? (z.B. "Aktualisieren bei nächstem UI-Release.")
- Baue einen Review-Prozess vor dem Launch ein: Wer gibt Artikel frei? Wie lange dauert der Review?
Teams, die HappyRecorder nutzen, lösen dieses Problem mit einem anderen Ansatz: Statt Screenshots manuell zu erstellen, zeichnet die Chrome Extension die UI-Interaktion direkt als DOM- und CSS-Selektoren auf. Keine Pixel, keine veralteten Bilder nach dem nächsten Release.
Phase 4: Was muss technisch eingerichtet sein?
Der technische Teil wird unterschätzt. Teams investieren Wochen in Inhalte und gehen dann mit einer Suche live, die keine Ergebnisse findet. Oder der Widget ist nicht eingebunden, sodass Nutzer im Produkt keinen Weg zur Hilfe finden. Das Technische muss vor dem Launch stehen, nicht danach.
- Richte die interne Suche ein und teste sie mit zehn echten Suchbegriffen aus deinen Tickets. Findet sie die richtigen Artikel?
- Konfiguriere Synonyme und Aliase: Nutzer suchen nach "bezahlen", dein Artikel heißt "Abrechnung". Das muss verknüpft sein.
- Binde den Help Center Widget in dein Produkt ein. Kontextsensitiv ist besser als generisch: Der Widget auf der Seite "Integrationen" sollte Integrations-Artikel zeigen.
- Richte SSO oder Zugangsbeschränkungen ein, wenn du Inhalte nur für eingeloggte Nutzer zeigen willst.
- Überprüfe die Ladezeiten. Ein Help Center, das über drei Sekunden zum Laden braucht, wird verlassen. Google bestätigt: Jede Sekunde Ladezeit kostet bis zu sieben Prozent Conversions.
- Konfiguriere den GitHub Sync (falls du HappyAgent nutzt): Welche Repositories werden überwacht? Welche Artikel sollen bei Code-Änderungen automatisch als veraltet markiert werden?
- Teste alle Integrationen: Ticketsystem, Chat-Tool, CRM. Nichts ist frustrierender als ein "Kontakt aufnehmen"-Button, der ins Leere führt.
- Richte einen CDaaS-Layer ein, wenn dein AI-Chatbot strukturierte Daten aus dem Help Center ziehen soll. Unstrukturierter Content liefert schlechte AI-Antworten.
- Erstelle Redirect-Regeln für alte URLs, falls du von einem anderen System migrierst.
Phase 5: Welche Analytics-Metriken zählen wirklich?
Pageviews sagen dir nicht, ob dein Help Center hilft. Sie sagen dir nur, dass Nutzer es besucht haben. Was du brauchst: Daten, die zeigen, ob Nutzer ihr Problem gelöst haben oder nicht.
- Richte Tracking für die Sucherfolgsrate ein: Anteil der Suchen, die zu einem Klick auf einen Artikel führen. Ziel: über 70 Prozent.
- Messe die Ticket-Deflection: Wie viele Nutzer haben das Help Center besucht und danach kein Ticket erstellt?
- Tracke "Failed Searches": Welche Begriffe liefern keine Ergebnisse? Das ist deine Content-Gap-Liste.
- Implementiere Artikel-Bewertungen (hilfreich / nicht hilfreich). Zwei Klicks, wertvolle Daten.
- Verbinde dein Help Center mit deinem Ticketsystem: Welche Tickets kommen trotz existierendem Artikel rein? Das zeigt dir, welche Artikel überarbeitet werden müssen.
- Richte ein wöchentliches Dashboard ein, das die fünf wichtigsten Metriken auf einen Blick zeigt. Kein Dashboard bedeutet kein regelmäßiges Review.
Laut einer Analyse von Zendesk sind 69 Prozent der Kunden lieber in der Lage, ihr Problem selbst zu lösen, als den Support zu kontaktieren. Nur wer seine Analytics richtig aufsetzt, sieht, ob er das auch liefert.
Phase 6: Wie stellen wir sicher, dass das Help Center aktuell bleibt?
Veraltete Help-Center-Artikel sind schlimmer als kein Help Center. Sie geben Nutzern falsche Anweisungen, erzeugen Frustration und beschädigen das Vertrauen. Ein Help Center ohne Wartungsplan ist eine Zeitbombe.
- Definiere eine klare Ownership: Welche Kategorie gehört welchem Teammitglied?
- Schreib in jeden Artikel ein "Zuletzt überprüft am"-Datum. Artikel ohne Datum veralten unbemerkt.
- Leg einen Review-Zyklus fest: Kritische Artikel (Onboarding, Abrechnung, häufige Fehler) alle vier Wochen prüfen. Alle anderen alle drei Monate.
- Verknüpfe den Content-Workflow mit dem Engineering-Prozess: Jeder Feature-Ticket im Sprint-Board sollte eine "Docs needed?"-Frage enthalten.
- Nutze GitHub Sync, wenn möglich: Wenn sich ein UI-Element ändert, wird der verknüpfte Artikel automatisch als "Review erforderlich" markiert. Das eliminiert 80 Prozent der manuellen Wartungsarbeit.
- Erstelle ein Changelog für das Help Center: Was wurde wann geändert? Hilft beim Team-Onboarding und bei der Qualitätskontrolle.
- Plane jeden Sprint eine "Help Center-Stunde" ein. 60 Minuten pro Woche reichen für ein gesundes Help Center bei einem Team von fünf bis zwanzig Personen.
Phase 7: Was prüfe ich direkt vor dem Go-Live?
Pre-Launch-Tests kosten zwei Stunden. Ein schlechter Launch kostet Wochen an Vertrauen. Mach diesen Teil nicht zu schnell.
- Teste alle P1-Artikel auf Vollständigkeit: Kein Schritt darf fehlen, kein Screenshot darf fehlen.
- Prüfe alle internen Links: Jeder Link in einem Artikel muss auf einen existierenden Artikel zeigen.
- Teste die Suchfunktion mit zwanzig Begriffen aus echten Tickets. Minimum 75 Prozent sollten relevante Ergebnisse liefern.
- Lass zwei bis drei echte Nutzer das Help Center testen: Gib ihnen eine konkrete Aufgabe ("Finde heraus, wie du eine Integration einrichtest") und schau zu, ohne einzugreifen.
- Prüfe die mobile Ansicht auf iOS und Android. Wirklich. Nicht nur kurz ansehen, sondern durchklicken.
- Teste den Widget im Produkt: Öffnet er sich? Zeigt er relevante Inhalte? Funktioniert der "Kontakt aufnehmen"-Button?
- Prüfe, ob Analytics-Tracking korrekt feuert. Teste mit einem Echtzeitbericht in deinem Analytics-Tool.
- Überprüfe SEO-Basics für die wichtigsten Artikel: Title-Tag, Meta-Description, H1. Nicht perfekt müssen sie sein, aber leer darf nichts sein.
- Schau, ob Zugangsbeschränkungen korrekt funktionieren: Können Nicht-Kunden das sehen, was sie nicht sehen sollen?
Phase 8: Was passiert am Launch-Tag konkret?
Der Launch-Tag ist kein Ziel. Er ist der Start. Trotzdem gibt es konkrete Aufgaben, die genau an diesem Tag erledigt werden müssen, damit der Start reibungslos läuft.
- Schalte das Help Center um 9 Uhr live. Nicht freitagabends, nicht montagmorgens mitten in einem Sprint.
- Informiere dein Support-Team eine Stunde vorher. Sie müssen wissen, dass das Help Center existiert, bevor Nutzer ihnen Fragen stellen.
- Schreib eine kurze In-App-Nachricht oder E-Mail an deine Nutzer: "Wir haben ein Help Center. Hier findest du Antworten sofort." Zwei Sätze reichen.
- Aktiviere alle Analytics-Dashboards und prüfe nach 60 Minuten das erste Mal: Gibt es Fehler? Werden Klicks getrackt?
- Notiere die drei häufigsten Suchanfragen des ersten Tages. Sie sagen dir, was als nächstes geschrieben werden muss.
- Stelle sicher, dass jemand am Launch-Tag erreichbar ist, um Feedback aufzunehmen. Nicht automatisieren, nicht delegieren.
- Schreib nach dem ersten Tag eine kurze Zusammenfassung: Was hat funktioniert? Was nicht? Was wird als erstes nachgebessert?
Phase 9: Was tue ich in den ersten 30 Tagen nach dem Launch?
Die ersten 30 Tage entscheiden, ob dein Help Center langfristig funktioniert oder langsam veraltet. Das Muster ist immer gleich: Teams investieren alles in den Launch, atmen durch, und dann passiert drei Monate lang nichts. Damit du nicht in diese Falle tappst, hier der konkrete Plan.
- Woche 1: Review alle "Failed Searches". Schreib mindestens drei fehlende Artikel nach, die häufig gesucht wurden.
- Woche 1: Schau dir alle "nicht hilfreich"-Bewertungen an. Überarbeite die schlechtesten zwei bis drei Artikel sofort.
- Woche 2: Führe ein kurzes Interview mit zwei bis drei Nutzern. Frage: "Was hast du gesucht und nicht gefunden?" Nicht per E-Mail, sondern per Videocall.
- Woche 2: Prüfe die Ticket-Deflection-Rate. Wenn sie unter 30 Prozent liegt, fehlen entweder Inhalte oder die Suchfunktion ist schlecht konfiguriert.
- Woche 3: Schreib alle P2-Artikel, die du vor dem Launch verschoben hast.
- Woche 3: Überprüfe, ob der Widget korrekt kontextsensitiv ausgesteuert wird. Welche Seiten zeigen irrelevante Artikel?
- Woche 4: Erstelle dein erstes monatliches Help-Center-Review: Wie entwickeln sich die fünf Kern-Metriken? Wo gibt es Content-Gaps?
- Woche 4: Plane das nächste Quartal: Welche neuen Features kommen? Welche Artikel müssen vorbereitet werden?
- Tag 30: Stelle einen Vergleich an: Wie hat sich das Ticketvolumen seit Launch entwickelt? Dieser Daten-Snapshot ist dein Business Case für weiteres Investment.
Teams, die HappyAgent einsetzen, bekommen in diesen 30 Tagen automatisch Hinweise auf veraltete Inhalte, sobald sich Code ändert. Statt wöchentliche Review-Meetings zu halten, filtert der GitHub Sync heraus, welche Artikel überprüft werden müssen. Das spart im Schnitt 80 Prozent der Wartungszeit.
Was kostet ein schlechter Start wirklich?
Kurz gerechnet: Wenn dein Team täglich 20 Tickets bearbeitet, die ein gutes Help Center hätte abfangen können, und jedes Ticket 15 Minuten Bearbeitungszeit kostet, verlierst du täglich fünf Stunden Support-Kapazität. Pro Monat sind das über 100 Stunden. Bei einem Support-Gehalt von 45.000 Euro im Jahr entspricht das knapp 2.500 Euro monatlich, die du für Fragen zahlst, die bereits beantwortet sein könnten.
Laut Gartner kostet ein Self-Service-Kontakt im Schnitt 0,10 Euro, während ein Live-Support-Kontakt zwischen 7 und 13 Euro liegt. Ein gut betriebenes Help Center amortisiert sich innerhalb weniger Wochen.
Bereit für den nächsten Schritt?
Wenn du diese Checkliste abgehakt hast, ist dein Help Center bereit für den Go-Live. Aber "bereit" ist nicht dasselbe wie "fertig". Ein Help Center ist kein Projekt, das du abschließt. Es ist eine Infrastruktur, die du betreibst.
Wenn du ein Help Center aufbauen willst, das sich bei Code-Änderungen automatisch aktualisiert und deinen Support langfristig um 30 bis 50 Prozent entlastet, teste HappySupport kostenlos auf happysupport.ai.
Fazit
Die meisten Help Center scheitern nicht am fehlenden Willen. Sie scheitern, weil Teams nicht wissen, was vor dem Launch erledigt sein muss. Diese Checkliste gibt dir das. Neun Phasen, konkrete Aufgaben, klare Reihenfolge.
Fang mit Phase 1 an. Beantworte die drei Strategiefragen, bevor du einen einzigen Artikel schreibst. Plane von Anfang an, wer das Help Center nach dem Launch betreibt. Ein guter Launch dauert zwei bis vier Wochen. Ein gutes Help Center hält Jahre, wenn du die Wartung von Anfang an einplanst.

