Lesedauer: ca. 7 Minuten
|
Was du aus diesem Artikel mitnimmst: • Warum fehlende Dokumentation das unsichtbarste Skalierungsproblem im Support ist • Welche drei Typen von Doku wirklich zählen und welche du ignorieren kannst • Ein einfaches Framework, mit dem du heute anfangen kannst, ohne ein riesiges Projekt daraus zu machen • Konkrete erste Schritte für Teams jeder Größe |
In fast jedem Start-up, mit dem ich arbeite, läuft es irgendwann auf dasselbe Gespräch hinaus. Das Team wächst, die Ticketzahlen steigen, und plötzlich stellt jemand fest: Wir haben eigentlich keine einheitliche Antwort auf diese Frage. Jeder löst das irgendwie. Aber niemand weiß, wie die anderen es lösen.
Das ist kein Kommunikationsproblem. Das ist ein Dokumentationsproblem. Und es fängt viel früher an, als die meisten denken.
Das Problem, das keiner sieht, bis es zu spät ist
Fehlende Support-Dokumentation fühlt sich lange nicht wie ein Problem an. Am Anfang kennt jeder im Team das Produkt. Eskalationen klären sich durch kurze Slack-Nachrichten. Der erste Agent fragt einfach den Gründer. Das funktioniert.
Bis es nicht mehr funktioniert.
Der Moment kommt meistens nicht mit einem großen Knall. Er kommt mit einem neuen Agenten, der dieselbe Frage dreimal anders beantwortet. Mit einem Kunden, der sich beschwert, weil er letzte Woche eine andere Auskunft bekommen hat. Mit einem Team Lead, der merkt, dass seine Leute alle unterschiedliche Workarounds nutzen, und niemand weiß, welcher der richtige ist.
Laut dem Digital Customer Excellence Report 2024 geben über 60 Prozent der Support-Teams an, dass inkonsistente interne Wissensbasis einer der Hauptgründe für sinkende Erstlösungsraten ist. Der Salesforce State of the Connected Customer zeigt zudem, dass Kunden Konsistenz über alle Kanäle hinweg als wichtigsten Qualitätsindikator bewerten, noch vor Reaktionsgeschwindigkeit.
Das Skalierungsproblem entsteht nicht, wenn die Doku fehlt. Es entsteht schon viel früher, nämlich wenn die Entscheidung getroffen wird: Wir brauchen das jetzt noch nicht.
Der häufigste Denkfehler: Dokumentation ist ein Projekt
Ich sehe in meiner Arbeit mit Teams regelmäßig, wie Gründer das Thema angehen. Entweder gar nicht, weil gerade andere Prioritäten gelten. Oder zu groß, weil der Plan ist, irgendwann ein vollständiges internes Wiki aufzubauen.
Beides ist falsch. Dokumentation ist kein Projekt. Es ist eine Gewohnheit.
Der Unterschied ist entscheidend. Wer wartet, bis es ein richtiges Projekt wird, wartet zu lange. Und wer versucht, alles auf einmal zu dokumentieren, scheitert meistens an der eigenen Ambition. Das Wiki bleibt halbfertig. Die Agenten nutzen es nicht, weil es veraltet wirkt. Die Energie verpufft.
Was stattdessen funktioniert, habe ich in Projekten aus dem CX-Magazin 2025-Umfeld immer wieder beobachtet: kleine, konsistente Schritte, eingebettet in den normalen Support-Alltag.
Drei Typen von Dokumentation, die wirklich zählen
Nicht jede Form von Dokumentation bringt denselben Wert. Aus der Praxis haben sich drei Typen herauskristallisiert, die den Unterschied machen.
1. Produkt-Wissen
Was sind die häufigsten Fragen? Welche Fehler tauchen regelmäßig auf? Welche Workarounds existieren für bekannte Bugs? Das ist die Basis. Ohne sie beantwortet jeder Agent diese Fragen anders.
Diese Doku gehört nicht in ein separates Tool. Sie gehört dorthin, wo die Antworten entstehen, also direkt in das Ticketsystem oder in ein verlinktes, strukturiertes Dokument, das jeder in 30 Sekunden findet.
2. Prozess-Wissen
Wer entscheidet was? Wie läuft eine Eskalation ab? Was passiert, wenn ein Kunde droht abzuwandern? Welche SLAs gelten für welche Ticketkategorie?
Das klingt nach Overhead. In Wirklichkeit ist es das, was einen Agenten souverän macht. Wer weiß, wie er entscheiden darf, fragt weniger nach. Und stellt zufriedenere Kunden.
Laut der PwC Service Studie 2023 wünschen sich 71 Prozent der Kunden, dass Support-Mitarbeitende eigenständig Entscheidungen treffen können, ohne Rücksprache halten zu müssen. Das geht nur, wenn die Entscheidungswege klar dokumentiert sind.
3. Ton & Haltung
Das wird am häufigsten vergessen. Nicht weil es unwichtig wäre, sondern weil es schwerer zu greifen ist.
Wie klingt euer Support? Was ist erlaubt, was nicht? Gibt es Formulierungen, die ihr nie verwenden würdet? Gibt es Beispiele für besonders gute Antworten aus der Vergangenheit?
Gerade in Start-ups, die schnell wachsen und Menschen aus unterschiedlichen Hintergründen einstellen, ist Ton-Dokumentation das, was aus einem Support-Team eine Marke macht.
Zwei Wege und ihre Trade-offs
Option A: Bottom-up dokumentieren
Jeder Agent hält fest, was er gelernt hat. Neue Lösungen, neue Erkenntnisse, neue Workarounds werden direkt nach dem Ticket dokumentiert. Ein einfaches Template, ein fester Platz, keine langen Abstimmungen.
Vorteil: Nah an der Realität. Aktuell. Wenig Overhead.
Nachteil: Ohne Qualitätskontrolle entsteht schnell ein unstrukturiertes Sammelsurium. Jemand muss regelmäßig sichten.
Option B: Top-down aufbauen
Eine Person, oft der Team Lead oder eine erfahrene Agentin, setzt die Struktur. Definiert Kategorien, erstellt die ersten Templates, gibt den Rahmen vor.
Vorteil: Konsistenter. Leichter zu navigieren. Skaliert gut.
Nachteil: Zeitaufwendiger am Anfang. Wenn die verantwortliche Person das Team verlässt, bricht das System oft zusammen.
Die ehrliche Empfehlung: Fang mit Bottom-up an, aber bau Top-down-Strukturen ein, sobald du mehr als zwei Agenten hast. Hybrid ist in diesem Fall kein Kompromiss, sondern die richtige Entscheidung.
Das Minimal-Framework für den Start
Kein perfektes Wiki. Kein monatelanges Projekt. Nur vier Dokumente, die du heute anlegen kannst.
|
Bereich |
Was dokumentieren? |
Wann? |
|
Produkt |
FAQs, bekannte Fehler, Workarounds |
Ab Tag 1 |
|
Prozess |
Eskalationswege, SLAs, Zuständigkeiten |
Ab erstem Agenten |
|
Tone & Voice |
Beispiele guter/schlechter Antworten |
Ab Teamgröße 2+ |
|
Tools |
Ticketsystem-Workflows, Makros, Tags |
Bei Tool-Einführung |
Das sind keine Geheimwaffen. Das ist das Minimum, das jedes Support-Team braucht, unabhängig von Größe, Branche oder Ticketvolumen. Was sich ändert, ist Tiefe und Pflege. Nicht die Struktur.
Was das in der Praxis bedeutet
Ein Start-up im B2C-Bereich, mit dem ich gearbeitet habe, hatte nach 18 Monaten ein Team von acht Agenten, ein Ticketsystem mit über 300 aktiven Makros und keine einzige dokumentierte Eskalationsregel. Jeder hatte seine eigene Vorstellung davon, wann ein Ticket zum Team Lead geht.
Wir haben in zwei halben Tagen eine einfache Prozess-Doku aufgebaut. Kein neues Tool, keine große Initiative. Nur klare Entscheidungswege, in einem gemeinsamen Dokument, verlinkt direkt im Ticketsystem.
Vier Wochen später war die durchschnittliche Bearbeitungszeit pro Ticket um 18 Prozent gesunken. Nicht wegen eines besseren Tools. Sondern weil die Agenten aufgehört hatten, bei jeder unsicheren Situation nachzufragen.
Die Signale, dass es Zeit wird
Du brauchst keine großen Analysen, um zu merken, dass deine Dokumentation ein Problem ist. Es gibt klare Warnsignale.
• Neue Agenten brauchen länger als vier Wochen, um eigenständig zu arbeiten.
• Dieselbe Frage landet mehrfach beim Team Lead oder direkt beim Gründer.
• CSAT-Werte variieren stark zwischen einzelnen Agenten, obwohl alle ähnliche Tickets bearbeiten.
• Bei Produktupdates fragen sich die Agenten selbst, was sich geändert hat.
• Wenn jemand das Team verlässt, geht Wissen mit.
Wenn mehr als zwei dieser Punkte auf dich zutreffen, ist es nicht zu früh. Es ist genau der richtige Zeitpunkt.
Konkrete erste Schritte
• Diese Woche: Legt ein zentrales Dokument an. Keine perfekte Struktur nötig. Vier Tabs: Produkt-FAQ, Prozesse, Ton-Beispiele, Tools. Und schreibt die drei häufigsten Fragen der letzten Woche rein.
• In zwei Wochen: Stellt in einem kurzen Meeting die Frage: Welche Situation hat euch letzte Woche Energie gekostet, weil ihr nicht sicher wart, wie ihr entscheiden sollt? Die Antworten sind eure nächsten Dokumentations-Prioritäten.
• In vier Wochen: Baut Dokumentation in den Onboarding-Prozess ein. Nicht als Extra, sondern als festen Teil. Neue Agenten lernen nicht nur das Produkt, sie lernen auch, wie Wissen bei euch gespeichert wird.
• Laufend: Macht Dokumentation zur Aufgabe, nicht zur Selbstverständlichkeit. Wer eine neue Lösung findet, hält sie fest. Wer ein veraltetes Dokument bemerkt, aktualisiert es. Zwei Minuten, direkt nach dem Ticket.
Die wichtigste Erkenntnis
Support-Dokumentation ist keine Bürokratie. Es ist das Fundament, auf dem skalierender Support erst möglich wird.
Teams, die früh anfangen, bauen einen Vorsprung auf, der sich nicht mehr aufholen lässt. Nicht im Sinne von Wettbewerb, sondern im Sinne von Struktur. Wer in Phase zwei dokumentiert, was in Phase eins entstanden ist, macht ein dreifach so großes Projekt daraus.
Laut Scale-up your Customer Care und dem Kundenservice Kongress Hamburg 2024 ist mangelnde interne Wissensdokumentation einer der drei häufigsten Gründe, warum Skalierungsvorhaben im Support scheitern oder deutlich länger dauern als geplant. Nicht fehlendes Budget. Nicht falsches Tool. Fehlende Doku.
Fang heute an. Klein. Aber fang an.
|
Dein Support wächst, aber die Struktur fehlt? In einem kostenfreien Erstgespräch schauen wir gemeinsam, wo dein Team heute steht und was eine skalierbare Dokumentation für dich konkret bedeutet. |
⭐⭐⭐⭐⭐