Kundendokumentation erstellen: Die vier Ebenen, die jede Übergabe braucht

Drei Wochen nach dem Launch klingelt das Telefon. Der Kunde möchte das Bild auf der Startseite austauschen und weiß nicht mehr, wie das geht. Dabei wurde es in der Schulung gezeigt, und irgendwo in seinem Postfach liegt sogar eine Anleitung.

Diese Situation kennen die meisten Agenturen. Kundendoku entsteht oft als lange E-Mail mit ein paar Screenshots und Erklärungen, geschrieben am Projektende, wenn eigentlich keine Zeit mehr dafür ist. Gespart ist damit nichts. Die Zeit kommt später zurück, nur in anderer Form: als Anruf, als Mail, als „Kannst du mal kurz schauen?“.

Dieser Artikel zeigt, wie du Kundendokumentation erstellst, die tatsächlich genutzt wird. Und warum der wichtigste Hebel dabei nicht das Schreiben ist, sondern der Zeitpunkt.

Warum die meisten Kundendokus nicht funktionieren

Dass Kunden gar keine Dokumentation bekommen, ist selten das Problem. Meistens gibt es eine. Sie wird nur nicht genutzt.

Dabei wollen sich die meisten Menschen durchaus selbst helfen. In einer Auswertung von Zendesk gaben 69 Prozent der Befragten an, so viele Probleme wie möglich selbst lösen zu wollen. Der Wille ist also da. Woran scheitert es dann? Meistens an einem von vier Gründen.

Sie kommt zu spät

Die Doku entsteht am Projektende. Das Budget ist aufgebraucht, die Deadline drückt, und die Details sind längst wieder vergessen. Du rekonstruierst Schritte, die du vor Wochen gemacht hast. Das Ergebnis ist lückenhaft, und genau diese Lücken landen später als Rückfrage bei dir.

Sie steckt im falschen Format

Eine E-Mail mit Screenshots ist schnell geschrieben und genauso schnell verschwunden. Ein PDF ist beim ersten Update veraltet, und niemand weiß mehr, welche Fassung gilt.

Sie erklärt das Falsche

Viele Anleitungen erklären das CMS im Allgemeinen. Das hat der Hersteller aber längst selbst getan, und meistens besser. Dein Kunde braucht etwas anderes: Er will wissen, wie seine Website funktioniert. Welcher Baustein ist für die Teaser auf der Startseite? Wo liegen die Bilder für das Team? Was passiert, wenn er eine Seite verschiebt?

Sie erreicht nicht die, die später kommen

Bei der Übergabe sitzen meist ein, zwei Ansprechpersonen am Tisch. Wer danach dazukommt, war nie dabei: die neue Mitarbeiterin, die Vertretung im Urlaub, die Aushilfe im Weihnachtsgeschäft. Für sie zählt nur, was aufgeschrieben ist, und zwar dort, wo sie es auch finden.

Wie viel Zeit dabei zusammenkommt, zeigt ein Beispiel aus der Praxis: Nach einem Website-Projekt kamen in den ersten Wochen nach dem Launch rund zehn Rückfragen in sechs Mails. Fast jede wurde mit Screenshots oder einer ausführlichen Erklärung beantwortet, im Schnitt etwa 20 Minuten pro Antwort. Zusammen sind das gut drei Stunden für zehn Einzelantworten, die beim Kunden außer dem Empfänger niemand zu sehen bekam. Die Doku ist also trotzdem entstanden, nur nachträglich, Stück für Stück und verteilt über das Postfach.

Das Prinzip: Vier Ebenen statt einer langen Anleitung

Kundendokumentation funktioniert am besten, wenn sie die Fragen deines Kunden in der Reihenfolge beantwortet, in der er sie stellt. Erst will er verstehen, was er da vor sich hat. Dann will er sich zurechtfinden. Dann will er etwas erledigen. Und irgendwann muss er wissen, wo seine Zuständigkeit endet.

Ebene 1: Verstehen

Bevor dein Kunde irgendetwas bearbeitet, braucht er ein Grundverständnis. Nicht der ganzen Software, sondern seiner Website: Wie ist sie aufgebaut? Was wurde individuell für ihn entwickelt? Welche Begriffe tauchen im Backend auf?

Ein kurzes Glossar wirkt hier Wunder. Wenn du im Gespräch von „Ressourcen“, „Templates“ oder „Bausteinen“ sprichst, sollte dein Kunde wissen, was gemeint ist.

