Notbetrieb, wenn Claude nicht erreichbar ist: so laufen Ihre Zoho-Prozesse weiter

Notbetrieb, wenn Claude nicht erreichbar ist, heißt: Ihr Zoho-Prozess arbeitet ohne KI nach festen Regeln weiter, statt stillzustehen. Ein neues Ticket in Zoho Desk landet dann über eine Standard-Zuweisungsregel in einer Sammelwarteschlange. Dort ordnet ein Mensch es zu, bis die KI wieder antwortet.

Notbetrieb ist der vorab festgelegte Ablauf, nach dem ein Geschäftsprozess weiterläuft, wenn eine beteiligte Komponente ausfällt. Er wird geplant, bevor etwas passiert. Im Ernstfall entscheidet niemand mehr spontan, sondern das System schaltet auf den vereinbarten Weg um.

Dieser Leitfaden behandelt drei Bausteine für den Notbetrieb:

• Ausweichwege: eine feste Regel oder ein zweites Modell übernimmt die Aufgabe der KI.
• Warteschlangen: Vorgänge werden gesammelt und später von der KI nachbearbeitet.
• Manuelle Übergaben: ein Mensch übernimmt, mit klarer Zuständigkeit.

Der Grundgedanke ist einfach. Claude ergänzt einen Prozess, der in Zoho bereits existiert. Fällt die KI aus, verlieren Sie Tempo und Komfort, aber keine Anfrage, keinen Datensatz und keine Frist. Die folgenden Abschnitte zeigen, wie Sie das konkret einrichten und prüfen.

Störungen bei Claude sind keine Theorie, sondern mehrfach dokumentiert. Am 31. Oktober 2025 berichtete it-daily.net über Störungen, die Nutzer weltweit betrafen. Laut den Status-Updates traten die ersten Fehler gegen 09:17 UTC auf, also um 10:17 Uhr deutscher Zeit. Anthropic bestätigte auf seiner Statusseite erhöhte Fehlerraten bei Anfragen an das damalige Hauptmodell.

Eine Korrektur allein beendete die Probleme nicht sofort. Anthropic meldete „A fix has been implemented and we are monitoring the results.“ Trotzdem berichteten viele Nutzer weiter, dass Claude unzuverlässig reagierte oder keine Antworten lieferte. In Entwicklerforen kursierten Berichte über 500er-Fehler und Zeitüberschreitungen beim Zugriff über die API.

Ein weiterer Ausfall betraf laut Aktien.news den Chatbot, die API und Claude Code zugleich. Die Störung begann laut Statusseite um 10:53 Uhr ET. Seit 13:50 Uhr ET waren alle Systeme wieder vollständig betriebsbereit. Das sind knapp drei Stunden.

Auf Downdetector, einer Plattform, die Nutzerberichte über Internetprobleme in Echtzeit erfasst, meldeten gegen 10:42 Uhr ET rund 6.000 Nutzer Probleme. Bis 13:12 Uhr ET sank die Zahl auf etwa 2.000, gegen 13:34 Uhr ET waren es noch rund 500 Meldungen. Ein Beitrag auf Instagram schildert zudem mehrere Störungen kurz hintereinander im August. Für Ihre Planung zählt: Ein Ausfall von einigen Stunden während der Geschäftszeit ist ein realistisches Szenario.

Ein Claude-Ausfall zeigt sich in Ihrer Integration zuerst als Fehlercode oder als Anfrage, die keine Antwort bekommt. Die Berichte vom Oktober 2025 nennen genau diese zwei Muster: 500er-Fehler und Zeitüberschreitungen. Ihre Integration muss beide Fälle erkennen und als Signal für den Notbetrieb behandeln.

Die Zeitüberschreitung ist der tückischere Fall. Eine Anfrage, die einfach hängt, löst keinen Fehler aus und hält den Prozess still. Laut einem Fehleranalyse-Artikel von APIYI hat der HTTP-Client von Claude Code keinen Read-Timeout-Mechanismus. Die Community empfiehlt dort, STREAM_READ_TIMEOUT_MS auf 120 Sekunden zu setzen. Für Ihre eigene Zoho-Integration gilt dasselbe Prinzip: Legen Sie eine feste Wartezeit fest, nach der die Anfrage als gescheitert gilt.

