KI-Telefonassistent bei Ausfall: Notbetrieb, Fallback und Wiederanlauf richtig planen

Ein Telefonat ist eine Kette – nicht ein einzelner KI-Dienst

Die Aussage „unsere KI war erreichbar“ kann fachlich wertlos sein, wenn die Rufnummer nicht zugestellt wurde oder kein Kalender antwortete. Vor jeder Verfügbarkeitsdiskussion braucht das Unternehmen eine Abhängigkeitskarte vom Anrufer bis zum abgeschlossenen Vorgang.

1. Öffentliches Telefonnetz und Carrier: Der Anruf muss zur richtigen Rufnummer gelangen.
2. Nummernverwaltung und Routing: Die Zielnummer muss auf den produktiven Dienst oder den Ersatzweg zeigen.
3. Sprachstrecke: Audioannahme, Spracherkennung, Dialog und Sprachausgabe müssen zusammenarbeiten.
4. Wissen und Regeln: Der Assistent benötigt gültige, freigegebene Antworten und Grenzen.
5. Werkzeuge: Kalender, CRM, Ticketsystem oder Warenwirtschaft führen Aktionen aus.
6. Menschliche Ziele: Teams, Mobiltelefone oder Bereitschaften müssen erreichbar und zuständig sein.
7. Benachrichtigung und Nachweis: Fehler, Rückrufe und offene Vorgänge brauchen Alarm, Eigentümer und Status.

Jede Kante kann ausfallen, langsam werden oder nur teilweise falsche Ergebnisse liefern. Deshalb ist „Uptime“ allein zu grob. Eine Plattform kann erreichbar sein und dennoch Termine doppelt buchen; ein Zielsystem kann schreiben, aber seine Antwort verlieren; ein Weiterleitungsziel kann klingeln, ohne dass jemand annimmt.

Anrufpfad und Steuerungsebene getrennt betrachten

Der laufende Anrufpfad sollte nicht unnötig von einer Administrationsoberfläche abhängen. Ist nur das Dashboard gestört, können bestehende Regeln häufig weiterlaufen. Umgekehrt kann ein grünes Dashboard nicht beweisen, dass ein echter Anruf zugestellt wird. Überwacht werden deshalb zwei Ebenen: synthetische Testanrufe prüfen den Kundenweg, technische Checks prüfen einzelne Dienste.

Sechs Ausfallarten brauchen sechs unterschiedliche Reaktionen

Ob eine cloudbasierte Telefon-KI beim Internetausfall im Büro weiterarbeitet, hängt vom tatsächlichen Anrufpfad ab. Liegen Rufnummer, Routing und KI außerhalb des Standorts, kann die Rufannahme weiterlaufen, obwohl Tischtelefone und interne Systeme offline sind. Führt die Verbindung hingegen durch eine lokale Anlage oder einen lokalen Session Border Controller, kann genau dieser Anschluss zum Engpass werden. Das lässt sich nicht aus einem Architekturdiagramm beweisen – der Büroanschluss muss im Test wirklich getrennt werden.

MTPD, RTO und RPO: vom Geschäftsprozess her definieren

Das BSI ordnet im Standard 200-4 Business Continuity Management als Managementsystem ein. Für Telefon-KI bedeutet das: Ziele werden nicht aus einer Anbieterbroschüre übernommen, sondern aus der Business-Impact-Analyse des eigenen Prozesses abgeleitet.

• MTPD: Wie lange darf der Geschäftsprozess höchstens beeinträchtigt sein, bevor die Folgen nicht mehr akzeptabel sind?
• RTO: Innerhalb welcher Zielzeit muss ein definierter Mindest- oder Normalbetrieb wiederhergestellt sein?
• RPO: Welcher Datenstand beziehungsweise welcher maximale Datenverlust ist beim Wiederanlauf tolerierbar?

Die Begriffe sollten im Projekt immer mit Messpunkt und Zielzustand konkretisiert werden. „RTO 30 Minuten“ ist unvollständig. Besser: „Spätestens 30 Minuten nach bestätigtem Ausfall der KI-Strecke nimmt die Service-Rufnummer Anrufer über die unabhängige Warteschlange an.“ Das ist prüfbar.

Für Terminwünsche kann der tolerierbare Datenverlust null sein, obwohl eine verzögerte Bestätigung akzeptabel ist. Dann erhält jeder aufgenommene Vorgang sofort eine eindeutige Ereignis-ID und wird dauerhaft in einer separaten Warteschlange gesichert. Die Zielsystembuchung darf später erfolgen, aber keine Anfrage verschwinden.

Prioritäten nach Wirkung, nicht nach technischer Größe

