Fallstudie: Fehlermeldungen mit automatischer Triage

Die Antwort vorweg: Fehlermeldungen in Unternehmensanwendungen sind genau die Art von Prozess, die sich vollständig automatisieren lässt: Der Benutzer klickt direkt in der Anwendung auf ein schwebendes Symbol, markiert die problematische Stelle auf einem Screenshot und sendet die Meldung ab. Das System ergänzt automatisch den technischen Kontext einschließlich der Fehler aus der Browserkonsole. Ein Sprachmodell fasst die Meldung zusammen und schlägt eine Priorität vor, während die Benachrichtigung bei Telegram eintrifft, noch bevor der Benutzer eine E-Mail fertig geschrieben hätte. Ein solches System haben wir für unseren eigenen Betrieb entwickelt. Es läuft zentral für mehrere Projekte, und zur Einbindung in eine weitere Anwendung genügt eine einzige Codezeile. Diese Fallstudie zeigt, wie das System im Inneren funktioniert und welche Erkenntnisse Sie daraus für die Automatisierung von Prozessen in Ihrem Unternehmen gewinnen können.

Über die Automatisierung von Geschäftsprozessen haben wir in unserem Blog bereits zwei allgemeine Artikel veröffentlicht: Welche Prozesse sich wirklich zu automatisieren lohnen und Sieben Prozesse, die Stunden sparen. Allgemeine Empfehlungen haben jedoch einen Nachteil: An ihnen lässt sich kaum zeigen, wie eine fertige Automatisierung aus der Nähe aussieht – wo sie beginnt, wo sie endet und welche Aufgaben weiterhin beim Menschen bleiben. Deshalb stellen wir diesmal ein konkretes Projekt aus unserem eigenen Betrieb vor: ein System für Fehlermeldungen, das wir für uns selbst entwickelt haben, weil wir keine Lust mehr auf das übliche „Es funktioniert nicht, schauen Sie bitte mal nach“ hatten.

Ausgangslage: „Es funktioniert nicht“ per E-Mail

Wir betreiben mehrere Webanwendungen – sowohl eigene als auch solche, die wir für Kunden entwickelt haben und verwalten. Bei jeder davon entsteht früher oder später derselbe Ablauf: Ein Benutzer stößt auf einen Fehler und muss ihn jemandem melden.

Ohne ein entsprechendes System sieht dieser Prozess jedes Mal gleich aus:

  1. Der Benutzer schreibt eine E-Mail oder ruft an: „Ich kann den Eintrag nicht speichern.“
  2. Der Techniker muss nachfragen: In welchem Browser? Auf welcher Seite? Worauf genau haben Sie geklickt? Können Sie einen Screenshot schicken?
  3. Der Benutzer beschäftigt sich inzwischen mit etwas anderem, antwortet erst einen Tag später und erinnert sich nicht mehr an die Hälfte der Details.
  4. Der Techniker versucht, den Fehler ohne ausreichende Informationen nachzustellen – häufig erfolglos, weil ein entscheidender Umstand in der Beschreibung fehlt.

Jede Runde dieser Schleife bedeutet Wartezeit auf beiden Seiten. Vor allem aber haben die Meldungen weder eine einheitliche Struktur noch eine gemeinsame Warteschlange. Eine kommt per E-Mail, die zweite telefonisch, die dritte wird bei einer Besprechung mündlich erwähnt – und die vierte geht vollständig verloren, weil der Benutzer „niemanden damit stören wollte“.

Nach der Checkliste aus unserem Artikel über Automatisierung ist dies ein Paradebeispiel für einen geeigneten Prozess: Er wiederholt sich, besitzt einen klaren Eingang und Ausgang (Fehler → strukturierte Meldung in einer Warteschlange) und wird derzeit durch manuelles Übertragen und wiederholte Rückfragen ausgebremst.

Die Aufgabe: Die Meldung entsteht dort, wo der Fehler auftritt – und landet in einer zentralen Warteschlange

Wir haben uns folgende Ziele gesetzt:

  • Der Benutzer meldet den Fehler direkt in der Anwendung, in der er darauf gestoßen ist – ohne E-Mail, ohne Fensterwechsel und ohne separat angefertigte Screenshots.
  • Jede Meldung besitzt dieselbe Struktur: einen Screenshot mit markierter Stelle, eine Beschreibung und den technischen Kontext.
  • Alle Anwendungen melden Fehler an eine zentrale Warteschlange – statt fünf Postfächern, fünf Formularen und fünf unterschiedlichen Vorgehensweisen.
  • Eine KI-Triage schlägt Priorität und Zusammenfassung vor, damit die Meldungen bereits sortiert sind, bevor ein Mensch die Warteschlange zum ersten Mal öffnet.
  • Das Team wird über neue Meldungen sofort bei Telegram benachrichtigt.

