Kundenanfragen per Messenger: Was sich automatisieren lässt – und was nicht
Ich wollte wissen, wie weit sich Kundenanfragen per Chat sinnvoll automatisieren lassen, und habe den Ablauf am Beispiel einer Kfz-Werkstatt als Prototyp gebaut. Drei Szenarien, eine klare Grenze.
So kann ein Vormittag in einer Werkstatt aussehen: Das Telefon klingelt, während jemand unter einem Auto liegt. Nebenbei kommen Nachrichten. Ob nächste Woche noch ein Termin frei ist. Ob es einen Ersatzwagen gibt. Und einmal: dass die Bremse seit heute komisch klingt.
Die meisten dieser Nachrichten sind schnell beantwortet. Aber jemand muss sie lesen, einordnen und beantworten, oft zwischen zwei anderen Aufgaben. Und eine davon ist keine Routine.
Kundenanfragen per Messenger lassen sich dort sinnvoll automatisieren, wo Standardfälle klar beschrieben sind, das nötige Firmenwissen vorliegt und festgelegt ist, wann ein Mensch übernimmt. Die Übergabe an einen Mitarbeiter ist dabei kein Mangel des Systems, sondern Teil eines guten Ablaufs.
Die Frage
Nicht „Chatbot ja oder nein“, sondern: Welche Nachricht braucht einen Menschen?
Manche Kunden schreiben lieber, als anzurufen, etwa per WhatsApp. Für einen Betrieb ist das ein weiterer Kanal, der gelesen und beantwortet werden will.
Mich hat dabei nicht interessiert, ob sich ein Chat automatisieren lässt. Sondern welche Anfragen sich zuverlässig ohne Mitarbeiter erledigen lassen, und woran ein System erkennt, dass es besser aufhört. Um das nicht nur theoretisch zu beantworten, habe ich den Ablauf am Beispiel einer Kfz-Werkstatt als Prototyp gebaut. Der Chat ist dabei nur die Oberfläche. Entscheidend ist der Ablauf dahinter.
Kurz gesagt
- Was
- Ein Prototyp, der Kundenanfragen im Chat beantwortet, einen Termin reserviert oder an einen Menschen übergibt.
- Beispiel
- Eine Kfz-Werkstatt.
- Gebaut
- Drei Szenarien: Werkstattwissen, Terminwunsch, sicherheitskritischer Fall.
- Mensch
- Übernimmt, sobald eine Anfrage sicherheitsrelevant ist.
- Stand
- Demonstrator. Bei keinem Kunden im Einsatz, keine gemessenen Ergebnisse.
Gebaut
Drei Szenarien
Der Prototyp bildet drei Situationen ab. Die Chats unten sind nachgestellt: Die Texte sind fiktiv, der Ablauf je Szenario entspricht dem Prototyp. Zu jedem Chat gehört der Ablauf, der zeigt, wer gerade handelt: der Kunde, das System oder ein Mensch aus der Werkstatt.
01 · Eine Frage mit fester Antwort
Viele Fragen haben eine Antwort, die sich selten ändert: Gibt es einen Ersatzwagen? Wie kann ich bezahlen? Der Prototyp beantwortet solche organisatorischen Fragen direkt aus vorhandenem Werkstattwissen.
- Kunde stellt eine organisatorische Frage
- Passende Information im Werkstattwissen
- Direkte Antwort
Bekomme ich während der Inspektion einen Ersatzwagen?
- Werkstattwissen: Ersatzwagen
Ja, für Inspektionen gibt es einen Ersatzwagen, solange einer frei ist. Sagen Sie am besten schon bei der Terminvereinbarung Bescheid.
Und kann ich vor Ort mit Karte zahlen?
- Werkstattwissen: Zahlung
Ja, mit EC- oder Kreditkarte.
02 · Ein Terminwunsch
Ein Terminwunsch braucht mehr als eine Antwort. Der Prototyp erkennt das Anliegen, fragt eine fehlende Angabe nach, prüft freie Termine, bietet sie an und reserviert den gewählten. Woher die freien Termine in einem echten Betrieb kämen, hängt von dessen Terminplanung ab.
- Kunde möchte einen Termin
- Anliegen erkannt, fehlende Angabe erfragt
- Freie Termine geprüft
- Kunde wählt
- Termin reserviert und bestätigt
Hallo, ich bräuchte einen Termin für den Reifenwechsel. Geht nächste Woche?
Gern. Um welches Fahrzeug geht es?
Einen Golf, Baujahr 2019.
- Freie Termine geprüft
Nächste Woche sind diese Termine frei:
Mittwoch, 14:30 passt.
- Termin reserviert · Mi, 14:30
Ist eingetragen. Bis Mittwoch um 14:30 Uhr.
03 · Eine Frage, die keine Routine ist
Die dritte Nachricht sieht aus wie die anderen: kurz, mit einer Frage am Ende. Eine verlässliche Antwort darauf kann aber nur jemand geben, der sich das Auto ansieht. Der Prototyp erkennt, dass die Anfrage sicherheitsrelevant ist, gibt keine eigene Einschätzung ab und übergibt an einen Menschen.
- Kunde beschreibt ein mögliches Sicherheitsproblem
- Als sicherheitsrelevant erkannt
- Keine eigene Einschätzung
- Übergabe an einen Menschen
Seit heute quietscht es beim Bremsen und das Pedal fühlt sich weich an. Kann ich damit noch fahren?
- Sicherheitsrelevant erkannt
Das sollte sich jemand aus der Werkstatt persönlich ansehen. Ich gebe Ihre Nachricht direkt an unser Team weiter.
- An das Werkstatt-Team übergebenAb hier antwortet ein Mensch.
Die Grenze
Der wichtigste Fall ist der, in dem das System aufhört
Ein System, das Texte formuliert, würde auch auf die Frage nach der Bremse eine Antwort finden. Genau das soll hier nicht passieren. Eine falsche Auskunft zu Öffnungszeiten ist ärgerlich. Eine falsche Auskunft zur Verkehrssicherheit ist etwas anderes.
Eine gute Automatisierung erkennt, wann sie nicht weitermachen sollte.
Deshalb gehört die Grenze zur Lösung und nicht an ihren Rand. Der Prototyp soll Standardfälle erledigen und erkennen, wann eine Anfrage in die Hände eines Menschen gehört. Für mich ist das keine Einschränkung, sondern der wichtigste Teil des Ablaufs.
Die Forschung zur Mensch-Maschine-Interaktion beschreibt das als Frage der Aufgabenteilung: Parasuraman, Sheridan und Wickens unterscheiden (2000) zwischen dem Aufnehmen und Auswerten von Informationen, dem Entscheiden und dem Ausführen. Jede dieser Funktionen kann unterschiedlich stark automatisiert werden. Im Prototyp erkennt das System das Anliegen und bereitet vor, die Entscheidung in heiklen Fällen bleibt beim Menschen.
Das Prinzip
Was daran übertragbar ist
Nimmt man die Werkstatt heraus, bleibt ein Muster, das in vielen Betrieben vorkommt:
Eine Nachricht kommt an, wird automatisch erkannt und eingeordnet. Im Standardfall beantwortet das System sie mit vorhandenem Wissen. Ist die Anfrage heikel, übernimmt ein Mitarbeiter und antwortet selbst.
Standardfall
- Anfrage (System)
- Erkennen (automatisch)
- Einordnen: Standardfrage (automatisch)
- Wissen nutzen, bei Bedarf Aktion (automatisch)
- Antwort (System)
Ausnahme
- Anfrage (System)
- Erkennen (automatisch)
- Einordnen: gehört zu einem Menschen (automatisch)
- Mitarbeiter übernimmt (Mensch)
- Antwort (System)
Ob das Muster in einem Betrieb trägt, hängt an drei Bedingungen:
- Die Standardfälle sind klar. Welche Fragen und Wünsche kommen immer wieder, und wie lautet jeweils die richtige Antwort oder Aktion?
- Das Wissen liegt vor und wird gepflegt. Öffnungszeiten, Leistungen, Abläufe: Eine Antwort ist nur so gut wie die Information, auf die sie sich stützt.
- Die Grenze ist festgelegt. Welche Themen gehen immer an einen Menschen, und wie erfährt der Mitarbeiter davon?
Ob sich der Aufwand für einen Betrieb lohnt, ist eine eigene Rechnung. Wie man sie aufstellt, beschreibt der Beitrag Wann lohnt sich Prozessautomatisierung?
Denkbar
Wo das Prinzip außerhalb der Werkstatt passen könnte
Die folgenden Beispiele sind keine umgesetzten Projekte, sondern mögliche Übertragungen des Musters. Ob sie im Einzelfall sinnvoll sind, hängt vom Ablauf und von den vorhandenen Systemen ab.
- Handwerksbetrieb: Denkbar wäre, Anfragen für Wartungs- oder Besichtigungstermine vorzuklären, bevor jemand zurückruft.
- Dienstleister: Dasselbe Prinzip könnte wiederkehrende Fragen zum Ablauf oder zu benötigten Unterlagen beantworten.
- Betrieb mit festen Terminen: Je nach Terminplanung ließen sich Buchungen über den Chat vorbereiten.
- Fachhandel: Denkbar wären Antworten zu Öffnungszeiten und Abholung oder der Hinweis, wer für eine Frage der richtige Ansprechpartner ist.
Mögliche Weiterentwicklungen
Auch in der Werkstatt ließe sich der Prototyp erweitern. Nichts davon ist umgesetzt:
- Angaben vor einem Termin einsammeln, damit die Werkstatt vorbereitet ist.
- Termine verschieben, ohne dass jemand zurückrufen muss.
- Fragen zum Stand eines laufenden Auftrags beantworten, sofern die Werkstattsoftware diese Information bereitstellt.
- Anfragen, die nicht automatisch bearbeitet werden, direkt an die zuständige Person weitergeben.
- Service-Erinnerungen oder Statusmeldungen verschicken. Nachrichten, die ein Betrieb von sich aus sendet, werfen allerdings eigene Fragen auf, etwa zur Einwilligung der Kunden und zu den Regeln des jeweiligen Kanals, und wären gesondert zu prüfen.
Welche davon sich lohnen, zeigt erst der konkrete Ablauf. Nicht alles, was möglich ist, ist auch sinnvoll.
Stand
Was der Prototyp ist, und was nicht
Der Prototyp ist ein Demonstrator. Er ist bei keinem Kunden im Einsatz, und es gibt keine gemessenen Ergebnisse.
Für einen echten Betrieb wären mehrere Fragen erst zu klären: über welchen Kanal Kunden schreiben, woher freie Termine kommen, wer das Wissen pflegt, auf das sich Antworten stützen, und wie mit den Daten der Kunden umgegangen wird. Diese Entscheidungen hängen von den Systemen und Abläufen des jeweiligen Betriebs ab. Ein Prototyp beantwortet sie nicht.
Setzt ein Betrieb für solche Antworten ein KI-System ein, kommt eine rechtliche Frage hinzu: Nach Artikel 50 der EU-KI-Verordnung müssen Systeme, die direkt mit Menschen kommunizieren, seit dem 2. August 2026 so gestaltet sein, dass die Betroffenen erfahren, dass sie mit einer KI sprechen, sofern das nicht offensichtlich ist. Was das im Einzelfall bedeutet, wäre bei einem echten Einsatz zu klären.
Ein Prototyp zeigt, dass ein Ablauf funktionieren kann. Ob er sich im Alltag bewährt, zeigt erst der Einsatz.
Einordnung
Was ich daraus mitnehme
- Die spannende Frage ist nicht, ob ein Chat Anfragen beantworten kann, sondern welche. Die Antwort darauf steckt im Betrieb, nicht in der Technik.
- Die Grenze muss man festlegen, bevor man baut. Welche Fragen weitergegeben werden, ist eine Entscheidung des Betriebs.
- Eine Antwort ist nur so gut wie das Wissen dahinter. Welche Informationen ein Betrieb freigibt und aktuell hält, entscheidet mehr als das Werkzeug.
Wer überlegt, ob ein solcher Ablauf im eigenen Unternehmen der richtige Anfang wäre, findet Kriterien dafür im Beitrag Welchen Prozess sollte man zuerst automatisieren?
Quellen
Modell, nach dem Automatisierung einzelne Funktionen unterschiedlich stark übernehmen kann – hier: erkennen und vorbereiten automatisch, entscheiden beim Menschen.
Seit dem 2. August 2026 müssen KI-Systeme, die direkt mit Menschen interagieren, so gestaltet sein, dass die Betroffenen davon erfahren, sofern es nicht offensichtlich ist.