Eine kleine Störung kann hohe Wirkung haben: Wenn nur die Storno-Funktion ausfällt, entstehen vielleicht teure Leertermine. Umgekehrt kann der Ausfall eines Analyse-Dashboards den Kundendienst kaum betreffen. Priorisiert werden daher konkrete Dienstleistungen wie „Notfallanruf annehmen“, „Terminwunsch sichern“ oder „Rückruf zustellen“ – nicht abstrakte Komponenten.

Eine Fallback-Kette ist nur so gut wie ihre Unabhängigkeit

Der häufigste Planungsfehler ist ein Ersatzweg, der denselben Single Point of Failure nutzt. Eine zweite Rufgruppe beim gleichen nicht erreichbaren Standort hilft bei dessen Stromausfall wenig. Eine Notansage aus derselben ausgefallenen KI-Plattform ist ebenfalls kein unabhängiger Fallback.

Eine einfache Kette kann so aussehen:

1. Normalbetrieb über Telefon-KI und Zielsysteme.
2. Bei Werkzeugfehlern: KI nimmt strukturiert auf, kennzeichnet „noch nicht verbucht“ und stellt später zu.
3. Bei KI-Fehlern: unabhängiges Telefonrouting zu einem menschlichen Pool oder schlanker Rückrufannahme.
4. Bei Ausfall der primären Rufroute: vorbereitete Carrier-Umleitung oder öffentlich dokumentierte Ersatznummer.
5. Bei vollständiger Nichtverfügbarkeit: aktuelle Statusinformation über einen getrennt betriebenen Kanal.

Praktische Telekommunikationsanbieter stellen für Anschlussstörungen teils Umleitungsfunktionen bereit; die Deutsche Telekom beschreibt beispielsweise Erreichbarkeitslösungen bei Störungen. Ob und wie schnell eine konkrete Umleitung greift, muss mit dem eigenen Vertrag und Produkt geprüft werden.

Automatisch umschalten – aber nicht unbemerkt

Automatisches Failover verkürzt die Unterbrechung, kann jedoch einen Fehler kaschieren. Jede Umschaltung erzeugt daher einen Alarm mit Startzeit, betroffener Route und aktivem Betriebsmodus. Das Team sieht nicht nur „Dienst verfügbar“, sondern „Dienst läuft seit 10:17 Uhr im Modus Rückrufannahme“.

Manuelle Umschaltung bleibt für Grenzfälle sinnvoll, darf aber nicht von einer einzelnen Person mit Laptop und Passwort abhängen. Mindestens zwei Rollen kennen den Ablauf; Zugang, Freigabe und Rückweg sind dokumentiert.

Im Notbetrieb nur bestätigen, was wirklich gesichert ist

Störungen werden zum Vertrauensproblem, wenn der Assistent Normalbetrieb vorspielt. Die Formulierung richtet sich nach dem nachgewiesenen Zustand:

Ein Notdialog ist bewusst kürzer als der Normaldialog. Er sammelt nur Informationen, die für den Ersatzprozess nötig sind: Kontaktweg, Anliegen, Dringlichkeit soweit fachlich definiert, Rückrufzeit und Standort. Zusätzliche Fragen erhöhen in einer Störung nur Abbruchquote und Datenmenge.

Wiederanlauf: Zurückschalten ist erst die halbe Arbeit

Nach Wiederherstellung treffen neue Anrufe, gepufferte Vorgänge und manuelle Ersatzprozesse aufeinander. Ohne Abgleich entstehen Doppeltermine und doppelte Rückrufe. Jeder Notvorgang benötigt deshalb eine stabile Ereignis-ID, Zeitstempel und einen klaren Status.

1. Stabilität der reparierten Strecke mit synthetischen Anrufen und echten Zielaktionen prüfen.
2. Neue Anrufe kontrolliert zurückschalten, nicht zugleich alle Puffer freigeben.
3. Zwischengespeicherte Vorgänge in Reihenfolge und mit begrenzter Geschwindigkeit nachliefern.
4. Vor jeder Wirkung prüfen, ob ein Mitarbeiter den Vorgang bereits manuell erledigt hat.
5. Technische Wiederholungen mit derselben Ereignis-ID idempotent ausführen.
6. Unklare Konflikte in eine menschliche Prüfliste geben.
7. Erst nach vollständigem Abgleich den Vorfall schließen.

Ein Timeout ist mehrdeutig: Das Zielsystem kann geschrieben haben, obwohl seine Antwort nicht zurückkam. Bei einem Retry darf deshalb nicht blind ein zweiter Datensatz entstehen. Der Vorgang wird anhand seiner Ereignis-ID gesucht oder über eine idempotente Schnittstelle erneut eingereicht. Details zur sicheren Zielsystemanbindung erklärt der Leitfaden zur CRM-Integration.

