Help Center Launch Checkliste: Was du vor dem Go-Live erledigen musst

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 schließt diese Lücke. Fünf Phasen plus Launch-Tag und die häufigsten Fehler, die Teams vor dem Go-Live machen. Wenn du alle Punkte abgehakt hast, ist dein Help Center bereit. Nicht fertig, aber bereit.

1. Phase 1: Inhalte (welche Artikel müssen vor Launch fertig sein)
2. Phase 2: Technik und Integration (Suche, Mobile, SSO, Chatbot-Verbindung)
3. Phase 3: Design und UX (Navigation, Branding, Feedback-Widget)
4. Phase 4: Analytics und Tracking einrichten
5. Phase 5: Launch und Verbreitung
6. Die 5 häufigsten Launch-Fehler
7. Was nach dem Launch kommt
8. Vollständige Checkliste

Warum ein strukturierter Launch wichtig ist

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?

Teams, die ohne strukturierten Launch-Prozess vorgehen, machen immer denselben Fehler: Sie schreiben Artikel, bauen alles zusammen, und merken erst am Launch-Tag, dass die Suche nicht funktioniert, der Widget nicht eingebunden ist und niemand weiß, wo die Nutzer überhaupt den Link zum Help Center finden sollen. Ein strukturierter Prozess eliminiert das. Laut Salesforce State of Service erwarten 81 Prozent der Kunden Self-Service-Optionen. Aber nur ein Help Center, das technisch funktioniert und inhaltlich aktuell ist, erfüllt diese Erwartung auch.

Wie du ein Help Center von Grund auf aufbaust, erklärt der Step-by-Step-Guide zum Help-Center-Aufbau für SaaS detailliert. Diese Checkliste hier fokussiert auf den Launch selbst.

Phase 1: Inhalte

Die Inhaltsfrage ist die wichtigste vor dem Launch. Nicht jeder Artikel muss fertig sein, aber die richtigen müssen es sein. Teams, die mit 5 Artikeln live gehen, riskieren, dass Nutzer das Help Center besuchen, nichts finden und nie wiederkommen. Teams, die mit 80 Artikeln warten, bis alles perfekt ist, gehen nie live.

Das Minimum für einen sinnvollen Launch: 10 bis 15 P1-Artikel, die die häufigsten Nutzerfragen abdecken. Diese Zahl ist nicht willkürlich. Exportiere deine Top-50-Tickets der letzten drei Monate und sortiere nach Häufigkeit. Die obersten 10 bis 15 Themen sind deine P1-Artikel.

• Welche Tickets kommen täglich rein? Das sind P1.
• Welche Onboarding-Schritte erzeugen die meisten Rückfragen? Das sind P1.
• Was fragen Neukunden in den ersten zwei Wochen? Das sind P1.
• Alles andere ist P2 (erste 30 Tage) oder P3 (langfristig).

Qualitätsstandard vor dem Launch: Jeder P1-Artikel braucht einen klaren Titel (Aufgabe oder Frage), einen Eröffnungssatz der erklärt was der Nutzer danach erreicht hat, und nummerierte Schritte bei Anleitungen. Screenshots sind Pflicht bei jedem Schritt der UI-Interaktion erfordert. Fließtext wird bei technischen Anleitungen nicht gelesen. Nutzer scannen, sie lesen nicht.

Lass jeden Artikel vor dem Launch von jemandem lesen, der das Feature nicht kennt. Wenn diese Person drei Fragen hat, überarbeite den Artikel. Das ist kein aufwendiger Prozess. Es dauert pro Artikel 10 Minuten, aber es spart Dutzende Tickets nach dem Launch.

Schreib eine interne Notiz für jeden Artikel: Wann wird er veralten? (Beispiel: "Aktualisieren bei nächstem UI-Release.") Teams, die HappyRecorder einsetzen, lösen das strukturell: Die Chrome Extension zeichnet UI-Interaktionen direkt als DOM- und CSS-Selektoren auf. Wenn sich das UI ändert, erkennt HappyAgent den Unterschied und markiert den Artikel automatisch zur Überprüfung, statt dass jemand manuell nach veralteten Screenshots suchen muss.

Phase 2: Technik und Integration

Der technische Teil wird systematisch 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.

Suchfunktion:

• 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.
• Stelle sicher, dass neue Artikel innerhalb von Minuten indexiert werden, nicht erst nach Stunden.

Mobile-Optimierung:

