Ausgangslage
Ein Transportunternehmen in Panevėžys mit rund 90 Mitarbeitenden befördert Fracht innerhalb Litauens und nach Westeuropa. Aufträge treffen so ein, wie es dem Kunden passt: Manche senden ein PDF-Auftragsformular, andere Freitext in einer E-Mail, wieder andere leiten einen Auszug aus ihrem eigenen System mit Anhängen weiter. Ein einheitliches Format gibt es nicht und wird es nicht geben: Das Unternehmen hat mehrere Dutzend Kunden, jeder mit eigenen Gewohnheiten.
Zwei Mitarbeitende der Disposition verbrachten den Großteil des Tages nicht mit Planen, sondern mit Abtippen: eine E-Mail öffnen, Be- und Entladeadressen, Termine, Gewicht, Paletten und Referenznummern heraussuchen, ins Transportmanagementsystem eingeben und dem Kunden antworten, dass der Auftrag eingegangen ist. An Spitzentagen warteten E-Mails mehrere Stunden in der Warteschlange, und Kunden riefen an, um zu fragen, ob der Auftrag angekommen sei.
Fehler waren das zweite Problem. Eine vertauschte Entladezeit oder ein übersehener Hinweis auf die Rampenhöhe bedeutete eine Leerfahrt oder eine Vertragsstrafe. Der Geschäftsführer rechnete aus, dass es monatlich einige solche Fälle gab und jeder mehr kostete als ein Tag Abtipparbeit. Das Unternehmen kam mit einer konkreten Frage zu uns: Kann KI solche E-Mails zuverlässig lesen, und ist das sicher?
Was erforderlich war
- Aufträge unabhängig vom Format aus E-Mails lesen: PDF, Freitext, Tabelle in der E-Mail, Anhänge.
- Automatisches Anlegen eines Datensatzes im Transportmanagementsystem mit allen erforderlichen Feldern.
- Bestätigung durch einen Menschen vor jedem Datensatz in den ersten Monaten und immer dann, wenn sich der Agent nicht sicher ist.
- Keine Verwendung von Kundendaten zum Training von Modellen; die Daten werden über die API zu vereinbarten Bedingungen verarbeitet.
- Einführung ohne Stillstand in der Disposition und ohne neue Software für die Mitarbeitenden.
Was wir getan haben
Wochen 1–2: E-Mail-Analyse und Regeln
Wir haben nicht mit der Technik begonnen, sondern mit den E-Mails. Wir haben den Auftragsverlauf mehrerer Monate durchgesehen und nach Format gruppiert: Etwa die Hälfte kam als PDF-Formular, ein Drittel als Freitext, der Rest war gemischt. Gemeinsam mit den Disponenten haben wir festgehalten, was in einem Auftrag zwingend enthalten sein muss, wann ein Auftrag als unklar gilt und an wen er dann gehen soll. Diese Regeln wurden zu den Anweisungen des Agenten.
Wochen 3–5: Agent und Integration
Den Agenten haben wir auf Basis eines Claude-Modells über die API gebaut. Der Agent liest eine neue E-Mail im Postfach, erkennt, ob es sich um einen Auftrag handelt, zerlegt sie in eine Struktur (Absender, Strecke, Zeitfenster, Ladung, Besonderheiten, Referenznummer) und prüft, ob alle Pflichtfelder gefüllt sind. Wenn ja, legt er über die API einen Entwurf im Transportmanagementsystem an und markiert die E-Mail als bearbeitet. Wenn nicht, schreibt er eine kurze Zusammenfassung dessen, was er lesen konnte und was fehlt, und gibt sie an einen Disponenten weiter. An anderer Stelle schreiben wir darüber, wie solche Claude-Agenten in Unternehmensprozessen arbeiten.
Am schwierigsten waren nicht die PDFs, sondern die Adressen: Kunden schreiben „zu unserem Lager“ oder nennen nur eine Stadt. Der Agent gleicht solche Fälle mit den Adressen früherer Aufträge des Kunden ab, und wenn die Zuordnung nicht eindeutig ist, gibt er den Auftrag an einen Menschen weiter, statt zu raten.
Wochen 6–8: Kontrolle und Lockerung der Bestätigungen
In den ersten vier Wochen wurde jeder vom Agenten angelegte Datensatz von einem Disponenten bestätigt, mit einem Klick, wobei E-Mail und ausgelesene Felder nebeneinander zu sehen waren. Wir haben Statistiken darüber gesammelt, wo der Agent Fehler macht. Danach haben wir die Bestätigung für Standardformulare von Stammkunden abgeschaltet und für Freitext-Aufträge und Aufträge neuer Kunden beibehalten. Das gehört zu unserem Ansatz der Prozessautomatisierung: so weit automatisieren, wie das Vertrauen gemessen wurde, und nicht weiter.
Ergebnis
Der Zeitaufwand für die manuelle Erfassung in der Disposition sank um etwa 65 %. Wir messen das ganz einfach: wie viele Aufträge pro Tag der Agent und wie viele ein Mensch angelegt hat und wie lange die Bestätigung im Durchschnitt dauert. Einer der beiden Mitarbeitenden arbeitet jetzt hauptsächlich an der Planung und mit den Frachtführern statt an der Tastatur.
Die Fehler in Aufträgen gingen um etwa 40 % zurück. Wir zählen Fälle, in denen ein Datensatz nach der Beladung korrigiert werden musste, und Leerfahrten durch falsche Daten. Die verbleibenden Fehler entstehen überwiegend in den E-Mails der Kunden selbst, und der Agent markiert sie wenigstens als Abweichung von früheren Aufträgen.
Die Bestätigung an den Kunden geht jetzt im Durchschnitt innerhalb von 20 Minuten nach Eingang der E-Mail raus; früher dauerte es in Spitzenzeiten etwa 2 Stunden. Kundenanrufe mit der Frage „Haben Sie es erhalten?“ sind fast verschwunden.
Wir hatten Angst, dass die KI Fehler macht, die wir erst an der Laderampe bemerken. Es kam umgekehrt: Der Agent merkt als Erster, wenn ein Kunde ein anderes Datum schickt als vor einer Woche.
Was wir in einer ähnlichen Situation raten
- Beginnen Sie beim E-Mail-Verlauf, nicht bei der Wahl des Modells. Die Regeln, was ein unklarer Auftrag ist, sind der wichtigste Teil des Systems.
- Behalten Sie die Bestätigung durch einen Menschen ab dem ersten Tag bei und lockern Sie sie nur dort, wo die Statistik zeigt, dass der Agent keine Fehler macht.
- Binden Sie das bestehende System über seine API an, statt einen neuen Arbeitsplatz zu bauen: Die Mitarbeitenden müssen das Ergebnis dort sehen, wo sie ohnehin arbeiten.
- Klären Sie die Datenbedingungen: wo verarbeitet wird, wie lange gespeichert wird und dass nicht für Training verwendet wird. Danach fragen Ihre Kunden als Erstes.
