Die Geschäftsführung will bis Jahresende sehen, was KI im Service bringt. Im Innendienst sind die Maschinen seit Jahren sauber erfasst, Servicefälle laufen über dasselbe System, die Techniker bekommen ihre Aufträge daraus. Jetzt soll ein Agent zeigen, was er kann. Die naheliegende Frage lautet: Wo setzen wir ihn ein, und woran erkennen wir nach vier Wochen, ob es funktioniert?
Mit dem Druck sind Sie nicht allein. In einer Gartner-Umfrage unter 321 Service- und Support-Verantwortlichen gaben 91 Prozent an, dass ihre Geschäftsleitung sie drängt, 2026 KI einzuführen (Gartner, Februar 2026). Ein Pilot ist deshalb schnell beschlossen. Was er über die eigenen Daten verrät, wird dagegen selten ausgewertet. Kurz vorab, worauf es ankommt:
- Wer seine Maschinen schon im Servicesystem führt, hat die wichtigste Vorarbeit erledigt. Ein Agent kann dort sofort mit echten Fällen arbeiten.
- Triage eingehender Fälle ist der sinnvollste erste Einsatz. Einordnen, Ursachen vermuten, ähnliche Fälle finden, nächsten Schritt vorschlagen: Das entlastet den Innendienst und läuft auf vorhandenen Daten.
- Der Pilot zeigt Fall für Fall, wo der Agent rät. Jede schwache Antwort lässt sich auf eine konkrete Lücke zurückführen, etwa Messwerte in einem separaten System oder Wartungen, die nicht an der Maschine hängen.
- Lücken werden einzeln geschlossen, dort, wo der Pilot sie zeigt. Ein Gesamtumbau ist dafür nicht nötig.
Sie testen gerade einen Agenten im Service oder wollen damit starten?
In 30 Minuten gehen wir mit Ihnen drei bis fünf echte Servicefälle durch: was ein Triage-Agent mit Ihren heutigen Daten beantworten kann und an welcher Stelle er raten würde. Kein Folientermin.
→ Erstgespräch vereinbaren
Agentforce im Service: Warum Triage der beste erste Einsatz ist
Ein Servicefall im Maschinenbau beginnt fast immer gleich. Ein Kunde meldet per Mail, Telefon oder Portal eine Störung, oft mit Fehlercode, manchmal mit Foto, selten mit Seriennummer. Im Innendienst liest jemand die Meldung, sucht die Maschine, schaut in die Historie, fragt bei einem erfahrenen Kollegen nach und entscheidet: Rückruf, Fernwartung, Ersatzteil oder Technikereinsatz. Bei 40 oder 60 Meldungen am Tag ist das der Engpass des ganzen Service.
Genau diese Arbeit kann ein Agent vorbereiten. Triage heißt hier vier Dinge:
- Einordnen: Kategorie, Dringlichkeit, betroffene Baugruppe.
- Ursachen vermuten: zwei oder drei Hypothesen, jeweils mit Begründung.
- Ähnliche Fälle finden: an derselben Baureihe, mit derselben Fehlermeldung, mit dokumentierter Lösung.
- Nächsten Schritt vorschlagen: Rückfrage beim Kunden, Remote-Diagnose, Ersatzteil, Einsatz.
Die Entscheidung bleibt beim Menschen. Der Agent spart ihm die Suche, und das spürt der Innendienst ab dem ersten Tag.
Dazu kommt ein praktischer Grund: Triage braucht nichts, was nicht schon da ist. Wer Salesforce seit Jahren im Service nutzt, hat die Fälle, die Maschinen als Assets mit eigenen Erweiterungen, die Einsatzhistorie und meist auch Dokumentation im System. Auf diesen Daten kann ein Agent arbeiten, ohne dass vorher ein neues Datenmodell entsteht. Die Plattform bringt für das Einordnen eingehender Fälle bereits Bausteine mit, etwa die Klassifizierung nach Typ und Priorität auf Basis früherer Fälle.
Agentforce for Field Service, seit 2025 schrittweise verfügbar, setzt an einer anderen Stelle an: bei der Terminplanung, beim Briefing des Technikers vor dem Einsatz, bei der Fehlersuche vor Ort und beim Bericht danach. Das ergänzt sich. Die Triage entscheidet, ob überhaupt ein Einsatz nötig ist und mit welcher Vermutung der Techniker losfährt.
Den Pilot aufsetzen: echte Fälle, nachvollziehbare Bewertung
Viele Piloten scheitern an der Auswertung. Es wird drei Wochen getestet, die Rückmeldung lautet „teils gut, teils daneben“, und niemand kann sagen, woran es lag. Aufschlussreich wird ein Pilot erst, wenn jede Antwort einzeln bewertet wird.
Am aussagekräftigsten ist ein Rückspiegel-Test: Der Agent bekommt abgeschlossene Fälle, deren Ausgang bekannt ist. Am besten aus einer Baureihe mit vielen Maschinen im Feld, über die vergangenen sechs bis zwölf Monate, mit einer Mischung aus einfachen und schwierigen Störungen. Weil die tatsächliche Ursache feststeht, lässt sich jede Antwort sauber einordnen:
- Getroffen: Hypothese und nächster Schritt stimmen mit dem tatsächlichen Verlauf überein, belegt durch Daten im System.
- Plausibel, aber unbelegt: Die Antwort klingt richtig, stützt sich aber auf allgemeines Wissen statt auf Daten dieser Maschine.
- Geraten: Die Antwort passt nicht zum Fall, oder der Agent erfindet einen Zusammenhang.
Die zweite Gruppe ist die interessanteste. Dort stimmt das Ergebnis zufällig oder aus Erfahrung des Sprachmodells, nicht aus Ihren Daten. Bei der nächsten Maschine kann es genauso gut danebenliegen. Zu jeder Antwort in den Gruppen zwei und drei gehört deshalb eine kurze Notiz: Welche Information hätte der Agent gebraucht, und wo liegt sie heute?
Bewerten sollten das die Leute, die die Fälle damals bearbeitet haben, also Innendienst und erfahrene Techniker. Sie erkennen sofort, ob eine Hypothese fachlich trägt. Wenn Sie den Pilot mit Ihrem Implementierungspartner oder mit Unterstützung beim Aufbau von Agentforce durchführen, gehört diese Bewertungsliste mit in den Projektplan.
Wo der Agent rät: was das über Ihre Asset-Daten sagt
Nach einigen Dutzend bewerteten Fällen wiederholen sich die Notizen. Oft erklären wenige Ursachen einen großen Teil der schwachen Antworten. Typische Szenarien:
| Beobachtung im Pilot | Typische Ursache | Gezielter Schritt |
|---|---|---|
| Hypothese übersieht einen Temperaturanstieg, den der Techniker später findet | Messwerte liegen in einem separaten IoT-System und werden nie Teil des Falls | Kritische Messwerte als Fall oder am Asset ablegen |
| Agent schlägt eine Wartung vor, die vor zwei Wochen erledigt wurde | Wartungshistorie und Verträge hängen am Kunden, nicht an der Maschine | Wartungsaufträge und Verträge dem Asset zuordnen |
| Empfehlung passt zum Auslieferungszustand, die Maschine wurde aber umgebaut | Revisions- und Bauzustand sind nicht erfasst | Umbauten und Revisionsstand am Asset festhalten |
| Agent ignoriert ein Feld, das im Innendienst jeder kennt | Eigene Felder haben kryptische Namen und keine Beschreibung | Feldbeschreibungen und Auswahlwerte verständlich formulieren |
| Ähnliche Fälle fehlen oder passen nicht | Alte Fälle ohne Seriennummer, Lösung nur im Freitext oder gar nicht dokumentiert | Asset als Pflichtangabe am Fall, Lösung beim Abschluss erfassen |
Die vierte Zeile wird oft unterschätzt. Über Jahre gewachsene Erweiterungen am Asset sind für die Menschen im Unternehmen selbstverständlich: Jeder weiß, was „Kennz. Sonderausführung“ bedeutet oder welcher Wert im Feld „Steuerungsgeneration“ kritisch ist. Ein Agent weiß es nicht. Er liest Feldnamen, Beschreibungen und Auswahlwerte. Fehlen die Beschreibungen, ignoriert er das Feld oder deutet es falsch. Der Aufwand, das zu beheben, ist klein: eine Liste der wichtigsten 20 bis 30 Felder, je ein Satz Erklärung, gepflegt im System.
Eine Lücke nach der anderen
Aus der Notizliste wird eine Reihenfolge. Oben steht die Lücke, die die meisten schwachen Antworten erklärt und sich mit dem geringsten Aufwand schließen lässt. Häufig sind das die Feldbeschreibungen oder die Zuordnung der Wartungshistorie. Die Anbindung der Messwerte dauert länger, weil sie ein zweites System betrifft. Wie aus einem Messwert ein bearbeitbarer Fall wird, beschreibt der Beitrag Vom Maschinendatum zum Serviceauftrag.
An der Struktur, die Sie mit Ihrem Implementierungspartner aufgebaut haben, ändert sich dabei nichts Grundsätzliches. Es kommen Zuordnungen, Beschreibungen und gegebenenfalls einzelne Felder hinzu. Nach jeder geschlossenen Lücke läuft derselbe Satz Testfälle noch einmal durch. So wird sichtbar, wie viele Antworten von „geraten“ auf „getroffen“ wandern, und die nächste Investition lässt sich mit Zahlen aus dem eigenen Haus begründen.
Der Pilot ist damit auch ein Datencheck. Er kostet kaum mehr als der Test, den Sie ohnehin machen, und er liefert eine priorisierte Liste, die nach dem Pilot noch etwas wert ist.
Was ein Triage-Agent im Maschinenbau leisten sollte
Ob ein Agent für diese Arbeit taugt, zeigt sich an drei Eigenschaften. Er muss mit Maschinen umgehen können, also mit Baureihen, Seriennummern, Baugruppen und Fehlercodes, die je nach Variante etwas anderes bedeuten. Er muss jede Hypothese mit den Datensätzen belegen, auf die er sich stützt. Und er muss sagen, wenn ihm Daten fehlen, statt die Lücke mit allgemeinem Wissen zu füllen. Ohne die letzten beiden Punkte ist die Bewertung im Pilot kaum möglich, weil „plausibel“ und „belegt“ gleich aussehen. Warum das bei Agenten im Service so entscheidend ist, steht im Beitrag Wenn Agentforce halluziniert.
Für diese Aufgabe hat logicline Service Decision Intelligence (SDI) entwickelt, einen Salesforce-nativen Triage- und Diagnose-Agenten für den Service im Maschinenbau. SDI läuft auf dem Standard-Asset mit Ihren eigenen Erweiterungen, die Digitale Maschinenakte (IOTAM) ist dafür keine Voraussetzung. Jede Empfehlung kommt mit Quellennachweis, und fehlende Daten werden als solche benannt. Das ist genau die Information, die der Pilot braucht. SDI läuft auf Ihrer Infrastruktur, EU-konform und unabhängig vom Sprachmodell, und lässt sich auch aus Agentforce heraus aufrufen. Mit jeder geschlossenen Lücke werden die Antworten besser.
Nächster Schritt
Ein Agenten-Pilot im Service zeigt, welche Informationen Ihrem Service heute bei jeder Entscheidung fehlen, auch dem Menschen im Innendienst. Diese Liste ist der eigentliche Ertrag, und sie bleibt, egal welcher Agent am Ende produktiv geht.
Zwei pragmatische Einstiege:
- Installed Base Assessment – wenn Maschinen, Wartungen und Messwerte heute über mehrere Systeme verteilt liegen und Sie vor dem Pilot wissen wollen, welche Daten an der Maschine ankommen.
- Erstgespräch – wenn Ihre Maschinen im Servicesystem stehen und Sie klären wollen, mit welchen Fällen und welcher Bewertung der Triage-Pilot startet.
Nehmen Sie für den ersten Durchlauf die Baureihe, zu der im Innendienst die meisten Meldungen eingehen. Dort entlastet der Agent den Innendienst zuerst, und dort zeigen sich die Lücken am schnellsten.
FAQs
Welche Daten braucht ein KI-Agent für die Triage im Service?
Für den Start reichen die Daten, die in einem gepflegten Servicesystem ohnehin liegen: die Servicefälle mit Beschreibung und Lösung, die Maschine als Asset mit Seriennummer und Baureihe, die Einsatzhistorie und technische Dokumentation. Messwerte, Wartungshistorie und Bauzustand verbessern die Antworten, sobald sie an der Maschine hängen, sind aber keine Voraussetzung für den ersten Pilot.
Muss das Asset-Modell für einen Agentforce-Pilot umgebaut werden?
Nein. Ein Triage-Agent kann auf dem bestehenden Asset mit seinen eigenen Erweiterungen arbeiten. Was der Pilot an Lücken zeigt, wird gezielt ergänzt, etwa durch Feldbeschreibungen oder die Zuordnung von Wartungen zur Maschine. Ein Neuaufbau ist dafür nicht nötig.
Woran erkennt man im Pilot, dass ein Agent rät?
Am einfachsten im Rückspiegel-Test mit abgeschlossenen Fällen, deren Ursache bekannt ist. Eine Antwort, die richtig klingt, sich aber nicht auf Daten dieser Maschine stützt, ist geraten, auch wenn sie zufällig stimmt. Ein Agent, der jede Hypothese mit Quellen belegt und fehlende Daten benennt, macht diese Unterscheidung sichtbar.
Wie erkennt man, ob Wie viele Fälle braucht ein aussagekräftiger Triage-Pilot? Ersatzteile anderswo kaufen?
Einige Dutzend abgeschlossene Fälle einer Baureihe reichen, um Muster zu erkennen, sofern sie einfache und schwierige Störungen mischen. Wichtiger als die Menge ist, dass jede Antwort einzeln bewertet wird und zu jeder schwachen Antwort notiert ist, welche Information gefehlt hat.
Wie hängen Triage und Agentforce for Field Service zusammen?
Agentforce for Field Service unterstützt vor allem Disposition und Einsatz: Terminplanung, Briefing vor dem Einsatz, Fehlersuche vor Ort und Bericht danach. Die Triage liegt davor. Sie entscheidet, ob ein Einsatz nötig ist, und gibt dem Techniker eine begründete Vermutung mit. Beide nutzen dieselben Daten zur Maschine und profitieren von denselben geschlossenen Lücken.
