Freitag, 16:43 Uhr. Ein Kunde ruft an und möchte für Montag einen Termin. Der Voice-Agent versteht die Anfrage, aber das Buchungssystem liefert Timeout. Beim nächsten Versuch wieder. Die schlechteste Reaktion wäre: „Termin ist bestätigt“ und hoffen, dass der Schreibvorgang später irgendwie durchgeht.
Die zweit-schlechteste wäre, das Gespräch einfach zu verlieren.
Dazwischen liegt der reduzierte Betrieb: Die Automation bietet weniger Funktionen, aber sie bleibt ehrlich und kontrollierbar. Sie nimmt Kontaktdaten und Terminwunsch auf, verspricht keinen Slot, legt den Vorgang in eine sichtbare Warteschlange und sagt klar, dass die definitive Bestätigung folgt.
Das Prinzip ist in resilienten Softwaresystemen längst normal. Circuit-Breaker-Patterns verhindern, dass ein fehlerhafter externer Dienst endlos weiter angefragt wird. Betriebsüberwachung hilft zu erkennen, ob eine Abhängigkeit verfügbar ist. Für KMU-Automation muss daraus kein kompliziertes Cloud-Projekt werden. Es braucht vor allem eine klare Antwort auf: Was darf noch passieren, wenn ein Teil nicht mehr funktioniert?
Reduzierter Betrieb beginnt mit einer Übersicht erlaubter Funktionen
„API ausgefallen“ ist zu grob. Vielleicht ist das Sprachmodell erreichbar, aber CRM nicht. Vielleicht kann der Kalender gelesen, aber nicht beschrieben werden. Vielleicht ist nur ein Zahlungsanbieter gestört.
Definieren Sie pro Workflow drei Zustände: normal, reduziert, gestoppt.
Im Normalmodus darf der Agent lesen, entscheiden und ausführen, was im Prozess vorgesehen ist. Im reduzierten Betrieb bleiben sichere Funktionen aktiv: Anfrage erfassen, Informationen aus stabilen Quellen geben, Rückruf aufnehmen, Job in Warteschlange schreiben. Aktionen, die einen Live-Zustand brauchen — Verfügbarkeit zusagen, Zahlung bestätigen, Bestellung finalisieren — werden gestoppt.
Im Stop-Modus geht selbst das nicht mehr zuverlässig. Dann braucht es einen einfachen menschlichen Eingangskanal.
Bestätigter Fakt: Ausfallsicherheit-Patterns wie Circuit Breaker und Zustandsprüfungen dienen dazu, fehlerhafte Abhängigkeiten zu erkennen und kaskadierende Probleme zu reduzieren.
Empfehlung: Definieren Sie die reduzierte Betriebsart fachlich, nicht erst technisch nach dem Ausfall.
Der häufigste Fehler: aus „nicht erreichbar“ wird „wahrscheinlich okay“
AI-Systeme sind darauf optimiert, weiterzuhelfen. Das ist im Gespräch angenehm, bei kaputten Integrationen gefährlich.
Wenn der Kalender nicht antwortet, darf das Modell nicht aus alten Daten oder Gesprächskontext ableiten, dass 10 Uhr „vermutlich frei“ ist. Wenn das CRM-Schreibvorgang scheitert, darf die Benutzeroberfläche nicht trotzdem „Kunde angelegt“ anzeigen. Wenn der Zahlungsanbieter keine Bestätigung liefert, ist „bezahlt“ kein zulässiger Ersatzstatus.
Ein reduzierter Betrieb braucht deshalb klare negative Regeln: Bei fehlender Quelle keine verbindliche Zusage; bei fehlgeschlagenem Schreibvorgang keine Erfolgsmeldung; bei unbekanntem Status kein automatischer Wiederholungsversuch ohne Idempotenz und Warteschlange-Kontrolle.
Beispiel Hotel: PMS nicht verfügbar. Der Assistent kann Zimmerwunsch, Daten, Personenanzahl und Kontaktdaten aufnehmen. Er kann aber keine live Verfügbarkeit oder endgültige Rate versprechen, wenn diese Informationen vom ausgefallenen System abhängen.
Warteschlange statt Gedächtnis
Der wichtigste Baustein im reduzierten Betrieb ist oft langweilig: eine sichtbare Warteschlange.
Jeder nicht ausführbare Vorgang bekommt eine ID, Zeitpunkt, gewünschte Aktion, Kundendaten, Grund des Aufschubs und Verantwortlicher. Der Kunde erhält einen realistischen Status: „Anfrage aufgenommen, Bestätigung folgt“, nicht „erledigt“.
Nach Wiederherstellung darf die Warteschlange nicht blind abgespielt werden. Während des Ausfalls können Mitarbeitende Aufgaben manuell erledigt haben, Kunden können erneut angerufen oder ihre Meinung geändert haben.
Darum lautet der Wiederanlauf:
- Abhängigkeit gesund prüfen, nicht nur „HTTP 200 einmal gesehen“.
- Neue Arbeit zunächst begrenzt zulassen, damit der Fehler nicht sofort wieder skaliert.
- Warteschlange nach Alter und Kritikalität sortieren.
- Vor erneuter Verarbeitung Zielzustand prüfen, damit man keine manuell erledigte Aufgabe doppelt ausführt.
- Veraltete Aufgaben markieren. Ein Terminwunsch von vor sechs Stunden kann eine neue Bestätigung brauchen.
- Ausnahmen einem Verantwortlichen geben, statt sie in „retry failed“ verschwinden zu lassen.
Das ist der Punkt, an dem der reduzierte Betrieb und der Ergebnisabgleich zusammenkommen.
Kundenkommunikation ist Teil der Ausfallsicherheit
Technikteams denken bei Ausfällen an Retries. Kunden denken an Zusagen.
Ein Assistent sollte den reduzierten Zustand in normaler Sprache ausdrücken: „Unser Buchungssystem ist gerade nicht erreichbar. Ich kann Ihren Wunsch aufnehmen und wir bestätigen den Termin, sobald der Zugriff wieder da ist.“
Das wirkt vielleicht weniger beeindruckend als eine vollautomatische Buchung, ist aber besser als eine falsche Bestätigung.
Nicht jeder technische Fehler muss dem Kunden im Detail erklärt werden. „API error 503“ ist keine sinnvolle Information. Aber die geschäftliche Konsequenz muss klar sein: Anfrage aufgenommen, noch nicht bestätigt; Zahlung noch nicht verifiziert; Rückruf folgt.
Übergabe an Menschen bekommt Priorität, wenn das Anliegen zeitkritisch ist. Ein Notdienst, eine Anreise am selben Abend oder ein Kunde, der bereits vor Ort steht, sollte nicht sechs Stunden in einer Warteschlange warten, nur weil das System theoretisch später wiederkommt.
Minimaler Pilot: Ziehen Sie absichtlich den Stecker
Der Test ist einfach: Nehmen Sie eine externe Abhängigkeit in einer Testumgebung offline. Prüfen Sie, was der Agent sagt, welche Schreibvorgänge er versucht, ob die Warteschlange vollständig ist und wie der Wiederanlauf funktioniert.
Messen Sie Zeit bis zur Erkennung des Ausfalls, Anteil der Anfragen, die im reduzierten Betrieb korrekt erfasst werden, Anzahl falscher Erfolgs- oder Bestätigungszustände, Alter der Warteschlange bis zur Bearbeitung, Anteil der Jobs, die nach Wiederherstellung ohne Duplikat abgeschlossen werden, und Zeit bis zur Übergabe bei zeitkritischen Fällen.
Ein guter Wert ist nicht „100 Prozent Automation verfügbar“. Manchmal ist der sichere Erfolg gerade, eine Funktion bewusst nicht anzubieten.
Ein robuster AI-Agent muss nicht immer alles können. Er muss wissen, wann er weniger kann. Für ein KMU ist der beste reduzierte Betrieb einer, der Kundenkontakte nicht verliert, keine falschen Versprechen macht und offene Arbeit so speichert, dass ein Mensch sie übernehmen und später sauber abschliessen kann.
Beim Wiederanlauf werden alte Fälle nicht blind nochmals gesendet. Prüfen Sie zuerst, ob die Zielaktion vielleicht doch ausgeführt wurde. Genau hier treffen Schutz vor Doppelaktionen und Reconciliation auf den reduzierten Modus.
Quellen
FAQ
Ist der reduzierte Betrieb einfach ein Wiederholungsversuch?
Nein. Ein Wiederholungsversuch ist nur eine technische Taktik. Der reduzierte Betrieb ändert bewusst, welche Geschäftsfunktionen erlaubt sind.
Darf der Agent bei Kalenderausfall einen Slot „provisorisch“ bestätigen?
Nur wenn Ihr Prozess wirklich einen separaten, konfliktfreien Reservationsmechanismus hat. Sonst sollte er den Wunsch aufnehmen, nicht die Verfügbarkeit behaupten.
Was passiert mit alten Jobs nach Wiederherstellung?
Sie müssen vor erneuter Verarbeitung gegen den aktuellen Zielzustand geprüft werden, weil Menschen oder Kunden inzwischen Änderungen vorgenommen haben können.
Braucht jedes kleine KMU Betriebsüberwachung?
Für kritische Abhängigkeiten ist zumindest ein einfacher Prüfung der Verfügbarkeit und möglicher Fehler sinnvoll. Die Lösung muss nicht komplex sein.
Wann geht ein Fall sofort an einen Menschen?
Wenn Zeitkritik, Sicherheitsrelevanz oder wirtschaftliche Auswirkung das Warten auf die automatische Wiederherstellung unvernünftig machen.