Der Fallback entscheidet, nicht der Normalfall
Aus dem Maschinenraum – Zahlen, Entscheidungen und Lehren aus dem Support-Betrieb.
In jeder Demo läuft der Bot den Normalfall durch: Anliegen erkannt, Daten geholt, Antwort geliefert. Den können inzwischen alle. Über die Akzeptanz im Betrieb entscheidet der andere Moment: der, in dem etwas schiefgeht. Wie elegant ein System scheitert, ist keine Fussnote im Design, sondern die eigentliche Entwurfsaufgabe.
Die Grundregel: Plan B oder Eskalation mit Kontext
Ein Fallback ist keine höfliche Fehlermeldung. Die Regel, nach der wir bauen: Jeder technische Fehlerfall bekommt eine von zwei Antworten: einen Plan B oder eine Eskalation an den Menschen, mit Kontext.
Und «jeder» heisst jeder: die API, die nicht antwortet; das System im Wartungsfenster; die Antwort, die anders aussieht als erwartet. Es reicht nicht, die wahrscheinlichen Fälle abzudecken. Im Betrieb kommen die unwahrscheinlichen garantiert dazu.
Ein Plan B ist ein zweiter Weg zum gleichen Ergebnis. Wo es keinen gibt, übernimmt der Mensch, mit dem bisherigen Verlauf und dem, was der Bot bereits geprüft hat, sodass die Kundschaft nichts zweimal erzählt. Das Gegenteil, die Endlosschleife aus «Ich habe dich leider nicht verstanden», ist der schnellste Weg, das Vertrauen in den ganzen Kanal zu verspielen.
Das vergessene Netz 1: der Kanalwechsel
Der häufigste Fallback taucht in keinem Flow-Diagramm auf: Die Kundschaft gibt den Kanal auf und ruft an. Spätestens wenn der Bot auf mehreren Kanälen läuft, stellt sich damit eine Architekturfrage: Woher weiss der Voice-Bot, dass im Chat schon etwas besprochen wurde? Beginnt jeder Kanal bei null, erzählt die Kundschaft ihr Anliegen zum dritten Mal, und der Kanalwechsel, eigentlich ihr letzter Ausweg, macht die Erfahrung noch schlechter.
Das Muster dagegen: den Kontext dort ablegen, wo ihn jeder Kanal findet, am Kundenprofil, zum Beispiel als User Field. Der Voice-Bot prüft beim Anruf, ob ein Chat-Kontext existiert, und setzt dort auf. Ein Gedächtnis über die Kanäle hinweg, bei uns die nächste Ausbaustufe.
Das vergessene Netz 2: Aussagen, die nicht liegen bleiben dürfen
Manche Sätze im Chat sind keine Anliegen, sondern Signale: «Ich kann meine Rechnungen nicht bezahlen.» In einem regulierten Umfeld darf so eine Aussage nicht einfach im Transkript verschwinden, auch dann nicht, wenn die Kundschaft danach nichts mehr schreibt. Gerade dann nicht.
Unsere Lösung: Bleibt ein Chat 15 Minuten ohne Aktivität der Kundschaft, stösst das automatisch einen Use Case in AI Agents Advanced an, den wir anhand unserer eigenen Kriterien darauf trainiert haben, kritische Aussagen im Chat-Transkript zu erkennen. Bei einem Treffer löst er eine Benachrichtigung an unsere Agenten aus. Ein Mensch schaut hin, auch wenn niemand mehr fragt.
In der Notiz über die Lösungsquote war Schweigen ein Erfolgssignal: kein weiterer Kontakt, Fall gelöst. Hier ist dasselbe Schweigen ein Alarmsignal. Was Schweigen bedeutet, hängt vom Fall ab. Solche Unterscheidungen zu treffen, ist Fallback-Design.
Die vier Fragen an jedes Bot-Design
- Hat jeder technische Fehlerfall einen Plan B oder eine Eskalation, nicht nur die wahrscheinlichen?
- Kommt bei der Übergabe der Kontext mit, oder beginnt die Kundschaft von vorn?
- Überlebt der Kontext einen Kanalwechsel?
- Gibt es ein Netz für die Aussagen, die nach Gesprächsende nicht liegen bleiben dürfen?
Der Normalfall gewinnt die Demo. Der Fallback gewinnt den Betrieb.