Diesen Mittwoch stand ein Lauf in unserem Protokoll. 5.255 Aufträge geprüft. 1.602 Mengen geändert. Dauer: 57 Minuten. Kein Mensch hat dabei ein Portal geöffnet. Am Dienstag davor waren es 2.051 Aufträge und 550 Änderungen. Der Unterschied kam nicht vom Agenten. Er kam vom Kunden. Mittwoch ist bei diesem Logistiker der Tag der Korrekturen.
Darum geht es in diesem Beitrag. Ein Kundenportal ohne Schnittstelle ist kein technisches Hindernis. Es ist ein Prozess mit einer bekannten Oberfläche: dem Bildschirm. Wer ihn automatisiert, spart nicht nur Klicks. Er bekommt zum ersten Mal ein Protokoll. Es zeigt, was in dem Portal jeden Tag passiert.
Speditionen kennen das Muster. Wir sehen es in fast jedem Logistikprojekt. Der Kunde stellt ein Portal. Dort werden Aufträge bestätigt. Mengenänderungen laufen über dieselbe Maske. Eine API gibt es nicht. Oder sie kostet extra. Oder sie steht in der Roadmap für übernächstes Jahr. Also loggt sich jeden Morgen jemand ein.
Die Zahlen dazu sind nicht neu, aber deutlich. Strategy& und die BVL haben im November 2025 115 Logistiker befragt. Aus Deutschland, Österreich und der Schweiz. 96 Prozent haben die digitale Transformation gestartet. 10 Prozent schaffen es, neue Technik zu skalieren. Zwei Drittel nennen den eigenen Reifegrad niedrig bis mittel.
Auf der anderen Seite des Tisches sieht es ähnlich aus. Der Logistik-Benchmark 2025 (Team Neusta, Netfederation) hat 54 große Logistiker geprüft. 55 Prozent bieten ein Kundenportal. Nur 20 Prozent liefern darin echten Nutzen, etwa aktive Meldungen. Portale wachsen schneller als Schnittstellen. Wer auf die API wartet, wartet auf etwas, das die andere Seite selten baut.
In unseren Gesprächen mit Disponenten kommt eine Ebene dazu. Sie steht in keiner Studie: Slot-Buchungen. Für jede Anlieferung braucht es ein Zeitfenster. Das bucht der Disponent im Portal des Lagerbetreibers. Je nach Empfänger ist das Transporeon, Cargoclix oder ein eigenes Portal. Jedes hat einen eigenen Login. Ein Auftrag, drei Portale, drei Passwörter. (Drei Passwörter, die genau eine Person kennt. Das ist kein Sicherheitsproblem. Das ist ein Urlaubsproblem.)
Für einen Agenten ist ein Portal dasselbe wie für einen Disponenten. Eine Login-Maske, eine Liste, ein Formular, ein Button. Der Unterschied liegt in der Bedienung.
So ist unser Bestätigungs-Agent gebaut, der die Zahlen vom Anfang liefert:
Erstens läuft er in einem eigenen Browser-Profil auf einer eigenen Maschine. Das Profil hält die Sitzung. Der Agent meldet sich nicht bei jedem Lauf neu an. Wenn doch, ist die Anmeldung ein eigener Schritt im Protokoll.
Zweitens spricht er das Portal über Selektoren an, nicht über Koordinaten. Ein Button heißt im Seitencode "Bestätigen", nicht "Position 812, 340". Ändert der Kunde das Layout, findet der Agent den Button trotzdem. Ändert der Kunde den Namen des Buttons, bricht der Schritt ab, und genau das soll er.
Drittens schreibt er ein Protokoll je Schritt. Login, Liste geladen, Auftrag 4711 geöffnet, Menge 12 statt 10 erkannt, Änderung gespeichert. Jede Zeile hat einen Zeitstempel und ein Ergebnis. Aus diesen Zeilen entstehen die Kennzahlen: Aufträge geprüft, Änderungen gebucht, Dauer, Fehler.
Viertens gibt es eine Prüfliste mit Grund. Manchmal kann der Agent einen Auftrag nicht bestätigen. Die Menge ist nicht plausibel, oder ein Artikel fehlt. Dann legt er ihn nicht stumm zur Seite. Er schreibt ihn mit dem Grund in eine Liste. Die Disposition sieht diese Liste am Morgen.
Fünftens läuft alles über einen Monitor, der jeden Lauf kennt. In acht Wochen hat dieser Agent 39 Läufe gemacht, 35 davon sauber. Vier brachen ab. Alle vier mit demselben Fehler: Der Browser wurde während des Laufs geschlossen. Das Portal war nicht das Problem. An allen vier Tagen lief ein zweiter Lauf sauber durch. Der Monitor zeigt beides mit Uhrzeit, den Abbruch und den Zweitlauf.
Das ist die Stelle, an der sich der Agent von einem Makro unterscheidet. Ein Makro klickt. Ein Agent klickt, protokolliert, erkennt, wann er aufhören muss, und sagt Bescheid.
Die Ersparnis ist das kleinste Ergebnis. Die Handarbeit im Portal fällt jeden Morgen weg. Das rechnet jeder Geschäftsführer in zwei Minuten aus.
Interessanter ist, was in den Protokollzeilen steht. Nehmen wir den Logistiker mit den 5.255 Aufträgen. Vor dem Agenten wusste niemand, wie die Änderungsquote über die Woche verläuft. Jetzt ist es klar: Mittwoch 23 bis 33 Prozent. Montag 11 bis 16 Prozent. Donnerstag null. Acht Wochen lang, jede Woche dasselbe Muster. Es steht jetzt in einer Tabelle. Die Disposition kann den Mittwoch anders besetzen. Und der Vertrieb kann mit dem Kunden über die Erstbestellungen sprechen. Mit Zahlen statt mit Gefühl.
Das Gleiche gilt für die Prüfliste. Jeder Grund darin ist ein Datenproblem des Kunden. Fehlende Artikelnummern. Mengen ohne Einheit. Adressen, die im eigenen System anders heißen. Vorher hat der Disponent das im Kopf korrigiert und nie notiert. Jetzt steht jeder Fall mit Datum da.
Ein ehrlicher Vorbehalt: Das sind unsere eigenen Betriebsdaten aus wenigen Projekten, keine Marktstudie. Die 30 Prozent am Mittwoch gelten für diesen einen Kunden. Ob ein anderes Portal ähnlich aussieht, wissen wir erst mit einem Protokoll dort.
Drei Fälle, in denen der Browser-Agent nicht die richtige Antwort ist.
Erstens Portale mit Captcha oder Zwei-Faktor-Anmeldung per Hardware-Token. Ein Mail-Code lässt sich lesen, ein Token in der Schublade nicht.
Zweitens Portale, die den Kunden vertraglich zur manuellen Bedienung verpflichten. Das ist selten, es kommt vor, und es gehört vor dem ersten Lauf geklärt.
Drittens der Fall, dass die API doch existiert und bezahlbar ist. Dann ist die API das bessere Projekt. Sie liefert Daten statt Bildschirme. Der Agent ist die Antwort auf "keine Schnittstelle". Er ersetzt keine vorhandene.
Ein vierter Punkt ist kein Bruch, aber eine Bedingung. Ohne Protokoll und Prüfliste ist ein Browser-Agent ein Risiko. Er bestätigt dann Aufträge, die niemand prüft. Der Fehler fällt erst beim Kunden auf. Die Ersparnis ohne das Protokoll bauen wir nicht.
Ein Browser mit eigenem Profil. Ein Skript, das Selektoren statt Bilder nutzt. Ein Postfach für Anmeldecodes. Eine Tabelle für das Protokoll. Ein Monitor, der Läufe zählt und beim Ausbleiben alarmiert. Nichts davon ist exotisch. Der Aufwand steckt in der Prüfliste und in den Fehlerpfaden, nicht in den Klicks.
Die Slot-Portale sind der nächste Schritt. Ein Auftrag, drei Plattformen, ein Agent. Er bucht die Zeitfenster und schreibt die Bestätigungen ins TMS. Die Mechanik ist dieselbe. Der Unterschied: Dort ändern drei Betreiber ihre Oberflächen, nicht einer.
Welches Portal kostet Ihre Disposition die meisten Minuten am Tag? Schreiben Sie es mir, ich sammle diese Fälle.
