Bei den meisten SaaS-Unternehmen ist das Help Center ein Friedhof guter Vorsätze. Jemand hat es in der Onboarding-Woche aufgesetzt. Jemand anderes hat zwei Monate lang Artikel ergänzt. Dann shipte das Produkt schneller als die Doku, und es wurde still um die ganze Sache.
Die Rechnung ist brutal. Wenn ein Screenshot-Update acht Minuten dauert und dein Produkt pro Quartal 30 UI-Änderungen ausliefert, ist das eine Personenwoche pro Jahr nur für Screenshots. Die meisten Teams geben auf. Doku veraltet, Tickets stapeln sich, und das Help Center wird zum Ort, den Kunden lernen zu ignorieren.
Wir haben HappySupport gebaut, weil wir glauben, dass das lösbar ist. Nicht mit Willenskraft (mehr Doku-Disziplin) und nicht mit Templates (jemand muss sie trotzdem pflegen). Mit Infrastruktur. Ein Help Center, das seine Nutzer findet, sich aus der Arbeit füllt, die dein Team ohnehin schon leistet, und sich aktualisiert, wenn sich das UI ändert.
HappySupport 2.0 erscheint Anfang Juni. Es ist das größte Release in unserer Geschichte. Es ist die erste Version, in der alle drei Versprechen gleichzeitig halten.
Was wir lösen wollten
Drei Probleme tauchen bei jedem SaaS-Team auf, mit dem wir gesprochen haben.
Das erste ist Verfall. Auch wenn Teams Artikel schreiben, bleiben diese Artikel nicht aktuell. Screenshots veralten innerhalb eines Sprints. Workflows ändern sich. Der Artikel, der das Problem eines Nutzers im Januar gelöst hat, verwirrt ihn im April. Die Werkzeuge zum Schreiben sind sehr gut geworden. Die Lücke bei der Pflege ist schlimmer geworden.
Das zweite ist der Kaltstart. Ein Help Center von null aufzusetzen bedeutete bisher, 50 Artikel vor dem Launch zu schreiben, alles Step-by-Step-Guides. Niemand will 50 Step-by-Step-Guides schreiben. Teams starten mit 12, verlieren Schwung und werden nie fertig.
Das dritte ist Sichtbarkeit. Die meisten Help Center liegen unter /help auf einer Domain, die für alles rankt außer Hilfe-Inhalten. Seiten rendern über JavaScript, was bedeutet, dass Google sie langsam sieht und AI-Crawler sie gar nicht sehen. Kunden, die ihre Frage in ChatGPT oder Perplexity suchen, bekommen Antworten zu deinen Wettbewerbern, nicht zu dir.
Wenn dein Help Center zwei dieser drei Probleme hat, hast du kein Help Center. Du hast eine Verbindlichkeit mit Navigationsleiste.
Warum HappySupport existiert
Hier ist die Wette, die wir eingegangen sind. Das Help Center ist kein Dokumentations-Tool. Es ist ein Aktivierungs-Tool. Derselbe Inhalt, der einem Kunden an Tag 90 hilft, ein Problem zu lösen, hilft ihm auch an Tag 1, das Produkt zu verstehen. Wenn es für beides funktioniert, zahlt es sich um ein Vielfaches aus.
Das funktioniert nur, wenn drei Dinge gleichzeitig wahr sind.
- Der Inhalt muss aktuell bleiben, ohne manuelle Arbeit. Wenn dein Team ihn babysitten muss, wird es das nicht tun.
- Das Setup muss schnell sein. Wenn das Befüllen des Help Centers ein Quartal dauert, macht es niemand.
- Der Inhalt muss auffindbar sein. Nicht nur in der App, sondern auch auf Google und in den KI-Tools, die Kunden ohnehin nutzen.
HappySupport 2.0 ist die erste Version, in der wir alle drei laut aussprechen können und es ernst meinen. Das Release ist um diese drei Säulen herum organisiert, und wir fangen mit der an, auf die wir am stolzesten sind.
Säule 1. Immer aktuell
Das ist der Teil, den so noch niemand auf dem Markt in dieser Tiefe hat.
Das Hand-Off-Feature aktualisiert deine Dokumentation über eine GitHub-Repo-Verbindung. Sobald du dein Repository verbindest, beobachtet HappySupport die Änderungen, die ausgeliefert werden. Nach jedem Release sagt es dir, welche Artikel erstellt, aktualisiert oder entfernt werden müssen, basierend darauf, was sich im Code tatsächlich verändert hat. Es funktioniert über mehrere Repos und mehrere Branches gleichzeitig. Dein Monorepo bringt es nicht aus dem Tritt.
Das automatische Screenshot-Update (aktuell in der Beta) ist die andere Hälfte von Immer aktuell. So funktioniert es: Wenn du einen Artikel mit unserem Recorder aufnimmst, erfasst HappySupport die zugrunde liegenden Bildschirme, die Klick-Sequenz und die Screenshots, die zu jedem Schritt passen. Wenn du später UI-Änderungen shippst, öffnest du den betroffenen Artikel und klickst auf den Button Screenshot Update. Ein Browser-Agent öffnet deine Anwendung, läuft denselben Pfad ab wie deine ursprüngliche Aufnahme, schaut sich das neue UI an und aktualisiert jeden Screenshot in jedem betroffenen Guide automatisch. Du nimmst nichts neu auf. Die Aufnahme bleibt gleich. Nur die visuellen Inhalte werden aktualisiert.
Wenn du jemals einen Screenshot über 40 Artikel hinweg von Hand aktualisiert hast, weißt du, was sich damit verändert.
Säule 2. Von null zu gefüllt in Tagen statt Monaten
Wir haben das Artikel-System komplett neu gebaut. Es gibt jetzt sechs Artikel-Typen, jeder für eine andere Art von Frage gemacht.
- Step-by-Step-Guides erfassen einen Workflow über mehrere Bildschirme. Über den Recorder gebaut, Klick für Klick.
- UI-Overview-Artikel erklären, was auf einer einzelnen Seite zu sehen ist und was jede Funktion macht. Auch über den Recorder, aber als beschreibender Walkthrough statt als Klick-Sequenz.
- FAQ-Artikel beantworten eine einzelne Frage. KI-gedrafted aus deinem Kontext: Doku, Transkripte, Support-Tickets.
- Reference-Artikel decken technische Details und Copy-Paste-Snippets ab. KI-gedrafted, leicht poliert.
- Knowledge-Artikel erklären ein Konzept, das der Nutzer verstehen muss, um seine Arbeit zu machen. KI-gedrafted.
- Best-Practice-Artikel zeigen Nutzern nicht nur, wie sie etwas machen, sondern wie sie es gut machen. KI-gedrafted.
Artikel können immer auch manuell erstellt werden. Der Unterschied ist, was passiert, wenn du Kontext verbunden hast. Wenn du Kontext-Dokumente hochgeladen oder ein GitHub-Repository verbunden hast, drafted HappySupport die erste Version eines Artikels automatisch für dich. Der Artikel-Typ, den du wählst, bestimmt die Form des Drafts. Dein Team bearbeitet ab einem Startpunkt, statt von null zu schreiben.
Der Punkt, Artikel in Typen aufzuteilen, ist nicht Kategorisierung. Es ist, dass jeder Typ eine andere Form, Länge und Tonalität hat. Ein Reference-Artikel liest sich nichts wie ein Step-by-Step-Guide. Wenn du den richtigen Typ wählst, füllt die KI ihn beim ersten Mal korrekt.
Artikel-Gruppen lassen dich verwandte Artikel auf einer einzigen Landing-Page zusammenfassen, die Kunden sehen. Ordner haben Icons und Beschreibungen. Drafts und veröffentlichte Zustände sind explizit, mit einer Seitenleiste, die widerspiegelt, was wo ist. Quick Search im Editor findet jeden Artikel oder jede Einstellung in zwei Tastenanschlägen.
Säule 3. Sichtbar ab Tag eins
Help Center leben jetzt auf einer eigenen Subdomain unter {dein-name}.happysupport.help. Custom Domains funktionieren weiterhin. URLs verwenden Slugs statt Artikel-IDs, sodass der Link zu deinem Artikel "Setting up SSO" in der Adressleiste tatsächlich setting-up-sso heißt.
Die Seiten rendern Server-seitig. Wenn Google oder ein KI-Crawler sie aufruft, ist der Inhalt schon da. Bilder laden als Fallback, falls JavaScript ausfällt. Der ganze Stack ist für Indexierung gebaut, nicht primär für eine Single-Page-App.
Was damit ausgeliefert wird:
- Sitemap.xml wird automatisch erzeugt
- robots.txt auf KI-Crawler abgestimmt (die neue Generation liest sie anders als Google)
- Schema.org strukturierte Daten auf jedem Artikel
- Open Graph Bilder für saubere Vorschauen, wenn Artikel geteilt werden
- RSS-Feed für alle, die deinen Updates folgen wollen
Es gibt außerdem eine verbesserte Version unseres KI-Such-Widgets direkt im Help Center. Kunden stellen eine Frage, das Widget antwortet mit Verweisen zurück zu den Quell-Artikeln. Die meisten Nutzer hören auf, durch Artikel-Listen zu scrollen, und fangen an zu fragen. Deine Support-Last verschiebt sich, bevor du irgendetwas anderes tust.
Eine Empfehlung, die zehn Minuten kostet und sich über Jahre auszahlt: Verlinke dein Help Center aus dem Footer oder der Hauptnavigation deiner Marketing-Seite. Crawler finden es schneller, und das SEO baut sich Monat für Monat auf.
Ein paar kleinere Dinge, die Erwähnung verdienen
Quick Search ist von überall in der App in zwei Tastenanschlägen verfügbar und findet Artikel, Einstellungen, Help-Center-Seiten und Aktionen wie das Erstellen eines neuen Artikels. Es verändert, wie du dich in HappySupport bewegst.
Die Settings-UI wurde neu gebaut. Ordner-Icons, Glossar, Customisation und Übersetzungen leben jetzt unter den Help-Center-Einstellungen, wo sie hingehören. Jedes Help Center hat sein eigenes Glossar (das globale gibt es weiter), und Glossar-Begriffe werden als Kontext genutzt, wenn die KI Artikel draftet.
Das Dashboard ist neu. Es zeigt die Zahlen, die zählen: veröffentlichte versus Draft-Artikel, top-performende Seiten, Suchanfragen ohne gute Antwort.
Analytics hat eine eigene Seite, mit Content-Performance über die Zeit.
Die Chrome-Erweiterung unterstützt jetzt die Help-Center-Auswahl direkt im Browser. Wenn du mehrere Produkte verwaltest, musst du nicht den Kontext wechseln. Artikel landen automatisch im richtigen Ordner.
Ein neuer Player für beschreibende Guides liefert flüssigere Drag-and-Drop-Animationen und bessere Step-Übergänge.
Was wir als Nächstes bauen
Wir sind nicht fertig. Die nächsten sechs Wochen konzentrieren sich auf vier Bereiche gleichzeitig, und jeder baut auf der Arbeit auf, die gerade ausgeliefert wurde.
Erstens, eine noch bessere Help-Center-UI. Kunden, die mit einer Frage kommen, sollen sich wohlfühlen und mehr als nur eine Antwort finden. Dieselbe Oberfläche beantwortet Fragen zu deinem Changelog, deinen Release Notes und dem aktuellen Status deiner App. Das Help Center wird zum einen Ort, an dem Kunden nachsehen, wenn etwas unklar, fehlend oder kaputt aussieht.
Zweitens, ein einfacher Weg, deinen Kundenservice zu kontaktieren, wenn Self-Service nicht reicht. Das Help Center erledigt die einfachen Antworten. Wenn eine echte Konversation nötig ist, soll der Weg zu deinem Team aus jedem Artikel heraus einen Klick entfernt sein.
Drittens, und das ist der Große, das In-App-Widget. Help-Center-Wissen direkt in deine Anwendung gebracht, im Kontext gezeigt. Der richtige Artikel erscheint zum richtigen Moment, basierend darauf, was der Nutzer gerade tut und wie lange er an einer Stelle hängt. Kein Hin- und Herspringen zwischen Tabs.
Viertens, In-App-Touren und In-App-Guidance auf Basis deiner Live-Dokumentation. Onboarding-Flows und Feature-Einführungen, die sich selbst aktualisieren, wenn sich dein Produkt ändert, weil sie aus demselben Inhalt gespeist werden, der auch dein Help Center antreibt.
Du bekommst vier Erfolge mit einer Investition. Dein Help Center, dein Changelog, deine Status-Seite, dein Kontakt-Kanal, dein In-App-Onboarding und deine Feature-Guidance laufen alle auf demselben Inhalt. Aktualisiere einen Artikel, und jede Oberfläche spiegelt es wider. Mehrere Fliegen, eine Klappe.
Sechs Wochen hinter uns, sechs Wochen vor uns
Alles in diesem Release ist in den letzten sechs Wochen Arbeit zusammengekommen, ausgeliefert Anfang Juni. Die nächsten sechs Wochen werden gleich aussehen: Kopf runter, bauen. Die vier Bereiche oben sind der Arbeitsplan.