Die Statuszeile von Claude Code ist dafür kein verlässlicher Anzeiger. Laut demselben Artikel entsprechen die Spinner-Verben nicht dem tatsächlichen Status. In einigen Versionen bleibt der Spinner sogar stehen, obwohl das Ergebnis längst da ist. Für Diagnosen empfiehlt Anthropic laut Artikel den Befehl /doctor. Er prüft Installation, Einstellungsdateien, MCP-Server-Listen und Kontextauslastung.

Auch die offizielle Statusseite reicht als einziger Auslöser nicht. Laut dem Instagram-Beitrag war sie während der Störungen im August zeitweise selbst nicht erreichbar. Verlassen Sie sich deshalb auf Ihre eigenen Messwerte: Fehlerquote und Antwortzeit der Anfragen, die Ihr System tatsächlich stellt.

Ein ausfallsicherer Aufbau beginnt mit der Reihenfolge der Schritte. Der Vorgang wird zuerst in Zoho angelegt und erst danach von Claude angereichert. Ein Ticket existiert also in Zoho Desk, bevor die KI es liest. Ein Kontakt steht in Zoho CRM, bevor Claude einen Antwortentwurf schreibt.

Die umgekehrte Reihenfolge ist riskant. Wenn eine Anfrage erst durch die KI muss, bevor sie im System landet, geht sie bei einem Ausfall verloren oder bleibt in einer Zwischenstation hängen. Niemand sieht sie, niemand fühlt sich zuständig.

Daraus ergeben sich drei Regeln für den Entwurf:

• Jeder Vorgang hat in Zoho einen Ausgangszustand, der ohne KI gültig ist, etwa „nicht zugeordnet“.
• Die KI schreibt ihr Ergebnis in eigene Felder, sodass erkennbar ist, ob sie gearbeitet hat.
• Für jeden Ausgangszustand gibt es eine Regel, die greift, wenn die KI kein Ergebnis liefert.

So wird der Ausfall sichtbar statt still. Ein Ticket ohne KI-Ergebnis ist kein Fehler, sondern ein Fall für die Ersatzregel. Wie das für die E-Mail-Eingangsverarbeitung aussieht, beschreibt auch unser Beitrag zur E-Mail-Triage und zu Entwürfen mit Claude. Dieselbe Logik gilt für Angebote, Belegerfassung und Berichte.

Das folgende Beispiel zeigt einen IT-Service-Desk, in dem Claude eingehende Tickets einordnet und dem richtigen Team zuweist. Für diese Aufgabe eignet sich Claude Haiku 5.5. Anthropic positioniert das Modell für Aufgaben mit hohem Volumen und kurzer Antwortzeit, ausdrücklich auch für Klassifizierung und Weiterleitung.

Der Ablauf im Normalbetrieb und im Notbetrieb:

1. Eine Anfrage geht per E-Mail oder Formular ein. Zoho Desk legt das Ticket sofort an, ohne Zuständigkeit.
2. Ihre Integration sendet Betreff und Text an Claude und wartet höchstens eine fest eingestellte Zeit.
3. Liefert Claude rechtzeitig Kategorie und Team, schreibt die Integration beides in eigene Ticketfelder und weist das Ticket zu.
4. Kommt ein Fehlercode oder läuft die Wartezeit ab, setzt die Integration ein Kennzeichen wie „KI ausstehend“.
5. Eine Standard-Zuweisungsregel in Zoho Desk leitet alle Tickets mit diesem Kennzeichen in eine Sammelwarteschlange.
6. Die diensthabende Person ordnet diese Tickets von Hand zu, bis die KI wieder antwortet.

Entscheidend ist Schritt 4. Ohne ihn bleibt das Ticket unzugeordnet und fällt niemandem auf. Mit ihm landet es in einer Warteschlange, die jemand beobachtet. Die Ersatzregel selbst braucht keine KI, sie prüft nur ein Feld.

Wie Sie die Anfragen bereits in Microsoft Teams entgegennehmen und an Zoho Desk weitergeben, beschreibt der Beitrag zu Claude in Microsoft 365 und Teams. Der Notbetrieb folgt dort demselben Muster.

Nicht jeder Prozess braucht denselben Ausweichweg. Maßgeblich ist, wie schnell ein Vorgang bearbeitet werden muss und ob ein Mensch die Aufgabe der KI übernehmen kann. Die Tabelle ordnet typische Claude-Aufgaben in Zoho-Prozessen einem passenden Notbetrieb zu.

