"Wie erkennt ihr eine Portal-Änderung?" Bevor uns Daten fehlen. Diese Frage kommt oft. Meist am zweiten Tag im Onboarding. Wenn der Disponent versteht. Was ein Browser-Agent im Kundenportal wirklich tut. Meine Antwort ist selten die erwartete. Nicht bessere Selektoren. Ein Erwartungs-Check. Er fragt bei jedem Schritt. Ist die Seite noch die von gestern?
Meine These. Ein Portal ohne Schnittstelle ändert sich ohne Ankündigung. Der Betreiber tauscht ein Layout. Verschiebt eine Spalte. Baut ein neues Cookie-Banner ein. Der Agent merkt das nicht selbst. Er merkt nur, ob sein Code noch läuft. Und laufender Code meldet fast immer Erfolg. Auch ohne Ergebnis. Oder mit einem falschen.
Der Logistik-Benchmark 2025 prüfte 54 Unternehmen. 55 Prozent bieten ein Kundenportal an. Nur 20 Prozent davon liefern echten Funktionsnutzen. Der Rest ist ein Bildschirm. Gepflegt von außen. Ohne Rücksicht auf den Agenten, der ihn täglich besucht.
Fall eins: Das Portal zeigt eine leere Liste. Heißt das "nichts zu tun"? Oder verdeckt ein neues Banner die Tabelle? Ein naiver Agent sieht den Unterschied nicht. Beide Fälle liefern null Zeilen. Beide enden mit Exit-Code 0.
Fall zwei ist schlimmer. Das Portal tauscht zwei Spalten. Menge und Gewicht wechseln die Position. Der Agent liest weiter Spalte drei. Er bekommt eine Zahl. Nur die falsche. Kein Fehler, keine Warnung. Nur ein Wert, der plausibel aussieht.
Beide Fälle brauchen dieselbe Antwort. Ein Schritt darf nicht nur laufen. Er muss sein Ergebnis prüfen. Vier Checks reichen für die meisten Portale.
Ist das erwartete Element da? Nicht nur "die Seite hat geladen". Sondern: Das Element mit der Bedeutung Ergebnistabelle existiert.
Steht der erwartete Spaltenkopf in der Kopfzeile? Nicht an Position drei. Am eigenen Text erkannt.
Ist die Zeilenzahl plausibel, gemessen am Median der letzten Läufe? Drei statt achtzig Zeilen sind kein Beweis. Nur ein Grund zur Prüfung.
Sind die Pflichtfelder gefüllt? Eine Zeile ohne Referenznummer ist keine Zeile. Sie ist ein Parsing-Fehler mit Häkchen.
Bei einem Kunden lief so ein Check monatelang mit. Unauffällig. 4.869 Läufe zwischen Anfang Juni und Mitte September. 4.850 davon erfolgreich. Eine Quote von rund 99,6 Prozent. Am 23. Juli, zwischen 5:30 und 7 Uhr. Der Check eskaliert viermal in Folge. Von Warnung zu Fehler. Grund, maschinenlesbar. Zwei erwartete Spaltenköpfe fehlen in den ersten acht Zeilen. Die Meldung nennt die Ursache selbst. Jemand bearbeitet die Datei gerade. Eine halbe Stunde später lief der nächste Check wieder durch. Ohne einen einzigen Menschen. Der Check hatte den Ausrutscher richtig eingeordnet. Kein Alarm für die Disposition. Nur ein Wartesignal für sich selbst.
Ein Screenshot-Vergleich klingt naheliegend. Er scheitert an jedem Werbebanner. An jeder A/B-Variante. An jeder Bildschirmbreite. Der bessere Weg: ein struktureller Fingerprint der Seite. Nicht wie sie aussieht. Wie sie aufgebaut ist. Anzahl der Tabellenzeilen. Reihenfolge der Formularfelder. Ein Hash über die relevanten DOM-Knoten, ohne Werbung und Zeitstempel.
Aktuelle Ansätze im Web-Scraping kennen drei Stufen. Volltext-Hashing. Gefiltertes DOM-Hashing. Element-Level-Hashing für einzelne Felder. Für ein Portal reicht meist die mittlere Stufe. Der Hash über die Struktur, die der Agent wirklich anfasst. Ändert sich der Hash ohne Grund? Das ist ein Signal. Kein Beweis. Nur ein Signal, das den nächsten Lauf vorsichtiger macht.
Null Ergebnisse sind kein Fehler. Und keine Entwarnung. Sie sind eine offene Frage. Der Agent beantwortet sie selbst, mit einem von zwei Gründen. "Queue-empty" heißt: Heute liegt nichts an. Der Prozess dahinter ist leer. "Input-missing" heißt: Das Portal liefert nicht, was erwartet wird. Obwohl etwas anliegen sollte. Der erste Grund braucht keinen Menschen. Der zweite braucht einen, schnell. Ohne diese Trennung landen beide Fälle in derselben grünen Zeile. Mit ihr landet nur einer dort.
Ein einzelner Fehlversuch ist kein Beweis. Netzwerke ruckeln. Server antworten manchmal langsam. Der Kill-Switch greift erst nach einer festen Zahl an Fehlversuchen. Nicht nach dem ersten. Beim ersten Abweichen hält der Agent zwei Dinge fest. Einen Screenshot der Seite. Und den DOM-Auszug der Stelle. Dort, wo die Erwartung nicht passte. Das ist der Unterschied. Zwei Stunden Suche. Oder fünf Minuten Lesen.
Aus dem Auszug wird die Korrektur. Ein neuer Selektor. Ein neuer erwarteter Spaltenkopf. Ausgerollt wird sie nie direkt live. Erst im Test-Modus, gegen den letzten gespeicherten Zustand des Portals. Erst wenn der Test die neue Erwartung erfüllt. Dann geht sie live. Er bleibt bis dahin aktiv. Lieber ein pausierter Prozess. Als einer, der falsche Zahlen für echt hält.
An einem normalen Tag sieht der Disponent nichts. Grün, Zeile für Zeile, wie erwartet. An dem Tag, an dem sich das Portal ändert, ist das anders. Er sieht einen pausierten Prozess. Mit einem Grund in Klartext. Nicht "Fehler 500". Sondern "erwarteter Spaltenkopf fehlt, Screenshot anbei". Genau das ist der Unterschied. Ein Ausfall, den jemand sofort merkt. Oder einer, der drei Tage lang falsche Zahlen schreibt.
Ein gesunder Lauf hat sein eigenes Protokoll. Schritt für Schritt. Das zeigt So läuft ein Browser-Agent im Kundenportal. Ein Portal ohne Schnittstelle ist trotzdem kein Blocker. Das steht in Ein Kundenportal ohne Schnittstelle ist kein Blocker. Und ein fehlerfreier Lauf ohne Ergebnis ist immer ein Ausfall. In jeder Automatisierung. Das erklärt "Job lief" ist kein Gesundheitsbeweis. Dieser Beitrag bleibt bei der Erkennung selbst.
Drei ehrliche Grenzen.
Manche Portale randomisieren ihre Struktur pro Sitzung. Aus Sicherheitsgründen. Oder wegen eines Frontend-Frameworks, das jede Klasse neu benennt. Dort schlägt ein Fingerprint ständig Alarm, für nichts. Dann bleibt nur der inhaltliche Check. Spaltenkopf und Pflichtfeld, kein Hash.
Ein zu empfindlicher Fingerprint erzeugt seinen eigenen Leerlauf-Fall. Jede harmlose A/B-Variante pausiert den Prozess. Die Schwelle braucht eine Kalibrierung. Keine einmalige Einstellung.
Und die schwerste Grenze. Der Check findet nur, was er erwartet. Ändert das Portal die Bedeutung eines Feldes? Ohne das Format zu ändern? "Erledigt" wird zu "in Bearbeitung", gleicher Datentyp. Der Check sieht nichts Falsches. Das ist kein Fehler der Technik. Das ist die Grenze jeder automatisierten Erwartung. Sie prüft, was sie vorher wusste.
Vier Checks je Schritt. Ein Fingerprint der relevanten DOM-Knoten. Zwei Leerlauf-Gründe statt einem stillen Nichts. Ein Kill-Switch nach fester Fehlerzahl. Mit Screenshot und Auszug beim ersten Abweichen. Eine Korrektur, erst im Test, dann live. Nichts davon ist exotisch. Neu ist nur, dass es für jedes Kundenportal existiert. Nicht nur für das eigene System.
Welches Ihrer Portale hat sein Layout geändert? Ohne dass es jemand merkte? Schreiben Sie mir die Antwort, auch "keine Ahnung". Dann zeige ich Ihnen den Check dafür. Im Prozess-Check, für dieses Portal.
