Der Durchlauf war erfolgreich, der schwierige Fall blieb liegen
Eine Automatisierung ordnet eine Anfrage ein, findet den Kunden nicht und verschiebt den Vorgang in einen allgemeinen Fehlerordner. Das Dashboard meldet Abschluss. Der Kunde wartet weiterhin. Für die Statistik ist das ein Erfolg, für den Betrieb nicht.
Ein Fall sollte erst abgeschlossen sein, wenn sein fachliches Ergebnis feststeht. Ihn aus dem Hauptpfad zu nehmen kann richtig sein. Dadurch entsteht aber Arbeit für jemand anderen. Eine Ausnahmewarteschlange macht diese Arbeit sichtbar, zuweisbar und wiederaufnehmbar. Sie gehört von Beginn an zum Produkt.
Verschiedene Ursachen brauchen verschiedene Wege
Ein vorübergehend ausgefallener Dienst rechtfertigt möglicherweise einen neuen Versuch. Eine fehlende Bestellung verlangt einen Nachweis. Eine umstrittene Kündigung braucht eine fachliche Entscheidung. Alles in dieselbe Wiederholungsschleife zu stecken verbraucht Ressourcen und verdeckt den Stillstandsgrund. Ein Modell kann sich die fehlende Befugnis nicht durch weitere Versuche beschaffen.
Eine technische Dead-Letter-Queue hat einen engeren Zweck. Amazon SQS beschreibt, wie Nachrichten nach erfolglosen Verarbeitungsversuchen anhand einer Redrive-Richtlinie dorthin gelangen. Die SQS-Dokumentation liefert den Mechanismus, aber keine betriebliche Zuständigkeit.
Jede Ausnahme braucht einen bearbeitbaren Grund. Kunde nicht gefunden hilft, wenn mögliche Treffer und Vergleichsnachweise mitgeliefert werden. Ein allgemeines Etwas ist schiefgelaufen verlagert dagegen die gesamte Diagnose auf die bearbeitende Person.
Eine Fallansicht statt eines Protokollhaufens
Die Ansicht sollte das beabsichtigte Ergebnis, relevante Quellen, bereits erfolgte Aktionen und den Haltepunkt zeigen. Modellvorschläge müssen von bestätigten Daten unterscheidbar sein. Eine Regel- oder Workflow-Version gehört dazu, wenn sie die Beurteilung beeinflusst. Unbeteiligte Kundendaten bleiben verborgen, auch wenn sie im ursprünglichen Payload vorkamen.
Zuständigkeit und Alter des Falls müssen sichtbar sein. Die Priorität richtet sich nach den Folgen der Verzögerung, etwa einem blockierten Zugang, nicht nach der Lautstärke einer Fehlermeldung. In einer gemeinsamen Warteschlange ohne Zuweisung nimmt leicht jedes Team an, ein anderes kümmere sich darum.
Die verfügbaren Entscheidungen sollten tatsächliche Arbeit abbilden: Nachweis anfordern, Referenz berichtigen, zulässige Ausnahme freigeben, Anfrage ablehnen oder eskalieren. Freitext ergänzt den Kontext, ersetzt aber keinen strukturierten Entscheidungsnachweis. Erst dieser macht wiederkehrende Ursachen auswertbar.
Auch die Rückkehr in den Ablauf braucht Regeln
Ein Neustart ganz am Anfang kann bereits erledigte Aktionen wiederholen. Bei einer beispielhaften Kontoeröffnung könnte das Konto angelegt worden sein, bevor die Zugangszuweisung scheiterte. Die Reparatur darf kein weiteres Konto erzeugen. Kontrollpunkte und sicher wiederholbare Schritte müssen bekannt sein.
Vor der Fortsetzung werden aktueller Geschäftszustand und Berechtigungen erneut geprüft. Bis zur Korrektur könnte der Kunde zurückgetreten sein oder ein Kollege den Fall manuell abgeschlossen haben. Die Warteschlange muss erkennen, wenn der ursprüngliche Plan nicht mehr passt.
Unbequem ist die Kapazitätsfrage. Automatisierung kann Routine beschleunigen und gleichzeitig die schwierigsten Fälle bei einem kleineren Team bündeln. Fehlen dort Zeit oder Befugnis, wurde der Engpass nur verschoben. Neben automatischen Abschlüssen gehören deshalb Wartealter und wiederholte Ausnahmegründe in die Betriebsübersicht.
Diese Woche den Ausnahmeweg erproben
Einen ungelösten Vorgang auswählen oder für einen neuen Workflow einen repräsentativen Testfall anlegen. Fehlende Nachweise, Entscheidungskompetenz und mögliche Ergebnisse festhalten. Eine Person aus dem Betrieb sollte ihn ohne Rückfrage beim ursprünglichen Entwickler bearbeiten können.
Danach die Wiederaufnahme testen, nachdem sich der Geschäftsdatensatz verändert hat. Bereits erfolgte Aktionen dürfen nicht wiederholt werden, die Entscheidung muss dokumentiert sein. Eine erste Version darf wenig automatisieren. Für alles Unverstandene braucht sie trotzdem einen klaren Zielort.