Prozess	Aufgabe von Claude	Notbetrieb	Wer übernimmt
Ticketzuordnung in Zoho Desk	Kategorie und Team bestimmen	Ersatzregel in Sammelwarteschlange	Diensthabende Person
E-Mail-Antwortentwürfe	Entwurf schreiben	Vorlagen statt Entwurf	Bearbeitende Person
Angebotstexte aus Zoho CRM	Text formulieren	Warteschlange, späterer Entwurf	Vertrieb bei Eilfällen
Rechnungs- und Belegerfassung	Felder auslesen	Warteschlange, Nachverarbeitung	Buchhaltung bei Fristen
Wochenbericht	Zusammenfassung erstellen	Bericht später erzeugen	Niemand, kein Eingriff nötig

Lesen Sie die Tabelle von rechts nach links. Wo ein Mensch sofort übernehmen muss, brauchen Sie eine Ersatzregel und eine benannte Zuständigkeit. Wo der Vorgang warten kann, genügt eine Warteschlange. Für zeitkritische Fälle in der Belegerfassung lohnt der Blick in den Beitrag zum Verarbeiten von Rechnungen und Verträgen mit Claude. Dort ist die menschliche Freigabe ohnehin Teil des Ablaufs.

Ein Ausweichmodell ist ein zweites Modell, auf das Ihre Integration umschaltet, wenn das erste nicht antwortet. Ein Kommentar unter dem Instagram-Beitrag fasst die Grenze treffend zusammen: Ein Backup-Modell sei ein guter Anfang, entscheidend seien aber auch Zugänge, Arbeitsstände und klare Alternativen.

Ein zweites Claude-Modell

Ein kleineres Modell kann einfache Aufgaben übernehmen, wenn das größere ausfällt oder überlastet ist. Claude Haiku 5.5 kostet laut Anthropic ab 0,10 US-Dollar je Million Eingabe-Token und ab 0,50 US-Dollar je Million Ausgabe-Token. Claude Opus 5.5 liegt bei 4 und 20 US-Dollar. Bei einem Ausfall wie im beschriebenen Fall betrafen die Fehler allerdings Chatbot, API und Claude Code gleichzeitig. Ein zweites Modell desselben Zugangs hilft dann nicht.

Ein zweiter Bezugsweg

Die aktuellen Modelle sind laut Anthropic auch über Amazon Bedrock, Google Cloud, Microsoft Foundry und Claude Platform on AWS verfügbar. Ein zweiter Zugang über einen dieser Wege kann eine Störung des direkten Zugangs überbrücken. Prüfen Sie vorab die Fähigkeiten des Modells auf diesem Weg. Die Models API liefert dafür für jedes verfügbare Modell max_input_tokens, max_tokens und ein capabilities-Objekt. Beachten Sie auch: Organisationseinstellungen können Anfragen mit einem unterstützten Werkzeug scheitern lassen, etwa wenn ein Administrator die Websuche abschaltet.

Ein Ausweichmodell ersetzt die regelbasierte Ersatzregel deshalb nicht. Es ist eine zusätzliche Stufe davor.

Eine Warteschlange sammelt alle Vorgänge, die während eines Claude-Ausfalls nicht bearbeitet wurden, und gibt sie danach erneut an die KI. In Zoho genügt dafür meist ein Statusfeld wie „KI ausstehend“. Nach dem Ende der Störung arbeitet die Integration alle Datensätze mit diesem Status nacheinander ab.

Planen Sie den Abbau der Warteschlange bewusst. Nach knapp drei Stunden Ausfall kommen viele Vorgänge auf einmal zurück. Verarbeiten Sie sie in kleinen Paketen, damit Sie nicht in neue Fehler laufen. Prüfen Sie außerdem, ob ein Mensch einen Vorgang in der Zwischenzeit schon erledigt hat. Sonst überschreibt die KI eine manuelle Zuordnung.

Die manuelle Übergabe braucht drei Festlegungen:

• Wer übernimmt während des Ausfalls, und wer vertritt diese Person?
• Wie erfährt das Team, dass der Notbetrieb gilt, etwa über eine Nachricht im Teamkanal?
• Wann endet der Notbetrieb, und wer gibt das Ende frei?

Ein weiterer Kommentar unter dem Instagram-Beitrag weist darauf hin, dass die Absicherung bei Team-Accounts und geteilten Projekten schwieriger ist. Das gilt auch hier. Halten Sie Zuständigkeiten und Vorlagen deshalb in Zoho selbst fest, nicht in einem persönlichen KI-Projekt einer einzelnen Person. Dann kann jede vertretende Person sofort arbeiten.

