Vom 114-Widget-Telefonmenü zum Sprachassistenten

Ausgangslage

Der Vorgänger liegt im Projektordner: ein Menübaum aus 114 Widgets mit 10 Tastenmenüs, bis zu drei Ebenen tief verschachtelt. Wer ein bestimmtes Kundenservice-Team erreichen wollte, hörte ein Hauptmenü, dann ein Markenmenü, in einem Zweig noch ein drittes.

Was das Projekt ausgelöst hat, steht nirgends dokumentiert — keine Tickets, keine Abbruchquoten, kein Briefing. Die einzige schriftlich festgehaltene Motivation ist eine Projektnotiz: Anrufer sollen sagen können, was sie brauchen, statt zu navigieren. Ob Fehlleitung, Abbrüche oder die Belastung der Zentrale den Ausschlag gaben, wäre Rekonstruktion.

Ansatz

Anrufe laufen in den bestehenden Anrufweg, und die Prüfungen, die dort schon liefen — gesperrte Nummern, Öffnungszeiten, Durchwahlen —, laufen unverändert zuerst. Nur Anrufe, die vorher im alten Menü gelandet wären, erreichen den Assistenten.

Die Telefonanlage öffnet dann eine Audio-Sitzung zu einem kleinen Node.js-Dienst. Sprache-zu-Text und Text-zu-Sprache bleiben bei der Plattform; der Dienst sieht Text und führt das Gespräch. Er begrüßt mit Vornamen, wenn eine Abfrage gegen die Kundendatenbank innerhalb von 1,2 Sekunden antwortet — sonst ohne Namen, der wird nachgereicht, sobald er da ist. Jede Begrüßung sagt, dass hier ein automatischer Assistent spricht; ein Test erzwingt das, weil Art. 50 der EU-KI-Verordnung es verlangt.

Jeder Gesprächsschritt geht an ein Sprachmodell, dessen System-Prompt pro Anruf aus einer typisierten Konfiguration zusammengesetzt wird: Abteilungen und ihre Beschreibungen, Markennamen und bekannte Verhörer dieser Markennamen. Sobald das Modell das Anliegen verstanden hat, antwortet es nicht mehr in Prosa, sondern ruft eines von vier Werkzeugen auf.

Der Punkt, an dem es anders hätte laufen können

Das Modell darf nie ein Ziel benennen. Es wählt aus einer Liste, gewählt wird von der Anlage.

Das hätte anders ausgehen können — man kann das Modell eine Rufnummer oder einen Warteschlangennamen direkt zurückgeben lassen. Stattdessen werden die Werkzeugdefinitionen pro Anruf gebaut, mit den Zielparametern als Aufzählung aus der Länderkonfiguration. Das Modell kann gar nichts wählen, was nicht existiert. Die Antwort wird anschließend erneut gegen dieselbe Konfiguration geprüft; bei jeder Abweichung landet der Anruf beim Empfang.

Die Rufnummern erreichen das Modell überhaupt nicht. Es gibt einen abstrakten Schlüssel aus, etwa finance_payroll, den der Anrufweg selbst auflöst.

Derselbe Instinkt zieht sich durch: maximal fünf Gesprächsschritte, bevor an einen Menschen übergeben wird, und jeder Fehlerpfad endet beim Empfang. Der akzeptierte Preis: Der Assistent kann nie klüger sein als seine Konfiguration, und ein neues Ziel braucht eine Konfigurations- änderung samt Auslieferung.

Ergebnis

Der Anrufweg schrumpfte von 114 auf 18 Widgets. Der Gesprächsdienst umfasst rund 1.870 Zeilen TypeScript, abgesichert durch 38 Tests. Jeder Anruf wird mit Transkript in die Auswertungsdatenbank geschrieben, wo Mitarbeitende jede Entscheidung als richtig oder falsch bewerten — die Datengrundlage für die Verbesserung entsteht im Betrieb.

Ehrlich zum Stand: Ein Land ist live. Der Entwurf ist ausdrücklich mehrländerfähig, aber nur eine Konfiguration ist registriert. Die Betriebsdokumentation nennt ein internes Ziel von 80–95 % der Anrufe ohne Rückfall auf den Empfang — gemessen ist das im Projektstand nicht.

Bewusst offen: Die Verbesserungsschleife ist manuell. Eine wöchentliche Durchsicht liest die Telemetrie, findet neue Verhörer und unbehandelte Anliegen und speist sie als Konfigurationsänderung zurück. Nichts justiert sich selbst — und der Empfang bleibt das Sicherheitsnetz, nicht der Ausnahmefall.