KI-Assistent für Serviceabteilung einführen: Rollout in drei Phasen

Was ein KI-Assistent in der Serviceabteilung tatsächlich leistet

Ein KI-Assistent im Serviceticketingsystem ist nicht der Kundenservice-Chatbot, den jedes Unternehmen kennt. Er sitzt nicht zwischen Kunde und Unternehmen, sondern zwischen Ticket und Techniker. Der Assistent liest die eingehende Anfrage, sucht in der Dokumentation, in Bedienungsanleitungen und in den Reparaturprotokollen nach einer bekannten Lösung und füllt damit den Ticket-Kontext an, bevor der Techniker ihn liest.

Das unterscheidet sich grundlegend von einer Suchmaschine. Die Suchmaschine findet Dokumente, die das Wort Überströmventil enthalten. Der Assistent versteht die Frage „Ventil läuft aus" und verbindet sie mit Wartungshinweis Nr. 3.7 und dem Schaltplan auf Seite 47 der Betriebsanleitung, die beide nur das Wort Überströmventil haben, nicht „Lecks" oder „läuft aus". An dieser Stelle wird ein Techniker in fünf Minuten aktiv, statt erst zwanzig Minuten in Unterlagen zu blättern.

Eine deutsche Maschinenbau-Betrieb mit 200 Service-Anfragen je Monat hatte 68 Prozent davon als Kategorie „Standard mit Variationen" klassifiziert: eine bekannte Störung, unterschiedlich ausgelöst. Ein Assistent beantwortete diese 68 Prozent vollständig, ohne dass ein Techniker noch einmal nachschlagen musste. Die restlichen 32 Prozent waren entweder neue Fehlerbilder oder Sachschäden vor Ort, die ein Techniker sowieso sehen musste.

Woran die Einführung scheitert: die drei häufigsten Widerstände

Widerstand 1: Der Assistent erfindet Antworten. In laienfreundlichen Chatbots passiert das tatsächlich. Im Servicekontext ist das ein Fehler mit Haftungsfolgen. Die Technik dagegen ist einfach: Man gibt dem Assistenten die Anweisung, nur Texte aus der Dokumentation zu verwenden und zu sagen, wenn nichts passt. Das nennt sich Retrieval-Augmented Generation (RAG). Der Assistent sucht sich die relevanten Dokumente aus der Dokumentation, zitiert wörtlich daraus und sagt die Quelle. Erfindet nichts. Ein Assistent, der sagt „das weiß ich nicht", ist besser als einer, der erfindet.

Widerstand 2: Datenschutz und sensible Kundendaten. Ein lokales Modell läuft auf einer Grafikkarte im eigenen Rechenzentrum oder auf dem lokalen Server neben dem Ticketsystem. Die Kundendaten verlassen das Unternehmen nicht. Das kostet Hardware, spart aber Konfigurationsaufwand und Skepsis. Der Datenschützer liest einen Wort-für-Wort den gleichen Schutz wie bei jeder anderen lokalen Software. Größere Betriebe nutzen einen Mittelweg: eine lokale „Tore" vor die API, die Kundennamen, Seriennummern und Lieferadressen entfernt, bevor Daten an die API gehen.

Widerstand 3: Einführung ist zu viel Aufwand. Eine strukturierte Einführung läuft in drei Phasen über sechs bis zehn Wochen: erst eine Sandbox mit echten Tickets aus den letzten sechs Monaten, dann ein Pilot mit echter Kundenkommunikation, dann der scharfe Betrieb. Erfolgreiche Einführungen trainieren Techniker an zwei konkreten Fallbeispielen. Die Techniker sind danach nicht skeptisch geworden, sondern geschult und einverstanden.

Die drei Phasen des Rollout und was sie kosten

Phase 1 (Wochen 1-2): Sandbox. Der Assistent läuft auf einer Testumgebung mit echten historischen Tickets aus den letzten sechs Monaten. Es geht nicht um Kundenkommunikation, sondern darum, dass Ihr Servicemanager und zwei erfahrene Techniker sehen, was der Assistent antwortet und wo er Unsinn macht. Sie stellen fest: bei dieser Klassifizierung von Fehlern sind die Antworten gut, bei dieser sind sie falsch. Sie passen damit die Dokumentation an oder die Eingabe-Struktur des Formulars. Diese Phase kostet zwei bis drei Tage intensive Arbeit und spart dann Wochen später Frustrationen.

Phase 2 (Wochen 3-6): Pilot. Der Assistent läuft neben dem Normalbetrieb und bekommt echte Tickets, beantwortet sie, aber kein Kunde sieht die Antwort noch. Der Techniker sieht neben dem eigenen Urteil die Assistent-Antwort und vergleicht. Drei, vier Techniker machen das an zwei Fallbeispielen pro Woche durch. Das Nebeneinander dauert solange, bis alle beteiligten Techniker ihre anfängliche Skepsis überwunden haben.