Für Unternehmen in Deutschland fallen Claude-Störungen oft in die eigene Geschäftszeit. Die Störung vom 31. Oktober 2025 begann um 10:17 Uhr deutscher Zeit, also mitten im Vormittag. Ein Service-Desk, der zu dieser Stunde ohne Notbetrieb arbeitet, sammelt unzugeordnete Tickets genau dann, wenn die meisten Anfragen eingehen.

Der zweite Punkt betrifft den Datenschutz. Ein zweiter Bezugsweg über einen anderen Cloud-Anbieter ist ein zusätzlicher Datenweg. Er gehört in dieselbe Prüfung wie der Hauptzugang: Vertrag, Speicherort, Art der übertragenen Daten. Klären Sie das vor dem Ernstfall, nicht währenddessen. Die Grundlagen beschreibt unser Beitrag zur DSGVO-konformen Nutzung von Claude.

Der dritte Punkt ist die Dokumentation. Halten Sie den Notbetrieb schriftlich fest: welche Prozesse betroffen sind, welche Ersatzregel greift, wer übernimmt. Diese Beschreibung hilft neuen Mitarbeitenden, Vertretungen und jeder späteren Prüfung des Ablaufs.

Der regelbasierte Ansatz hat hier einen Vorteil. Eine Standard-Zuweisungsregel in Zoho verarbeitet keine Daten außerhalb Ihres Zoho-Systems. Im Notbetrieb verlassen also weniger Daten das System als im Normalbetrieb. Das vereinfacht die Bewertung des Ausweichwegs erheblich.

Ein Notbetrieb, der nie getestet wurde, ist eine Annahme und kein Ablauf. Der einfachste Test besteht darin, die Verbindung zu Claude bewusst zu unterbrechen und zu beobachten, was in Zoho passiert. Bei Svennis schalten wir in jedem Projekt vor dem Livegang die KI-Verbindung absichtlich ab und prüfen, ob jedes neue Ticket in der Sammelwarteschlange landet und dort auffällt.

Ein vollständiger Probelauf prüft vier Dinge:

1. Erkennt die Integration Fehlercodes und abgelaufene Wartezeiten zuverlässig?
2. Setzt sie das Kennzeichen, und greift die Ersatzregel in Zoho Desk?
3. Erfährt die zuständige Person rechtzeitig vom Notbetrieb?
4. Arbeitet die Warteschlange nach dem Wiederanschalten sauber ab, ohne manuelle Zuordnungen zu überschreiben?

Wiederholen Sie den Test nach jeder größeren Änderung. Dazu zählen ein Modellwechsel, ein neuer Prompt oder eine neue Kategorie in der Ticketzuordnung. Wie Sie Prompts und ihre Änderungen nachvollziehbar halten, beschreibt der Beitrag zum Testen und Versionieren von Claude-Prompts. Halten Sie das Ergebnis jedes Probelaufs fest. So sehen Sie, ob der Notbetrieb mit dem System mitgewachsen ist.

Den Notbetrieb für einen Claude-Ausfall richten Sie in drei Arbeitsschritten ein. Beginnen Sie mit dem Prozess, bei dem ein Stillstand am meisten kostet, meist der Service-Desk.

1. Prozessliste erstellen: Schreiben Sie auf, wo Claude heute in Ihren Zoho-Prozessen arbeitet. Ordnen Sie jedem Prozess mit der Entscheidungstabelle oben einen Notbetrieb zu: Ersatzregel, Warteschlange oder Abwarten.
2. Ersatzregel einrichten: Legen Sie das Kennzeichen „KI ausstehend“ an, eine feste Wartezeit in der Integration und die Standard-Zuweisungsregel in Zoho Desk. Benennen Sie die zuständige Person und ihre Vertretung.
3. Probelauf durchführen: Unterbrechen Sie die KI-Verbindung bewusst und prüfen Sie die vier Punkte aus dem Abschnitt zum Testen.

Rechnen Sie dabei nicht mit Minuten, sondern mit Stunden. Der beschriebene Ausfall dauerte von 10:53 bis 13:50 Uhr ET. Ihr Notbetrieb muss einen halben Arbeitstag tragen, ohne dass Anfragen verloren gehen.

Wenn Ihre Anfragen über Microsoft Teams eingehen, ist der Beitrag zu Claude in Microsoft 365 und Teams mit Weiterleitung an Zoho Desk der passende nächste Schritt. Er zeigt den Normalbetrieb, auf den Sie den hier beschriebenen Notbetrieb aufsetzen.