Aus Sicht des Benutzers: ein Käfer unten rechts

In der Ecke der Anwendung schwebt ein kleines Käfersymbol. Nach einem Klick öffnet sich ein Assistent mit drei Schritten:

  1. Stelle markieren. Das Widget erstellt eine Aufnahme des aktuellen Bildschirms, auf der der Benutzer mit einem Stift oder einem Auswahlrahmen kennzeichnet, wo das Problem liegt. Kein „Drücken Sie die Drucktaste und fügen Sie den Screenshot in eine E-Mail ein“ – die Markierung erfolgt direkt in der Anwendung.
  2. Problem beschreiben. Der Benutzer beschreibt kurz, was passiert ist und welches Verhalten er erwartet hatte. Wer nicht tippen möchte, kann die Beschreibung per Sprache diktieren.
  3. Prüfen und absenden. Der Benutzer sieht, welche Daten übermittelt werden, und bestätigt den Versand.

Der gesamte Vorgang dauert weniger lang als das Öffnen eines E-Mail-Programms. Entscheidend ist außerdem: Der Meldung werden automatisch Fehler aus der Browserkonsole beigefügt – also genau jene technischen Informationen, die ein normaler Benutzer niemals mitsenden würde, weil er nicht weiß, dass sie existieren.

Das Widget läuft in einem sogenannten Shadow DOM und ist dadurch vollständig von der Technologie der jeweiligen Seite unabhängig. Es beeinträchtigt die Gestaltung der Anwendung nicht und funktioniert gleichermaßen auf Websites, die mit React, einem älteren Content-Management-System oder als statische Seiten erstellt wurden.

Was nach dem Absenden passiert: Bereinigung, Triage und Telegram

Nun beginnt der interessantere Teil. Alle folgenden Schritte erfolgen ohne einen einzigen menschlichen Eingriff:

1. Bereinigung. Noch bevor die Meldung in die Datenbank geschrieben wird, durchläuft ihr Text einen Filter, der Passwörter, Token, E-Mail-Adressen, Telefonnummern und Geburtsnummern unkenntlich macht. Fügt ein Benutzer versehentlich ein Passwort in die Beschreibung ein, gelangt es nicht in die Warteschlange. Die Identität des Meldenden – Name und E-Mail-Adresse – bleibt dagegen erhalten, damit eine Rückmeldung möglich ist.

2. KI-Triage. Ein Sprachmodell liest die Meldung und ergänzt einen Prioritätsvorschlag sowie eine kurze Zusammenfassung. Dadurch ist die Warteschlange bereits sortiert, bevor ein Mensch sie zum ersten Mal öffnet: Ein Fehler beim Speichern rückt nach oben, während eine kosmetische Anmerkung zur Farbe einer Schaltfläche warten kann. Die Triage läuft über eine OpenAI-kompatible Schnittstelle, sodass sich das Modell auch lokal auf eigener Hardware betreiben lässt – Meldungen aus internen Anwendungen müssen das Unternehmen dann nicht verlassen.

3. Benachrichtigung bei Telegram. Unmittelbar nach dem Absenden erscheint im Chat eine Nachricht über die neue Meldung. Jedes Projekt kann dabei einen eigenen Kanal erhalten, sodass Benachrichtigungen aus der Anwendung eines Kunden nur diejenigen erreichen, die dafür zuständig sind.

4. Warteschlange im Administrationsbereich. Die zuständige Person sieht sämtliche Meldungen an einem Ort und kann sie nach Projekt, Status, Typ oder Priorität filtern. Zu jeder Meldung stehen der annotierte Screenshot, die Beschreibung, die Konsolenfehler und der Kontext zur Verfügung. Rückfragen entfallen, weil alle wesentlichen Informationen gleich beim ersten Mal eingegangen sind. Nach der Fehlerbehebung wird die Meldung als erledigt markiert.

Beachten Sie die Arbeitsteilung, die wir in jedem Text über KI betonen: Die Maschine sortiert und bereitet vor, der Mensch entscheidet und behebt das Problem. Die Triage schlägt die Priorität lediglich vor – sie weckt niemanden eigenständig und behebt auch keine Fehler. Das ist beabsichtigt. Das Erfassen einer Fehlermeldung ist ein Prozess mit klarem Eingang und Ausgang und damit ideal für die Automatisierung; die eigentliche Diagnose und Fehlerbehebung sind es nicht.

