--- title: "Kundenanfragen per Messenger automatisieren: ein Prototyp mit klarer Grenze – Riccardo Nentwich" description: "Praxis-Einblick: ein Prototyp für eine Kfz-Werkstatt, der Standardfragen beantwortet, Termine reserviert und heikle Anfragen an einen Menschen übergibt." url: "https://riccardonentwich.com/wissen/kundenanfragen-per-messenger-prototyp/" language: "de" translation: "https://riccardonentwich.com/en/insights/customer-enquiries-via-messenger-prototype/" updated: "2026-10-01" --- [Wissen](https://riccardonentwich.com/wissen/)[Praxis](https://riccardonentwich.com/wissen/?typ=praxis) # 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. - Autor [Riccardo Nentwich](https://riccardonentwich.com/ueber-mich/) - Veröffentlicht 1\. Oktober 2026 - Lesezeit 6 Min. - Stand Prototyp, nicht im Kundeneinsatz 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. Chat 01Werkstattwissen 1. Kunde stellt eine organisatorische Frage 2. Passende Information im Werkstattwissen 3. Direkte Antwort 1) Kunde Bekomme ich während der Inspektion einen Ersatzwagen? 2) Werkstattwissen: Ersatzwagen 3) Assistent Ja, für Inspektionen gibt es einen Ersatzwagen, solange einer frei ist. Sagen Sie am besten schon bei der Terminvereinbarung Bescheid. 4) Kunde Und kann ich vor Ort mit Karte zahlen? 5) Werkstattwissen: Zahlung 6) Assistent Ja, mit EC- oder Kreditkarte. Nachgestellt mit fiktiven Inhalten. Die Darstellung ist vereinfacht und zeigt nicht die Oberfläche eines bestimmten Messengers. ### 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. Chat 02Terminwunsch 1. Kunde möchte einen Termin 2. Anliegen erkannt, fehlende Angabe erfragt 3. Freie Termine geprüft 4. Kunde wählt 5. Termin reserviert und bestätigt 1) Kunde Hallo, ich bräuchte einen Termin für den Reifenwechsel. Geht nächste Woche? 2) Assistent Gern. Um welches Fahrzeug geht es? 3) Kunde Einen Golf, Baujahr 2019. 4) Freie Termine geprüft 5) Assistent Nächste Woche sind diese Termine frei: - Di, 10:00 - Mi, 14:30 (gewählt) - Do, 08:30 6) Kunde Mittwoch, 14:30 passt. 7) Termin reserviert · Mi, 14:30 8) Assistent Ist eingetragen. Bis Mittwoch um 14:30 Uhr. Nachgestellt mit fiktiven Inhalten. Die Darstellung ist vereinfacht und zeigt nicht die Oberfläche eines bestimmten Messengers. ### 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. Chat 03Sicherheitskritischer Fall 1. Kunde beschreibt ein mögliches Sicherheitsproblem 2. Als sicherheitsrelevant erkannt 3. Keine eigene Einschätzung 4. Übergabe an einen Menschen 1) Kunde Seit heute quietscht es beim Bremsen und das Pedal fühlt sich weich an. Kann ich damit noch fahren? 2) Sicherheitsrelevant erkannt 3) Assistent Das sollte sich jemand aus der Werkstatt persönlich ansehen. Ich gebe Ihre Nachricht direkt an unser Team weiter. 4) An das Werkstatt-Team übergebenAb hier antwortet ein Mensch. Nachgestellt mit fiktiven Inhalten. Die Darstellung ist vereinfacht und zeigt nicht die Oberfläche eines bestimmten Messengers. 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: Muster / Kundenanfrage per Messenger 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 1. Anfrage (System) 2. Erkennen (automatisch) 3. Einordnen: Standardfrage (automatisch) 4. Wissen nutzen, bei Bedarf Aktion (automatisch) 5. Antwort (System) Ausnahme 1. Anfrage (System) 2. Erkennen (automatisch) 3. Einordnen: gehört zu einem Menschen (automatisch) 4. Mitarbeiter übernimmt (Mensch) 5. 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?](https://riccardonentwich.com/wissen/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?](https://riccardonentwich.com/wissen/welchen-prozess-zuerst-automatisieren/) ## Quellen 1. [Raja Parasuraman, Thomas B. Sheridan, Christopher D. Wickens: A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics – Part A, 30(3), 2000, S. 286–297.](https://doi.org/10.1109/3468.844354) Modell, nach dem Automatisierung einzelne Funktionen unterschiedlich stark übernehmen kann – hier: erkennen und vorbereiten automatisch, entscheiden beim Menschen. 2. [Europäische Kommission: Transparency obligations under Article 50 of the AI Act (FAQ).](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act) 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. ## Weiterlesen Wissen ### [Welchen Prozess sollte man zuerst automatisieren?](https://riccardonentwich.com/wissen/welchen-prozess-zuerst-automatisieren/) Mehrere Kandidaten, ein erstes Projekt: eine Priorisierung mit sechs Kriterien, einem einfachen Vergleichsraster und den häufigsten Fehlern bei der Auswahl. 6 Min. Lesezeit 20. August 2026 Wissen ### [Wann lohnt sich Prozessautomatisierung?](https://riccardonentwich.com/wissen/wann-lohnt-sich-prozessautomatisierung/) Fünf Prüffragen, ein nachvollziehbarer Rechenweg und die Fälle, in denen man es besser lässt: So schätzen Sie ein, ob sich die Automatisierung eines konkreten Ablaufs lohnt. 7 Min. Lesezeit 31. August 2026 Werkzeug ### [Prozess-Steckbrief: Einen Geschäftsprozess auf einer Seite erfassen](https://riccardonentwich.com/wissen/prozess-steckbrief/) Auslöser, Ergebnis, Schritte, Reibungsstellen, Menge, Ausnahmen und Entscheidungen: ein Ablauf auf einer Seite. Zum Ausdrucken, mit Anleitung und Beispielen. Vorlage zum AusfüllenPDF 21. September 2026 Ihr Ablauf ## Ein ähnlicher Ablauf bei Ihnen? Schildern Sie mir, wie Anfragen heute bei Ihnen ankommen. Ob und was sich daran automatisieren lässt, klären wir danach. [Erstgespräch vereinbaren](https://riccardonentwich.com/erstgespraech/)