Für den Onlineshop der Kaffeerösterei, der auch in den Screenshots dieses Artikels zu sehen ist, heißt das: Eine kurze Seite erklärt, wie Produkte, Kategorien und Varianten zusammenhängen. Wer das einmal verstanden hat, legt ein neues Produkt später ohne Rückfrage an.

Typischer Fehler: direkt mit Anleitungen einsteigen. Ohne Grundverständnis folgt der Kunde Schritten, ohne zu wissen, was sie bewirken.

Ebene 2: Orientieren

Jetzt geht es um die Landkarte: Wie meldet sich dein Kunde an? Wie ist das Backend aufgebaut? Wo liegen Seiten, Bilder, Formulare?

Hier ersetzt ein einziger markierter Screenshot oft eine ganze Seite Text. Ein Überblick über die Oberfläche mit nummerierten Markierungen zeigt in Sekunden, wofür du sonst drei Absätze bräuchtest.

Tipp: Erstelle die Screenshots so, wie dein Kunde das Backend sieht, und nicht mit deinem Admin-Zugang. Welche Menüs und Felder angezeigt werden, hängt oft davon ab, wie ein Benutzerkonto eingerichtet ist. Ein Screenshot aus Admin-Sicht zeigt Dinge, die dein Kunde nie zu sehen bekommt, und verwirrt mehr, als er hilft. Am einfachsten legst du dir dafür ein eigenes Konto an, das genauso eingerichtet ist wie das deines Kunden, idealerweise auf der Testumgebung seiner Website.

Typischer Fehler: jede Ecke des Systems erklären. Dein Kunde braucht nur die Bereiche, die er tatsächlich benutzt.

Ebene 3: Tun

Das ist der Teil, den die meisten unter „Doku“ verstehen: Schritt-für-Schritt-Anleitungen für Kunden. Und hier entscheidet sich, ob sie genutzt werden.

Die wichtigste Regel: Benenne Anleitungen nach dem Ziel deines Kunden, nicht nach der Funktion im System. „Bild auf der Startseite austauschen“ findet er. „Medienverwaltung“ sucht er nicht. Wie wichtig das ist, zeigt auch eine von Yext beauftragte Befragung unter 1.000 Menschen in Deutschland: Als größte Schwierigkeit beim Durchsuchen von Hilfe-Seiten nannten 47 Prozent, dass die Ergebnisse nichts mit ihrer Frage zu tun hatten.

Bewährt hat sich außerdem eine Trennung in zwei Kapitel: Grundlagen, die bei jedem Kunden mit demselben System gleich sind (Seiten anlegen, Bilder austauschen, Formulare prüfen), und Besonderheiten, die nur dieses Projekt hat (eigene Bausteine, spezielle Plugins, individuelle Abläufe). Die Grundlagen sind schnell erstellt, weil sich die Abläufe wiederholen. Trotzdem lohnt es sich, sie im Backend des jeweiligen Kunden aufzunehmen: mit seinen Inhalten und seinem Design statt mit einem allgemeinen Tutorial.

Ein paar Handgriffe, die jede Anleitung besser machen:

• Ein Schritt, ein Bild. Nicht fünf Schritte unter einem Screenshot.
• Etappen statt Endlosliste. Längere Abläufe in Abschnitte mit eigener Zwischenüberschrift teilen, etwa „Produktübersicht öffnen“ und „Produktdaten erfassen“. Das macht die Seite überfliegbar.
• Ausschnitt statt Vollbild. Zeig nur den Bereich, um den es geht.
• Markieren statt umschreiben. Ein Rahmen um den richtigen Button spart einen ganzen Satz.
• Klar anweisen. „Klicke auf Speichern“ statt „Anschließend sollte gespeichert werden“.

Genau an diesem Punkt scheitern die meisten Dokus. Zwanzig Screenshots machen, zuschneiden, in die richtige Reihenfolge bringen, zu jedem Bild einen Satz schreiben: Das kostet Zeit, die in kaum einem Projekt eingeplant ist. Hier setzen Tools an, die aus Screenshots einen ersten Entwurf erzeugen. In Aveela etwa schlägt die KI Reihenfolge und Schritte vor, Prüfung und Korrektur bleiben beim Menschen. Das Nachdenken über den Inhalt bleibt. Das Abtippen fällt weg.

Ebene 4: Grenzen