Sensible Daten: Was das System bewusst nicht speichert

Bei internen Tools wird häufig erst nach der Einführung über Sicherheit nachgedacht. Hier war sie von Anfang an Bestandteil der Anforderungen:

  • Unkenntlichmachung sensibler Daten vor dem Speichern. Passwörter, Token, E-Mail-Adressen, Telefonnummern und Geburtsnummern werden aus dem Meldungstext entfernt, bevor etwas gespeichert wird.
  • Screenshots außerhalb der öffentlichen Website. Bildschirmaufnahmen werden außerhalb öffentlich zugänglicher Dateien gespeichert und lassen sich ausschließlich über den geschützten Administrationsbereich anzeigen. Ein Screenshot aus einer internen Anwendung liegt somit niemals unter einer öffentlichen Adresse.
  • Herkunftskontrolle. Der Server akzeptiert Meldungen nur von Domains, die für das jeweilige Projekt registriert sind. Fremde Websites können die Warteschlange daher nicht mit unerwünschten Inhalten füllen.
  • Token-geschützter Administrationsbereich. Die Warteschlange ist nur mit einem geheimen Token zugänglich. Ohne dieses verweigert der Server den Zugriff.

Einbindung in ein weiteres System: eine einzige Codezeile

Das System wurde von Anfang an als zentraler Dienst für mehrere Projekte konzipiert. Die Einbindung in eine weitere Anwendung sieht folgendermaßen aus:

  1. In die Seite wird ein einziges <script>-Element eingefügt, das auf den zentralen Dienst verweist.
  2. Das Projekt erhält im Dienstregister einen Schlüssel, eine Liste zugelassener Domains und bei Bedarf einen eigenen Telegram-Kanal.
  3. Fertig – der Käfer erscheint in der Ecke, und die Meldungen laufen in der gemeinsamen Warteschlange ein.

In das System des Kunden muss nicht eingegriffen werden: keine Änderung an dessen Code, keine Installation auf seinem Server und keine Abhängigkeit davon, mit welcher Technologie die Website erstellt wurde. Der gesamte Dienst läuft dabei als einzelner Container auf unserem Server – ohne komplizierte Infrastruktur, die jemand zusätzlich warten müsste.

Erwähnenswert ist auch, wie das System entstanden ist. Rund 80 % des Codes haben wir aus einem Fehlermeldungsmodul übernommen, das wir ursprünglich für eine konkrete Anwendung zur Provisionsverwaltung entwickelt hatten, und anschließend für mehrere Projekte verallgemeinert. Als Nächstes integrierten wir es in unsere Anwendung zur Verwaltung von Inspektionen. Das ist der typische Verlauf einer guten Automatisierung: Sie entsteht nicht auf der grünen Wiese als Großprojekt, sondern durch die Verallgemeinerung einer Lösung, die sich bereits im produktiven Betrieb bewährt hat.

Was dadurch tatsächlich eingespart wird

Wir werden nicht behaupten, eine exakt bestimmte Zahl von Stunden eingespart zu haben – so haben wir es nicht gemessen. Die Einsparung wird jedoch unmittelbar an der Struktur des Prozesses deutlich:

  • Die Rückfrageschleife entfällt. Früher mussten Screenshot, Browserversion und Vorgehensweise in mehreren E-Mail-Runden zusammengetragen werden. Jetzt trifft alles beim ersten Mal ein – einschließlich der Konsolenfehler, die ein Benutzer selbst niemals mitgeschickt hätte.
  • Meldungen gehen nicht mehr verloren. Alles befindet sich mit einem eindeutigen Status in einer gemeinsamen Warteschlange. Nichts bleibt in einem E-Mail-Postfach, in Notizen zu einem Telefonat oder im Gedächtnis einer Person hängen.
  • Die Priorität ist sofort bekannt. Die Warteschlange wird von der Maschine vorsortiert, sodass kritische Probleme nicht zwischen Kleinigkeiten untergehen.
  • Die Hemmschwelle für Meldungen sinkt. Wenn eine Fehlermeldung mit drei Klicks direkt in der Anwendung erledigt ist, gilt nicht mehr: „Dafür schreibe ich keine extra E-Mail.“ Fehler erreichen die zuständige Person dadurch früher.

Was Sie daraus für die Automatisierung eigener Prozesse mitnehmen können

