Veröffentlicht am 2 November 2026
Hersteller mit Vertriebs- oder Direktkundengeschäft haben eine ganz bestimmte, repetitive Art von Supportaufkommen: Welches Teil passt zu diesem Modell, ist das noch unter Garantie, warum wurde mein Ersatzteil noch nicht versendet, wie lang ist die Lieferzeit für diese SKU. Das Volumen ist hoch, die Unklarheit gering, und die Antworten lassen sich fast vollständig aus Daten ableiten, die der Hersteller bereits hat — einem Teilekatalog, einer Garantiedatenbank, einem Bestellverwaltungssystem — wenn jemand diese Systeme mit dem Supportkanal verbindet, statt jede Frage erst an einen Menschen zu leiten, der die gleichen Informationen dann manuell nachschlägt. Genau an dieser Stelle rechnet sich AI-Kundenservice-Automatisierung in der Fertigung, und genau hier laufen viele Einführungen schief, weil der falsche Teil des Volumens automatisiert werden soll.
Die konkreten Fragen, die sich zuerst zu automatisieren lohnen
Fragen zu Teilen und Kompatibilität sind meist die größte einzelne Kategorie: Passt Teil X zu Modell Y, was ist das OEM-Äquivalent für dieses abgekündigte Teil, welches Ersatzteil ersetzt das ältere Modell. Das sind Abrufprobleme, keine Denkaufgaben, und sie eignen sich besonders gut für Automatisierung, weil die richtige Antwort deterministisch ist und bereits in einem Teilekatalog oder Stücklistensystem steht — die Aufgabe der AI-Schicht besteht darin, die Frage an den richtigen Abruf weiterzuleiten und die Antwort klar zu formulieren, nicht sie neu zu erfinden.
Garantiestatus und Schadenmeldungen folgen demselben Muster. Zu prüfen, ob ein Gerät noch unter Garantie steht, bedeutet, eine Seriennummer abzurufen, sie mit Kauf- oder Registrierungsdaten abzugleichen und die Garantiebedingungen für diese Produktlinie und dieses Kaufdatum anzuwenden — mechanische Arbeit, die ein System sofort und korrekt erledigen kann, während menschliche Mitarbeitende sich auf die Garantieansprüche konzentrieren, die tatsächlich strittig sind oder Ermessensspielraum erfordern.
Bestell- und Versandstatus ist die dritte große Kategorie und wahrscheinlich die einfachste, sauber umzusetzen: „Wo ist mein Teil“ lässt sich direkt aus den Bestell- und Versandsystemen beantworten, die ein Hersteller ohnehin betreibt, und wenn diese Frage automatisch mit einer direkten Antwort und einem Tracking-Link gelöst wird, entfällt ein großer Teil des Supportaufkommens ohne echtes Unklarheitsrisiko.
Wo Support-Automatisierung in der Fertigung besondere Sorgfalt braucht
Technische Fehlerbehebung ist die Kategorie, bei der man am vorsichtigsten sein muss. „Meine Maschine wirft Fehlercode E42“ kann etwas so Einfaches wie eine lose Sensorverbindung bedeuten oder etwas so Ernstes wie einen sicherheitsrelevanten Ausfall, und die Grenze zwischen „Automatisierung kann den Kunden hier sicher durchleiten“ und „dafür braucht es jetzt einen Techniker“ muss konservativ gezogen werden, mit klarer Tendenz zur Eskalation, sobald die Schwere unklar ist. Support-Automatisierung in der Fertigung, die Fehlerbehebung bei Geräten mit Sicherheitsbezug zu stark automatisiert, ist kein kleiner UX-Fehler — das ist ein Haftungsrisiko, und die Lösung besteht in einem klar definierten, eng begrenzten Satz sicher automatisierbarer Fehlerbehebungsabläufe, während alles andere standardmäßig an einen Menschen geht.
B2B-Distributoren- und Händlerbeziehungen bringen eine weitere Ebene mit, die die meisten Playbooks für Support-Automatisierung im Consumer-Bereich nicht abdecken. Ein großer Teil des Supportaufkommens in der Fertigung kommt gar nicht von Endkunden — sondern von Händlern und Distributoren, die im Namen eines Kunden nachfragen, oft mit anderen Preisen, anderen Garantiebedingungen und anderem Kontext auf Kontoebene als ein Privatkunde ihn hätte. Eine Automatisierungsschicht, die eine Händleranfrage nicht korrekt von einer Endkundenanfrage unterscheidet, liefert bei Preisen und Konditionen falsche Antworten mit echten finanziellen Folgen, deshalb muss die Erkennung des Kontotyps früh gelöst werden und darf nicht erst später nachgerüstet werden.
Wie die tatsächliche Architektur aussieht
Eine funktionierende Einführung verbindet drei Dinge, die Hersteller oft haben, aber selten für den Support miteinander verknüpft haben: die Teilekatalog- und Stücklistendaten (für Kompatibilitäts- und Abruffragen), die Garantie- und Registrierungsdatenbank (für Deckungsfragen) sowie das Bestell- und Versandsystem (für Statusfragen). Die AI-Schicht sitzt darüber als Routing- und Gesprächsschicht — sie erkennt, welches dieser Systeme eine konkrete Frage benötigt, ruft den relevanten Datensatz ab und formuliert eine klare Antwort — statt selbst ein System zu sein, das die Antwort unabhängig von diesen zugrunde liegenden Systemen „wissen“ soll.
Das ist wichtig, weil sich dadurch verändert, worin der eigentliche Engineering-Aufwand besteht. Der schwierige Teil ist meist nicht die Conversational AI; aktuelle Modelle verstehen diese Art von Fragen sprachlich sehr gut. Schwierig ist die Integrationsarbeit — also sauberer, abfragbarer Zugriff auf Teile-, Garantie- und Auftragsdaten, die oft für den internen ERP-Einsatz gebaut wurden und nicht dafür, in Echtzeit von einer Support-Automatisierung abgefragt zu werden — sowie die Eskalationslogik, die technische, sicherheitsrelevante oder händlerspezifische Fragen korrekt erkennt und komplett von der Automatisierung ausnimmt, damit sie direkt an einen Menschen gehen.
Die Kanalstrategie ist genauso wichtig wie die Genauigkeit der Antworten
Im Support-Volumen in der Fertigung läuft selten alles über einen einzigen Kanal. Händler rufen an, Endkunden schreiben E-Mails, und ein wachsender Anteil einfacher Fragen landet über ein Web-Chat-Widget oder ein Suchfeld im Help Center. Zu versuchen, von Tag eins an eine einzige Automatisierungsebene aufzubauen, die alle drei gleich gut abdeckt, ist meist ein Fehler — die Kontext- und Kontosignale unterscheiden sich je Kanal, und die schnellsten Erfolge entstehen in der Regel, wenn man zuerst den Kanal mit den saubersten Daten wählt (oft das Web-Chat-Widget, das mit einem angemeldeten Konto verknüpft ist, wo Kontotyp und Bestellhistorie bereits bekannt sind), statt gleichzeitig die telefonbasierte Identitätsprüfung und das Channel Routing zusammen mit der eigentlichen Automatisierungslogik lösen zu wollen.
Mehrsprachiger Support sollte ebenfalls ausdrücklich mitgeplant werden und nicht erst nachträglich dazukommen, besonders für Hersteller mit Vertriebs- oder Kundennetzwerken in mehreren Ländern. Fragen zu Ersatzteilen und Gewährleistung lassen sich sprachübergreifend recht gut übertragen, weil sich die zugrunde liegende Datenabfrage nicht ändert, aber Hinweise zur Fehlerbehebung und die Sprache für Eskalationen brauchen in jeder unterstützten Sprache dieselbe sorgfältige, sicherheitsbewusste Prüfung wie in der Hauptsprache — ein übersetzter Troubleshooting-Ablauf, bei dem die Eskalationshinweise in der Übersetzung verloren gingen, ist ein schlechteres Ergebnis als diese Sprache gar nicht anzubieten.
Prüfen, ob es tatsächlich funktioniert
Die relevante Kennzahl ist nicht der „Anteil automatisierter Tickets“ — diese Zahl lässt sich ganz leicht aufblasen, indem man nur die einfachsten Fragen automatisiert und sich dann Anrechnung für Volumen zuschreibt, das ohnehin kaum menschliche Hilfe brauchte. Aussagekräftiger sind: Ist die Erstreaktionszeit in den automatisierten Kategorien gesunken, ist die Lösungstrefferquote stabil geblieben (geprüft durch echte Stichproben der automatisierten Vorgänge, nicht nur durch Annahmen), und vor allem: Wird bei technischen und sicherheitsrelevanten Fällen korrekt eskaliert, statt dass das System mit viel Selbstsicherheit etwas beantwortet, das es besser nicht angefasst hätte. Ein System, das 30% des Volumens korrekt automatisiert und den Rest sauber eskaliert, leistet mehr echte Arbeit als eines, das 70% Automatisierung behauptet, dabei aber stillschweigend einen relevanten Teil falsch beantwortet.
Hersteller, die den größten Nutzen erzielen, rollen das meist nach Fragekategorie aus und nicht nach Kanal — zuerst vollständig automatisiert werden Bestellstatus und Ersatzteilsuche, weil diese Fälle risikoarm und volumenstark sind; danach folgt die Ausweitung auf Gewährleistungsansprüche, sobald die Datenintegration solide steht; und technische Fehlerbehebung wird als langfristiges, eng abgegrenztes Projekt behandelt, statt sie direkt am ersten Tag mit hineinzuverpacken.
Diese Art von Support-Automatisierung ist Teil der breiteren manufacturing AI Arbeit, die wir leisten, und sie überschneidet sich oft mit Dokumenten- und Datenintegrationsarbeit, die im Unternehmen an anderer Stelle ohnehin bereits läuft — dieselben ERP- und Ersatzteildaten, die die Support-Automatisierung speisen, brauchen oft auch für andere Automatisierungsprojekte dieselbe Bereinigung. Wenn Sie überlegen, wo Sie mit Ihrem eigenen Support-Volumen anfangen sollen, erklärt unsere Seite zur Automatisierung des Kundensupports den breiteren Ansatz, und wir sprechen gern mit Ihnen darüber, wie ein erster, eng begrenzter Rollout für Ihre Produktlinien aussehen würde — nehmen Sie Kontakt auf, um dieses Gespräch zu starten.
Verwandt