Die Ebene, die fast immer fehlt. Und genau sie verhindert die teuersten Supportfälle.

Schreib auf, was dein Kunde besser nicht anfasst: Templates, Systemeinstellungen, Plugins. Kläre, wer wofür zuständig ist. Und sag ihm, wann er sich melden soll, bevor aus einer Kleinigkeit ein Notfall wird.

Das ist keine Bevormundung. Im Gegenteil: Klare Grenzen geben deinem Kunden die Sicherheit, alles andere selbst auszuprobieren.

Typischer Fehler: davon ausgehen, dass der Kunde schon merkt, was er nicht anfassen sollte. Meistens merkt er es erst, wenn etwas kaputt ist.

PDF, Wiki oder Portal: Welches Format passt?

Die beste Struktur hilft wenig, wenn die Doku niemand findet. Deshalb lohnt sich ein ehrlicher Blick auf die üblichen Formate:

Das PDF hat durchaus seine Berechtigung, etwa wenn ein Kunde die Doku archivieren oder ausdrucken möchte. Und Wikis sind stark, wenn es um internes Wissen im eigenen Team geht.

Für die Übergabe an Kunden spricht vieles für ein Portal: ein eigener Bereich pro Kunde, im Look des Kunden, per Login oder Link erreichbar. Ändert sich etwas an der Website, wird nur die betroffene Anleitung aktualisiert, und der Kunde sieht sofort die aktuelle Fassung. Kein „Anleitung_final_v3.pdf“ mehr.

Worin sich ein Kundenportal von einem Wiki unterscheidet, zeigt ausführlicher der Vergleich von Aveela und Notion.

Doku von Anfang an mitdenken

Der größte Hebel liegt im Zeitpunkt: Die Doku gehört nicht ans Projektende, sondern ins Projekt.

In der Praxis bewähren sich vier Schritte:

1. Struktur zum Projektstart anlegen. Die vier Ebenen als leere Seiten, bevor die erste Zeile Code geschrieben ist.
2. Screenshots während des Baus sammeln. Wenn ein Bereich fertig ist, ist er noch frisch im Kopf. Genau dann ist der beste Moment.
3. Nach jedem Abschnitt einen Entwurf aufsetzen. Kurz, unfertig, aber vorhanden. Am Ende bleibt nur noch Prüfen und Glätten.
4. Doku ins Angebot schreiben. Als eigene Position. Was nicht im Angebot steht, wird am Ende verschenkt.

„Ich schreibe die Doku nicht mehr am Ende. Nach jedem Projektabschnitt setze ich kurz einen Entwurf aus den Screenshots auf. Wenn die Website live geht, ist die Doku schon da und es fehlt nur noch der Feinschliff.“

Die Zeitersparnis zeigt sich weniger beim Schreiben als danach: weniger Rückfragen, weniger Suchen, weniger Nacharbeit. Eine genaue Stundenzahl für die Doku lässt sich dabei kaum noch benennen, und genau das ist der Punkt: Sie läuft parallel zur Entwicklung mit, in vielen kurzen Einheiten von wenigen Minuten, immer wenn ein Abschnitt fertig ist.

Bei einer überschaubaren CMS-Website fühlt sich das deutlich leichter an als früher allein die Rückfragen. Und am Ende steht eine vollständige Doku, die auch neue Mitarbeitende des Kunden nutzen können, statt zehn verstreuter Antworten im Postfach.

Ein Nebeneffekt: Die Schulung wird kürzer. Statt alles zu erklären, reicht es, die Doku zu zeigen und die wichtigsten Stellen gemeinsam durchzugehen. Den Rest kann der Kunde nachlesen, wann immer er ihn braucht.

Checkliste: Kundendokumentation in vier Ebenen

Verstehen

• Kurzer Überblick über Aufbau und Besonderheiten der Website
• Individuelle Entwicklungen erklärt
• Glossar mit den wichtigsten Begriffen

Orientieren

• Login-Anleitung inklusive „Passwort vergessen“
• Annotierter Überblick über das Backend
• Wo liegen Seiten, Bilder, Formulare?

Tun

• Anleitungen nach Zielen benannt, nicht nach Funktionen
• Die fünf häufigsten Aufgaben abgedeckt
• Ein Schritt, ein Bild, wichtige Stellen markiert

Grenzen

• Tabuzonen klar benannt
• Zuständigkeiten geklärt
• Wann und wie der Kunde sich melden soll

Häufige Fragen