IVR Voice Agent — Praxisbeispiel

Problem

Der virtuelle Support-Agent von Resolve Systems wurde für asynchronen Chat entwickelt, bei dem eine Antwort innerhalb von zwei Sekunden als flott empfunden wird. Ein Telefonanruf ist jedoch ein blockierender, Echtzeit-Kanal – Anrufer hören jede Verzögerung in der Pipeline als Stille. Die Plattform benötigte einen Sprachkanal, ohne das bestehende Chatbot-Backend neu schreiben zu müssen.

Meine Rolle

Ich habe die Architektur von Anfang bis Ende entworfen und implementiert: Intent-Routing, Speech-to-Text- und Text-to-Speech-Orchestrierung über Amazon Connect, Amazon Lex, AWS Lambda und Polly sowie die Übergabe an die bestehende Fulfillment-Logik.

Der entscheidende Teil, der das möglich machte, war nicht sprachspezifisch. Ich habe die Factory-Method-Integrationsschicht entworfen und gebaut, auf der die Chatbot-Plattform läuft: Jeder Kanal wird in einen einheitlichen Envelope normalisiert, eine Factory instanziiert den passenden Adapter, und das Fulfillment arbeitet auf Intents und Entities, ohne jemals nach Kanal zu verzweigen.

Die Eigenschaft, die zählte, ist, dass die Abstraktion zeitneutral ist. Slack, Teams, Google Chat und Webex sind asynchron; ein Telefonanruf ist synchron und blockierend. Beides sind Adapter. Die Schnittstelle macht keine Aussage darüber, ob eine Antwort in zwei Sekunden oder zweihundert Millisekunden eintrifft, sodass Voice gegen eine bereits existierende Schnittstelle hinzugefügt wurde, anstatt die Produktionsinfrastruktur zu verzweigen, um sie zu unterstützen. Diese Grenze von Anfang an richtig zu ziehen, ist der Grund, warum der schwierigste Kanal überhaupt hinzugefügt werden konnte.

Einschränkungen

• Voice-Latenzbudgets sind unerbittlich – Anrufer bemerken Unterbrechungen unter einer Sekunde, die Chat-Nutzer nie wahrnehmen.
• Das asynchrone Fulfillment-Backend war Produktionsinfrastruktur, die mit allen Chat-Kanälen geteilt wurde; es konnte für Voice nicht verzweigt werden.
• Enterprise-Sicherheitsanforderungen – Authentifizierung, Umgang mit Secrets – galten für jeden neuen Hop.

Architektur

Amazon Connect erfasst Audio und streamt es an Lex zur Intent-Erkennung; eine Lambda-Bridge übersetzt zwischen dem synchronen IVR-Flow und dem asynchronen Chatbot-Backend, dann synthetisiert Polly die Antworten zurück in den Anruf. Downstream-Lookups starten spekulativ beim Beginn der Äußerung statt erst nach der Intent-Erkennung, und die Reise des Anrufers wird über Connect, Lex, Lambda und downstream APIs korreliert, sodass Traces die Kanalgrenze überleben.

Ergebnis

Als Produktionskanal der virtuellen Support-Agent-Plattform ausgeliefert, die dazu beitrug, das Helpdesk-Anrufvolumen um 40–60 % zu reduzieren.

Wie es weiterging

Der Kanal wurde inzwischen vom AWS-Stack auf Vapi migriert, das als Plattform mehr Echtzeit-Orchestrierung übernimmt als der Ansatz mit zusammengesetzten Primitiven. Das ist eine klare Aussage: Nach dem Aufwand, die Bridge zu bauen, stellte sich eine speziell für Voice gebaute Plattform als der bessere Agent heraus. Die Evaluation weiterer Voice-Plattformen läuft parallel dazu, denn die entscheidenden Einschränkungen bei solchen Systemen sind selten nur technischer Natur.

Überlebt hat die Migration der Teil, den ich genauso weiterbauen würde – die darunterliegende Integrationsschicht. Da das Fulfillment nie nach Kanal verzweigte, wurde es durch den Austausch des Voice-Frontends nicht berührt.

Was ich anders machen würde

Cross-Service-Korrelation von Anfang an mitdenken, statt sie erst während der Stabilisierung hinzuzufügen – Traces, die an einer Kanalgrenze sterben, sind keine Traces. Und frühzeitig Budget für Barge-in-Cancellation-Semantik einplanen: Jede laufende Synthese wird stornierbar, was die Idempotenzanforderungen downstream verändert.