Zuerst messen, was tatsächlich hereinkommt
Der erste Fehler bei fast jeder Support-Automatisierung ist, dass sie an der falschen Stelle anfängt — meist dort, wo es technisch am spannendsten aussieht. Die Reihenfolge ergibt sich aber nicht aus dem Bauchgefühl, sondern aus der Verteilung der Anliegen. Also haben wir in einem Kundenprojekt zuerst gezählt, worum es in den Anfragen überhaupt geht.
Ein schnell geschriebenes Skript mit Stichwortsuche zählte unter anderem die ausgehenden Mails des Teams als Kundenanfragen mit und lag bei einzelnen Kategorien um den Faktor drei daneben. Wer auf dieser Grundlage automatisiert, baut mit hohem Aufwand am tatsächlichen Aufkommen vorbei. Erst nach der Korrektur ergab sich ein belastbares Bild.
| Anliegen | Anteil | Automatisierbar |
|---|---|---|
| Versand und Lieferstatus | 41 % | Weitgehend — Antwort steht in Shop und Sendungsverfolgung |
| Sonstiges und Rückfragen | 25 % | Teilweise — Klassifizierung und Zuordnung ja, Antwort nein |
| Produktfragen | 17 % | Teilweise — nur bei belegten Angaben aus dem Katalog |
| Retoure und Widerruf | 8 % | Nein — Rechtsfolgen, gehört an einen Menschen |
| Rechnung | 6 % | Teilweise — Belegversand ja, Streitfälle nein |
| Reklamation | unter 1 % | Nein |
Diese Verteilung entscheidet über die Reihenfolge. Wer bei den 8 % Widerrufen anfängt, automatisiert ausgerechnet das Rechtsrisiko und lässt die 41 % liegen, bei denen die Antwort ohnehin schon in einem angebundenen System steht.
Vier Eingriffe, die tatsächlich etwas bewegt haben
1. Herausfinden, wer der Kunde wirklich ist
Ein Teil der Anfragen erreicht das Ticketsystem nicht direkt, sondern als Weiterleitung aus einem anderen Postfach — etwa aus einem Shop-Kontaktformular oder einer Sammeladresse. Das System trägt dann die weiterleitende Adresse als Anfragenden ein, nicht die des Kunden. Der Effekt ist unsichtbar und folgenschwer: Antworten gehen an den Weiterleiter statt an den Kunden.
Technisch war der Fund unangenehm versteckt. Die echte Adresse stand nicht im Klartext der
Nachricht, sondern nur in deren HTML-Fassung im Muster From: Name <mail>.
Weitergeleitete Formular-Mails hatten zusätzlich die Adresse des Shop-Systems als Absender —
dort steckt der Kunde in den Formularfeldern. Beides wird jetzt automatisch ausgelesen, der
richtige Kunde zugeordnet und, falls er noch nicht existiert, angelegt.
Dieser Schritt muss zwingend vor allen anderen laufen. Wer zuerst zusammenführt und dann die Zuordnung korrigiert, gruppiert fremde Kunden unter einer Sammeladresse.
2. Mehrfachanfragen zusammenführen
Kunden schreiben zum selben Anliegen oft mehrfach — im gemessenen Zeitraum kamen im Schnitt zwei Vorgänge auf eine Person. Für die Bearbeitung bedeutet das doppelte Arbeit am selben Fall und für den Kunden die Chance, zwei unterschiedliche Antworten zu bekommen. Zusammenführen löst beides auf einmal.
Bereits gelöste oder geschlossene Vorgänge lassen sich nicht als Quelle zusammenführen — das Ticketsystem lehnt das ab. Bei zwei Dritteln unserer Kandidaten war genau das der Fall. Sie werden inzwischen bewusst übersprungen und separat gemeldet, statt bei jedem Lauf in denselben Fehler zu laufen. Und weil ein Zusammenführen nicht rückgängig zu machen ist, läuft es grundsätzlich zuerst im Trockenlauf.
3. Den echten Sendungsstand beschaffen
Die naheliegende Antwort auf „wo ist mein Paket" wäre der Status aus dem Shopsystem. Der taugt aber nichts: Bei allen Sendungen stand dort dauerhaft nur, dass ein Versandlabel erzeugt wurde. Der tatsächliche Transportstatus kommt erst aus der Sendungsverfolgung. Bei Sendungen, die älter als 21 Tage waren, lieferte sie in 91 % der Fälle einen echten Status; bei frisch versandten in 0 % — dort gibt es schlicht noch keinen.
Daraus wurde eine harte Regel im Code: Aus „Label erzeugt" wird niemals eine Aussage über den Transport. Zu schreiben, die Sendung sei unterwegs, wenn nur ein Label existiert, wäre eine irreführende Angabe im Sinne des § 5 UWG — und ärgert genau die Kunden, die ohnehin schon warten.
Die Abfrage direkt nach der Registrierung einer Sendungsnummer liefert fast immer „nicht gefunden" — die Daten kommen asynchron nach. Im Stapelbetrieb ist das egal, in einem Live-Gespräch ist es fatal. Deshalb wird bis zu dreimal in kurzem Abstand nachgefasst, bevor eine Aussage entsteht.
4. Sofort reagieren statt im Stapel
Zunächst lief die Verarbeitung als geplanter Lauf alle zwei Stunden. Inzwischen löst jede eingehende Kundennachricht die Verarbeitung direkt aus; ein einzelner Vorgang ist nach etwa 23 Sekunden klassifiziert, zugeordnet und mit einem Antwortentwurf versehen.
Der auslösende Trigger braucht zwingend die Bedingung, dass der Kommentar öffentlich ist und vom Kunden stammt. Fehlt sie, lösen die eigenen internen Notizen den nächsten Lauf aus — und das System kommentiert sich selbst im Kreis.
Was bewusst nicht automatisiert wurde
Der Assistent schreibt seine Entwürfe als interne Notiz. Ein Mensch gibt frei. Das ist keine Übergangslösung, sondern die Konstruktion: Solange der Betrieb nicht über Monate belegt hat, dass die Entwürfe tragen, verschickt niemand automatisch Post an Kunden.
Fest im Code verankerte Ausnahmen — hier wird nie automatisch geantwortet:
- wenn im Text ein Anwalt, eine Verbraucherzentrale oder eine Rückbuchung vorkommt
- wenn die Absenderadresse nicht zur Adresse der Bestellung passt (sonst gibt das System Bestelldaten an Fremde heraus)
- wenn eine Sendung als zugestellt gilt, der Kunde aber danach fragt
- bei Widerruf, Storno und Retoure — die laufen im etablierten schriftlichen Ablauf
Dazu eine Regel, die keine technische ist: In Support-Mails gehört keine Werbung. Das ist nicht nur guter Stil, sondern folgt aus § 7 Abs. 2 Nr. 2 UWG.
Was das unterm Strich heißt
Bei den Versandanfragen — der größten Gruppe — erreicht das System eine Automatisierungsquote von rund 50 %. Nicht 90 %. Der Rest scheitert an fehlenden Daten, an Grenzfällen oder an Regeln, die absichtlich blockieren.
Der eigentliche Gewinn liegt aber weniger in der Quote als in dem, was vorher überhaupt nicht sichtbar war: falsch zugeordnete Absender, doppelt geführte Vorgänge, Sendungen ohne belastbaren Status. Ein System, das jede eingehende Nachricht gleich behandelt, macht solche Muster zwangsläufig sichtbar — ein Mensch, der 20 Vorgänge am Stück abarbeitet, kann das nicht leisten.
Wer denselben Weg über das Telefon gehen will, sollte vorher die Kosten- und Rechtsfragen kennen: dazu unser Beitrag über KI-Telefonassistenten.
Häufige Fragen
Ab wie vielen Anfragen am Tag lohnt sich Support-Automatisierung?
Weniger die Menge entscheidet als die Wiederholung. Wenn ein einzelnes Anliegen — typischerweise die Frage nach dem Sendungsstand — mehr als ein Drittel des Aufkommens ausmacht, rechnet sich die Automatisierung dieses einen Falls oft schon bei zehn Anfragen am Tag. Bei einem breit gestreuten Anliegen-Mix ohne dominierende Gruppe dauert es deutlich länger.
Antwortet das System selbstständig an Kunden?
In unserer Konstruktion nicht. Die Entwürfe werden als interne Notiz am Vorgang abgelegt, ein Mensch gibt frei. Das ist Absicht: Erst wenn der Betrieb über Monate belegt, dass die Entwürfe tragen, ist ein automatischer Versand überhaupt eine Diskussion wert.
Was lässt sich im Kundenservice nicht automatisieren?
Alles mit Rechtsfolgen und alles Eskalierte: Widerruf, Storno und Retoure, angekündigte Anwälte, Rückbuchungen, Beschwerden. Ebenso Fälle, in denen die Absenderadresse nicht zur Bestellung passt — sonst gibt das System Bestelldaten an Fremde heraus. Diese Ausnahmen stehen fest im Code, nicht in einer Anweisung an ein Sprachmodell.
Warum ist der Sendungsstatus aus dem Shopsystem nicht ausreichend?
Weil er bei vielen Versanddienstleistern dauerhaft nur meldet, dass ein Versandlabel erzeugt wurde. Daraus eine Aussage über den Transport zu machen, wäre eine irreführende Angabe. Der echte Status kommt erst aus der Sendungsverfolgung — bei Sendungen älter als drei Wochen in etwa 91 % der Fälle.