• Teste die mobile Ansicht auf iOS und Android. Über 40 Prozent der Help-Center-Zugriffe kommen vom Smartphone. Wirklich klicken, nicht nur ansehen.
• Prüfe Ladezeiten auf mobilem Netz. Ein Help Center, das über drei Sekunden braucht, wird verlassen.
• Stelle sicher, dass die Navigation auf kleinen Bildschirmen funktioniert.

SSO und Zugangsbeschränkungen:

• Richte SSO oder Zugangsbeschränkungen ein, wenn du Inhalte nur für eingeloggte Nutzer zeigen willst.
• Prüfe, ob Nicht-Kunden nur das sehen, was sie sehen sollen.
• Teste den Login-Flow für neue Nutzer, die noch kein Konto haben.

Chatbot-Verbindung:

• Konfiguriere den GitHub Sync, wenn du HappyAgent nutzt: Welche Repositories werden überwacht?
• Verbinde dein Help Center mit dem KI-Chatbot. Wie gut der Chatbot antwortet, hängt direkt von der Qualität deiner Wissensbasis ab. Wie veraltete Dokumentation zu falschen Chatbot-Antworten führt, erklärt der Artikel zu KI-Chatbot falsche Antworten Wissensbasis.
• Teste alle Integrationen: Ticketsystem, Chat-Tool, CRM. Nichts ist frustrierender als ein "Kontakt aufnehmen"-Button, der ins Leere führt.

Phase 3: Design und UX

Design bedeutet hier nicht Ästhetik. Es bedeutet, dass Nutzer finden, was sie suchen. Das ist die eigentliche UX-Aufgabe eines Help Centers: Orientierung, nicht Unterhaltung.

Navigation:

• Begrenze dich auf maximal sieben Hauptkategorien. Mehr verwirrt.
• Sortiere Kategorien nach Nutzungshäufigkeit, nicht nach interner Logik. Was die meisten Nutzer suchen, steht oben.
• Schreib für jede Kategorie eine kurze Beschreibung (ein bis zwei Sätze), was dort zu finden ist.
• Stelle sicher, dass die Suchleiste sofort sichtbar ist, sowohl auf Desktop als auch auf Mobile.

Branding:

• Nutze die Farben, Schriften und den Tonfall deines Produkts. Das Help Center ist kein separates Produkt, es ist Teil deines Produkts.
• Vermeide generisches "Knowledge Base"-Branding. Nenn es, wie deine Nutzer es nennen würden.

Feedback-Widget:

• Binde ein Feedback-Widget in jeden Artikel ein (hilfreich / nicht hilfreich). Zwei Klicks, wertvolle Daten.
• Ergänze ein offenes Textfeld für "Was fehlte dir in diesem Artikel?". Diese Antworten sind deine Content-Gap-Liste.
• Zeige einen "Kontakt aufnehmen"-Link am Ende jedes Artikels, damit Nutzer, die keine Antwort finden, direkt eskalieren können.

HappyWidget-Einbindung:

• Binde den Widget in dein Produkt ein. Kontextsensitiv ist besser als generisch: Der Widget auf der Seite "Integrationen" sollte Integrations-Artikel zeigen, nicht die Help-Center-Startseite.
• Teste den Widget im Produkt: Öffnet er sich? Zeigt er relevante Inhalte? Funktioniert der Eskalations-Link?

Phase 4: Analytics und Tracking einrichten

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.

Folgende Metriken musst du vor dem Launch einrichten:

• Sucherfolgsrate: Anteil der Suchen, die zu einem Klick auf einen Artikel führen. Ziel: über 70 Prozent. Alles darunter bedeutet, die Suche findet nicht das Richtige.
• Failed Searches: Welche Begriffe liefern keine Ergebnisse? Das ist deine Content-Gap-Liste für die ersten 30 Tage nach Launch.
• Ticket-Deflection: Wie viele Nutzer haben das Help Center besucht und danach kein Ticket erstellt? Das ist die Kennzahl für deinen ROI.
• Artikel-Bewertungen: Wie viele "hilfreich" vs. "nicht hilfreich" pro Artikel. Artikel unter 50 Prozent positiv müssen überarbeitet werden.

Eine Metrik wird häufig vergessen: die "No-Answer"-Rate des Chatbots. Wenn dein KI-Chatbot verbunden ist, zeigt die Rate der ungelösten Chatbot-Anfragen direkt, wo Wissenslücken in deiner Dokumentation liegen. Diese Metrik ist wertvoller als reine Pageview-Zahlen, weil sie absichtliche Nutzungsversuche misst.