Dieses Projekt entspricht genau dem Rahmen, den wir in unseren allgemeinen Artikeln beschreiben:

  • Klarer Eingang und Ausgang. Fehler in der Anwendung → strukturierte Meldung in der Warteschlange. Es ist keine verantwortungsbehaftete Entscheidung erforderlich – eine ideale Aufgabe für die Automatisierung.
  • Der Mensch bleibt eingebunden. Die KI sortiert und fasst zusammen; Diagnose, Fehlerbehebung und Kommunikation mit dem Benutzer übernimmt ein Techniker.
  • Sensible Daten bleiben unter Kontrolle. Bereinigung vor dem Speichern, Screenshots außerhalb der öffentlichen Website und die Möglichkeit, ein lokal betriebenes Modell zu verwenden.
  • Klein anfangen, anschließend verallgemeinern. Zunächst entstand ein Modul in einer einzelnen Anwendung. Erst nachdem es sich bewährt hatte, wurde daraus ein zentraler Dienst für alle Projekte.

Dasselbe Muster lässt sich auf die Annahme von Bestellungen, Reklamationen, interne IT-Anfragen oder die Freigabe von Unterlagen übertragen – überall dort, wo heute unstrukturierte E-Mails hin- und hergeschickt und anschließend von Hand übertragen werden.

Falls Sie beim Lesen gedacht haben: „Das könnten wir ebenfalls gebrauchen“ – unabhängig davon, ob es um Fehlermeldungen oder einen ganz anderen Prozess geht, der in Ihrem Unternehmen heute noch über E-Mails und Rückfragen läuft –, entwickeln wir genau solche individuellen Automatisierungen für Unternehmen im Rahmen unseres Angebots IT für Unternehmen. Wir beginnen mit einer kurzen Beratung zu Ihrem konkreten Prozess und nicht mit einer Präsentation über künstliche Intelligenz. Sie erreichen uns über die Seite Kontakt. Und wenn Ihr Team solche Möglichkeiten künftig selbst erkennen soll, bieten wir dafür unsere KI-Schulung für Unternehmen an.

Häufig gestellte Fragen

Funktioniert das Widget nur in modernen Anwendungen?

Nein. Es wird mit einem einzigen Skript eingebunden und läuft dank Shadow DOM unabhängig von der Technologie der jeweiligen Seite – in einer modernen Single-Page-Anwendung ebenso wie in einem älteren Content-Management-System oder auf einer statischen Website. In den Anwendungscode muss nicht eingegriffen werden.

Was passiert, wenn ein Benutzer ein Passwort oder personenbezogene Daten in die Meldung schreibt?

Der Meldungstext wird vor dem Speichern bereinigt. Dabei werden Passwörter, Token, E-Mail-Adressen, Telefonnummern und Geburtsnummern unkenntlich gemacht. Name und E-Mail-Adresse des Meldenden bleiben erhalten, damit nach der Bearbeitung eine Rückmeldung möglich ist.

Ersetzt die KI-Triage einen Programmierer?

Nein – und das ist auch nicht das Ziel. Die Triage fasst die Meldung zusammen und schlägt eine Priorität vor. Dadurch öffnet der zuständige Mitarbeiter eine sortierte Warteschlange statt eines Stapels unstrukturierter E-Mails. Diagnose und Fehlerbehebung übernimmt immer ein Techniker.

Müssen die Daten aus den Meldungen in eine ausländische Cloud übertragen werden?

Nein. Der Dienst läuft auf einem eigenen Server, Screenshots werden außerhalb öffentlich zugänglicher Dateien gespeichert und die KI-Triage kann mit einem lokal betriebenen Modell erfolgen. Meldungen aus internen Anwendungen verlassen dann die Unternehmensinfrastruktur nicht.

Was kostet eine solche Automatisierung?

Das hängt vom Umfang und von der bereits vorhandenen Infrastruktur im Unternehmen ab. Deshalb erstellen wir ein konkretes Angebot erst nach einer kurzen Beratung zu Ihrem Prozess. Einen allgemeinen Kostenrahmen für KI in Unternehmen erläutern wir im Artikel Was kostet KI für ein Unternehmen?.

Wo Sie uns finden

ITHOPE ist eine Firma aus Brno, Tschechien: wir machen Datenrettung von Festplatten, RAID und NAS, PC- und Notebook-Service und IT für Unternehmen, alles im eigenen Labor in der Viniční 3587/216, 615 00 Brno.

Telefon +420 775 556 063 (rund um die Uhr). Das Gerät können Sie persönlich bringen oder per Kurier schicken (Zásilkovna, PPL).