25 Abnahmetests für Ausfall, Notbetrieb und Rückkehr

1. Ein realer Testanruf erreicht im Normalbetrieb den vorgesehenen Assistenten.
2. Der Ausfall des Kalenders aktiviert den Modus „Terminwunsch“, nicht eine erfundene Buchung.
3. Der CRM-Ausfall puffert einen Vorgang mit eindeutiger Ereignis-ID.
4. Ein Timeout nach erfolgreichem Schreiben erzeugt beim Retry keine Dublette.
5. Eine veraltete Wissensquelle blockiert zeitkritische Auskünfte.
6. Der Ausfall der KI-Strecke wechselt innerhalb der Zielzeit auf den Ersatzweg.
7. Die Ersatzroute funktioniert ohne Administrationsoberfläche der KI-Plattform.
8. Ein ausgefallenes Weiterleitungsziel führt zum nächsten definierten Schritt.
9. Besetzt, Nichtannahme und technische Nichterreichbarkeit werden unterschieden.
10. Der Internetausfall im Büro wird durch physische Trennung getestet.
11. Beim lokalen Stromausfall bleibt die externe Rufannahme erreichbar, sofern so geplant.
12. Der Ausfall des primären Carriers prüft eine wirklich unabhängige Route oder Ersatznummer.
13. Jede automatische Umschaltung erzeugt einen Alarm mit aktivem Betriebsmodus.
14. Alarmempfänger bestätigen innerhalb der festgelegten Reaktionszeit.
15. Der Notdialog sammelt nur die minimal erforderlichen Angaben.
16. Die Kundenbotschaft unterscheidet Aufnahme, Vormerkung und bestätigte Aktion.
17. Notvorgänge bleiben bei einem Neustart der Integrationskomponente erhalten.
18. Eine volle Warteschlange löst vor Datenverlust einen eigenen Alarm aus.
19. Die Nachlieferung respektiert Limits des Zielsystems.
20. Manuell erledigte Vorgänge werden beim Abgleich nicht doppelt ausgeführt.
21. Unauflösbare Konflikte erscheinen mit Eigentümer und Frist in einer Prüfliste.
22. Synthetische Anrufe erkennen eine Störung, die technische Einzelchecks übersehen.
23. Ein Fehlalarm führt nicht zu einer Endlosschleife zwischen zwei Routen.
24. Die Rückkehr in den Normalbetrieb wird mit einer echten Zielaktion verifiziert.
25. Nach dem Test werden RTO, Datenverlust, offene Vorgänge und Verbesserungen dokumentiert.

Welche Kennzahlen den Notbetrieb wirklich beschreiben

18 Fragen für Anbieter, SLA und Betriebshandbuch

1. Welche Komponenten liegen im vollständigen Anrufpfad?
2. Welche davon betreibt der Anbieter selbst, welche Unterauftragnehmer?
3. Wo genau wird Verfügbarkeit gemessen?
4. Zählen fehlgeschlagene Zielaktionen zur Verfügbarkeit?
5. Welche Wartungszeiten und Fehlerklassen sind ausgeschlossen?
6. Welche RTO-Ziele gelten für welchen Betriebsmodus?
7. Welcher Datenstand ist nach Wiederanlauf garantiert?
8. Ist der Fallback technisch unabhängig von der Hauptplattform?
9. Wer darf automatisch oder manuell umschalten?
10. Wie werden Kunden im jeweiligen Fehlerbild informiert?
11. Welche Vorgänge werden gepuffert und wo?
12. Wie werden Wiederholungen ohne doppelte Wirkung umgesetzt?
13. Wer sieht Alarm, Backlog und aktiven Betriebsmodus?
14. Gibt es eine öffentlich erreichbare Statusseite auf unabhängiger Infrastruktur?
15. Wie werden lokale Internet- und Stromausfälle getestet?
16. Wie oft finden vollständige Wiederanlaufübungen statt?
17. Wie werden manuelle und automatische Vorgänge abgeglichen?
18. Kann der Anbieter die 25 Tests in der vorgesehenen Architektur vorführen?

Fazit: Ausfallsicherheit ist ein geübter Mindestprozess

Ein hochverfügbarer Dienst ist wertvoll, ersetzt aber keinen Notbetrieb. Unternehmen müssen wissen, welche Anrufleistung kritisch ist, welche Komponente sie trägt und welcher unabhängige Weg bei ihrem Ausfall verbleibt. Gute Telefon-KI sagt im Fehlerfall weniger, aber nichts Falsches; sie sichert jeden offenen Vorgang und kehrt erst nach einem kontrollierten Abgleich in den Normalbetrieb zurück.