Verbinde dein Help Center mit deinem Ticketsystem: Welche Tickets kommen trotz existierendem Artikel rein? Das zeigt dir, welche Artikel Nutzer nicht finden oder nicht verstehen. Oft ist das kein Inhaltsproblem, sondern ein Suchproblem: Der Artikel existiert, aber die Nutzer finden ihn nicht, weil er anders betitelt ist als die Begriffe, die sie eingeben.

Richte ein wöchentliches Dashboard ein, das diese Metriken zusammenfasst. Kein Dashboard bedeutet kein regelmäßiges Review. Und kein regelmäßiges Review bedeutet ein Help Center, das drei Monate nach Launch niemand mehr pflegt.

Phase 5: Launch und Verbreitung

Ein Help Center, das niemand findet, existiert nicht. Verbreitung ist keine Nacharbeit. Sie ist Teil des Launch-Prozesses. Diese Kanäle musst du am Launch-Tag oder in der ersten Woche aktivieren:

• In-App-Link: Der Help-Center-Link gehört in die App-Navigation. Nicht versteckt in den Einstellungen, sondern dort, wo Nutzer ihn suchen, wenn sie stecken. Typisch: oben rechts als Fragezeichen-Icon.
• Footer: Website-Footer und App-Footer mit direktem Link.
• Onboarding-Sequenz: Erwähne das Help Center in der ersten Onboarding-E-Mail. Viele Teams vergessen das. Der Moment, in dem ein neuer Nutzer anfängt, ist genau der richtige Zeitpunkt.
• Ticketsystem: Richte automatische Artikel-Vorschläge ein, die bei neuen Tickets relevante Help-Center-Artikel zeigen. Das erhöht die Deflection, bevor ein Agent antwortet.
• Support-Signatur: Füge einen Link zum Help Center in die E-Mail-Signatur deines Support-Teams ein.
• Chatbot-Fallback: Wenn der Chatbot keine Antwort findet, soll er direkt zum relevanten Help-Center-Artikel verlinken, nicht nur "Ich weiß es nicht" sagen.

Informiere dein Support-Team eine Stunde vor dem Go-Live. Sie müssen wissen, dass das Help Center existiert und wie es funktioniert, bevor Nutzer ihnen Fragen dazu stellen. Und sie müssen wissen, wie sie Nutzer dorthin navigieren können, wenn jemand per Ticket fragt. "Hier ist der Link zu unserem Help Center, der Artikel dazu ist ..." spart beiden Seiten Zeit.

Wähle den Launch-Zeitpunkt mit Bedacht. Kein Freitagabend. Kein Montag während des Sprint-Startups. Idealerweise Dienstag oder Mittwoch vormittags, wenn das Team vollständig da ist und auf erstes Feedback reagieren kann.

Die 5 häufigsten Launch-Fehler

Diese Fehler sehen wir bei Teams, die ein Help Center launchen, ohne strukturierten Prozess. Alle fünf sind vermeidbar.

Fehler 1: Zu wenig Inhalt am Go-Live. Teams gehen mit 4 Artikeln live, weil "der Rest kommt noch". Nutzer kommen, finden nichts, und kommen nie wieder. Minimum sind 10 bis 15 P1-Artikel vor dem Launch.

Fehler 2: Suche nicht getestet. Die Suche wurde eingerichtet, aber nie mit echten Nutzerbegriffen getestet. Nutzer suchen nach "passwort vergessen", der Artikel heißt "Zugangsdaten zurücksetzen". Kein Treffer. Teste vor dem Launch mit 20 realen Suchbegriffen aus deinen Tickets.

Fehler 3: Kein Widget im Produkt. Das Help Center existiert, aber der Weg dorthin aus dem Produkt ist versteckt. Nutzer, die im Produkt stecken, schreiben ein Ticket, statt ins Help Center zu schauen, weil der Link drei Klicks entfernt ist. Der kontextuelle Widget löst das: Er zeigt die richtigen Artikel direkt dort, wo der Nutzer gerade arbeitet, ohne dass er erst zur Help-Center-Startseite navigieren muss.

Fehler 4: Kein Wartungsplan. Das ist der häufigste Fehler. Das Help Center wird gebaut, gelauncht, und dann passiert drei Monate lang nichts. Artikel veralten, Nutzer finden falsche Anweisungen, das Vertrauen sinkt. Plane von Anfang an, wer welche Kategorie betreut und in welchem Rhythmus. Wie du die Dokumentation dauerhaft aktuell hältst, erklärt der Artikel zu Help Center aktuell halten.