Phase 3 (Woche 7+): Scharfschaltung. Der Assistent antwortet jetzt echte Tickets an Kunden, aber erst nur für die acht oder zehn häufigsten Fehlerkategorien, bei denen die Pilot-Quote über 85 Prozent lag. Nach zwei Wochen im Scharfbetrieb wird ausgewertet, weitere Kategorien kommen hinzu.

Was diese Phasen kosten und was sie einsparen

Einführungskosten. Außenberatung: drei bis vier Tage à 2.500 bis 3.500 Euro, Summe 7.500 bis 14.000 Euro. Interne Projektleitung und Vorbereitung der Daten: 40 bis 60 Stunden à 65 Euro Stundensatz (inkl. Overhead), Summe 2.600 bis 3.900 Euro. Hardware (lokales Modell): einmalig 9.000 bis 15.000 Euro für eine GPU mit 48 GB, danach rund 350 Watt Stromverbrauch, etwa 2.000 Euro Stromkosten je Jahr. Summe Einführung, Rollout-Risiko mitgerechnet: etwa 25.000 bis 35.000 Euro für einen Mittelständler mit 200 bis 500 Servicetickets je Monat.

Ersparnisse im ersten Jahr. 35 Prozent der einfachen Anfragen geklärt ohne Techniker-Arbeit: Bei 300 Tickets je Monat sind das 105 Tickets. Je Ticket sind 20 bis 40 Minuten Vor- und Nachbereitungszeit beim Techniker eingespart, sagen wir 30 Minuten à 65 Euro Stundensatz. Das sind 3.412 Euro pro Monat, 40.944 Euro im Jahr. Schnellere Beantwortung bei den restlichen 65 Prozent: Die Techniker brauchen durchschnittlich 25 Prozent weniger Zeit für Dokumentationsrecherche. Bei 300 Tickets à 30 Minuten sind das 150 Stunden im Monat, 25 Prozent sind 37,5 Stunden gespart, à 65 Euro sind das 2.437 Euro pro Monat, 29.250 Euro im Jahr. Summe Ersparnisse: etwa 70.000 Euro im ersten Jahr, danach 60.000 Euro im Jahr ohne die Einführungskosten.

ROI. 70.000 Euro Gewinn minus 30.000 Euro Einführungskosten = 40.000 Euro Netto im ersten Jahr, danach 60.000 Euro. Die Einführungskosten sind in fünf bis neun Monaten amortisiert.

Was beim Ausrollen noch schieflaufen kann

1. Zu umfangreiche Trainingsdaten. Manche Betriebe fütteru dem Assistenten alle Serviceprotokolle der letzten zehn Jahre, Bedienungsanleitungen, Ersatzteilkatalog und Normen auf einmal. Der Assistent wird damit lahm oder verwirrt. Besser: mit den häufigsten Fehlerkategorien anfangen (rund 80 Prozent aller Fälle) und den Rest später nachziehen.

2. Techniker nicht einbeziehen. Ein Assistent, der den Technikern aufgezwungen wird, wird blockiert oder sabotiert. In der Sandbox und im Pilot müssen die Techniker die Entscheidung treffen, ob der Assistent gut genug ist. Diese echte Entscheidungskompetenz ist wichtiger als schnelle Amortisation.

3. Kein Änderungsmanagement für die neue Dokumentation. Der Assistent funktioniert nur mit klarer, aktueller Dokumentation. Das bedeutet: wenn der Assistent eingebaut ist, muss das Service-Team Zeit für die Dokumentation aufbringen, nicht weniger Zeit als vorher. Diese Erwartung gehört in den Business Case.

Was ein KI-Assistent nicht löst

Ein Assistent ersetzt keine Diagnose vor Ort. Ein Techniker, der zur Maschine fahren muss, spart keine Fahrt. Ein Fehler, der sich nur unter Last zeigt, erklärt der Assistent nicht allein aus der Dokumentation. Eine Baustelle im Kundenservice, die mit Personalfluktuation kämpft, wird durch den Assistenten schneller klar, aber kein neues Personal einsparen. Auch ersetzt der Assistent keine Kultur. Ein Service-Team, das Tickets nicht dokumentiert und Lösungen nicht im System speichert, wird vom Assistenten nicht profitieren, weil es keine Trainingsdaten gibt. Der Assistent kann Chaos nicht ordnen, nur bestehende Ordnung automatisieren.

Was Sie diese Woche tun können

• Nehmen Sie drei bis vier Tickets der letzten Woche und lesen Sie selbst, wie lange die Recherche dauert.
• Befragen Sie Ihren Servicemanager: Wie viel Prozent der Anfragen sind Standard mit Variation, wie viel sind komplett neu?
• Lesen Sie die Datenschutz-Richtlinie durch und prüfen Sie mit dem Datenschützer, ob lokale vs. Cloud-Verarbeitung vorgegeben ist.
• Laden Sie eine kostenlose Demo eines KI-Assistenten ein und zeigen Sie sie einem erfahrenen Techniker. Fragen Sie, ob er damit schneller wäre.