Fehler 5: Analytics nicht eingerichtet. Teams launchen ohne Tracking und wissen nach drei Monaten nicht, ob das Help Center funktioniert. Ohne Daten keine Verbesserung. Richte die vier Kern-Metriken vor dem Launch ein, nicht danach. Besonders kritisch: das Failed-Search-Tracking. Ohne dieses weißt du nicht, was Nutzer suchen und nicht finden. Das ist die wertvollste Datenquelle für Content-Entscheidungen in den ersten 60 Tagen.

Was nach dem Launch kommt

Der Launch ist kein Abschluss. Er ist der Start des Betriebs. Die ersten 30 Tage entscheiden, ob dein Help Center langfristig funktioniert oder langsam veraltet.

Woche 1 nach Launch:

• Review alle "Failed Searches". Schreib mindestens drei fehlende Artikel nach, die häufig gesucht wurden.
• Überarbeite die schlechtesten zwei bis drei Artikel nach Bewertungen sofort.
• Prüfe, ob der Widget korrekt kontextsensitiv ausgesteuert wird.

Woche 2 bis 4:

• Führe ein kurzes Interview mit zwei bis drei Nutzern: "Was hast du gesucht und nicht gefunden?" Nicht per E-Mail, per Videocall.
• Prüfe die Ticket-Deflection-Rate. Liegt sie unter 30 Prozent, fehlen entweder Inhalte oder die Suche ist schlecht konfiguriert.
• Schreib alle P2-Artikel, die du vor dem Launch verschoben hast.
• Erstelle das erste monatliche Help-Center-Review: Wie entwickeln sich die Kern-Metriken?

Tag 30: Stelle einen Vergleich an, wie sich das Ticketvolumen seit Launch entwickelt hat. Dieser Daten-Snapshot ist dein Business Case für weiteres Investment in das Help Center. Wenn die Deflection-Rate unter 20 Prozent liegt, ist das kein schlechtes Help Center. Es ist ein Signal, dass entweder zu wenig Inhalt da ist oder die Nutzer das Help Center noch nicht als ersten Anlaufpunkt nutzen. Beides ist behebbar.

Ein typisches Muster: In Woche 1 und 2 nach Launch steigt das Ticket-Volumen leicht, weil Nutzer das neue Help Center testen, die Artikel bewerten und Lücken melden. Das ist kein schlechtes Zeichen. Ab Woche 3 beginnt die Deflection-Rate zu steigen, wenn die ersten Feedback-Schleifen abgeschlossen sind. Ab Monat 2 zeigen sich die echten Zahlen.

Teams, die HappyAgent einsetzen, bekommen ab dem ersten Tag automatisch Hinweise auf veraltete Inhalte, sobald sich Code ändert. Statt wöchentliche Review-Meetings zu halten, filtert der GitHub Sync heraus, welche Artikel geprüft werden müssen. Das reduziert den Wartungsaufwand um bis zu 80 Prozent.

Wie du dein Help Center auf Ticket-Deflection optimierst, erklärt der Artikel zu Support-Tickets reduzieren mit dem Help Center.

Vollständige Launch-Checkliste

Benutze diese Tabelle als konkretes Arbeitsblatt. Jeder Punkt hat eine klare Kategorie und kann direkt abgehakt werden.

Was kostet ein schlechter Launch 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. Laut SuperOffice Customer Service Benchmark Report kostet ein Live-Support-Kontakt zwischen 7 und 13 Euro, während ein Self-Service-Kontakt bei unter einem Euro liegt. Ein gut betriebenes Help Center amortisiert sich innerhalb weniger Wochen.

Der zweite Kostenfaktor ist schwerer zu messen: Vertrauen. Wenn ein Nutzer dreimal das Help Center besucht, nichts findet oder falsche Anweisungen bekommt, stellt er beim vierten Mal gar keine Suche mehr an. Er schreibt direkt ein Ticket. Ein schlecht gestartetes Help Center erhöht das Ticket-Volumen langfristig, weil Nutzer aufgehört haben, selbst zu suchen. Das ist schwerer zu reparieren als ein fehlender Artikel beim Launch.

Ein strukturierter Launch verhindert beide Kostenquellen. Diese Checkliste gibt dir den Rahmen. Was sie nicht ersetzt: den Wartungsplan. Denn die teuerste Phase ist nicht der Launch, sondern die sechs Monate danach, wenn niemand die Artikel aktualisiert und der erste Chatbot mit veralteten Informationen einen Kunden falsch berät.