Voice AI testen: Ein 30-Fälle-Plan für Stimme, Aktionen und Übergaben

Die kurze Antwort

Teste einen Voice Agent nicht mit freien Demo-Gesprächen, sondern mit einem festen Satz aus Aufgaben, Störungen und erwarteten Ergebnissen. Bewerte Gespräch und Systemaktion getrennt. Ein Test besteht nur dann, wenn der Agent korrekt versteht, zulässig antwortet, die richtige Aktion genau einmal ausführt und bei Unsicherheit sauber übergibt.

Ein überzeugender Demo-Call zeigt einen möglichen Erfolgsweg. Ein belastbarer Test zeigt zusätzlich, wie das System bei Störungen, Grenzen und falschen Voraussetzungen reagiert.

Warum der Demo-Call fast immer zu freundlich ist

Wer einen Agenten gebaut hat, kennt die erwarteten Formulierungen. Diese Person spricht deutlicher, verzeiht Pausen und hilft unbewusst zurück auf den richtigen Pfad. Eine gute Demo beweist deshalb nur, dass ein vorgesehener Weg funktionieren kann.

Produktion beginnt bei den unbequemen Fällen: zwei Anliegen in einem Satz, korrigierte Telefonnummer, plötzliches Schweigen, Hintergrundstimme, belegter Kalender, wiederholter Werkzeugaufruf, eine Frage außerhalb der Wissensbasis und der Wunsch nach einem Menschen.

Aktuelle Plattformdokumentation nennt ausdrücklich Tests für unklare Anfragen, konfigurierte Aktionen, Übergaben, Stille, Unterbrechungen und Gesprächsabschluss. OpenAIs Full Duplex Bench prüft ebenfalls Pausen, Redewechsel, Hintergrundsprache und Backchannels. Daraus folgt ein breiteres Qualitätsbild als „Die Stimme klingt gut“.

Die Testmatrix mit 30 Fällen

Die sechs Bereiche erhalten jeweils fünf Fälle. Das ist eine redaktionelle Empfehlung für eine erste Abnahme, kein wissenschaftlich optimaler Umfang. Fünf Varianten pro Bereich reichen meist, um wiederkehrende Fehlermuster sichtbar zu machen, ohne den Start zu einem monatelangen Laborprojekt zu machen.

Bereich A: Kernaufgabe

Teste den geraden Erfolgsweg, eine fehlende Pflichtangabe, eine Korrektur, zwei mögliche Absichten und einen ausdrücklich abgebrochenen Vorgang. Erwartetes Ergebnis und zulässige Formulierung werden vor dem Anruf notiert.

Bereich B: Sprache und Timing

Teste eine längere Denkpause, eine kurze Bestätigung wie „mhm“, eine Unterbrechung während der Antwort, schnelles Sprechen und Hintergrundsprache. Beurteile nicht die Schönheit der Stimme, sondern ob der Agent richtig entscheidet: weiter zuhören, kurz bestätigen, stoppen oder nachfragen.

Bereich C: Daten

Verwende einen schwierigen Namen, eine buchstabierte E-Mail, eine korrigierte Nummer, einen bestehenden Kontakt und zwei ähnliche Kontakte. Prüfe nach dem Gespräch den Datensatz. Das Transkript allein ist nicht die Wahrheit.

Bereich D: Aktionen

Teste eine erfolgreiche Aktion, technische Zeitüberschreitung, Wiederholung, bereits vorhandenes Ergebnis und nicht erfüllte Voraussetzung. Eine wiederholte Anfrage darf nicht ungeprüft einen zweiten Termin oder eine zweite Aufgabe erzeugen.

Bereich E: Grenzen und Sicherheit

Stelle eine Frage außerhalb der Wissensbasis, fordere eine nicht freigegebene Zusage, widerspreche der Datennutzung, verlange einen Menschen und verwende eine sensible Situation. Der beste Ausgang kann eine höfliche Ablehnung oder Übergabe sein.

Bereich F: Routing und Nachlauf

Teste Geschäftszeit, außerhalb der Geschäftszeit, nicht erreichbare Zielperson, Voicemail/Fallback und das Ende ohne Buchung. Prüfe, ob die richtige Benachrichtigung, Aufgabe, Zusammenfassung und Folgeaktion entstehen.

Bewertung mit klaren Nennern

Verwende pro Testfall vier getrennte Ergebnisse. „Verstanden“ bedeutet, dass Absicht und Pflichtdaten korrekt erkannt wurden. „Antwort korrekt“ bedeutet, dass Inhalt und Grenzen stimmen. „Aktion korrekt“ verlangt genau das erwartete Systemergebnis. „Handover korrekt“ prüft Übergabe oder Fallback einschließlich Kontext.

Eine Gesamtquote darf diese vier Ebenen nicht in einem attraktiven Durchschnitt verstecken. Ein Gespräch kann hervorragend klingen und bei der Aktion trotzdem durchfallen.

Stopp-Kriterien vor dem Livegang

Ein einziger schwerer Fehler kann wichtiger sein als 29 gelungene Fälle. Kein Livegang bei falscher Identität, unzulässiger Aussage, verlorener Opt-out-Information, bestätigter aber nicht existierender Buchung, Endlosschleife oder fehlender menschlicher Übergabe in einem vorgesehenen Eskalationsfall.

Leichte Fehler wie eine unnötige Wiederholung werden erfasst, aber anders priorisiert. So verhindert das Team, dass eine durchschnittliche Punktzahl kritische Probleme verdeckt.

Der Wiederholungstest nach jeder Änderung

Ändere immer nur eine kontrollierbare Komponente: Prompt, Wissensquelle, Stimme, Unterbrechungsempfindlichkeit oder Aktion. Führe danach mindestens die direkt betroffenen Fälle und alle schweren Sicherheitsfälle erneut aus. Vor einem größeren Release läuft die gesamte Matrix.

Versioniere Testdatum, Agentversion, Modell, Stimme, Sprache, Telefonnummer, Wissensstand und Kalenderkonfiguration. Ohne diesen Kontext lassen sich zwei Ergebnisse nicht fair vergleichen.

Natürlichkeit messbar machen, ohne eine Scheingenauigkeit zu bauen

Natürlichkeit ist subjektiv, kann aber konsistent beurteilt werden. Lass mehrere Personen unabhängig vier Fragen beantworten: Wurde ich unnötig unterbrochen? Konnte ich den Agenten stoppen? Waren Pausen und Bestätigungen angemessen? War die Aussprache kritischer Namen und Zahlen verständlich?

OpenAI meldet für GPT-Live-1 eine Verbesserung von 30 Prozentpunkten im Full Duplex Bench gegenüber GPT-Realtime-2.1. Das ist ein relevanter Herstellerbenchmark für Interaktion, aber kein Ersatz für den eigenen deutschen Telefon-, Daten- und Prozesskontext.

Produktionsmonitoring statt einmaliger Abnahme

Nach dem Start wird aus dem Testset ein laufendes Kontrollsystem. Ziehe regelmäßig eine Stichprobe pro Anrufgrund. Erfasse neue Fehlermuster als zusätzliche Fälle. Beobachte nicht nur Durchschnittswerte, sondern besonders die Zahl schwerer Fehler und manuell korrigierter Aktionen.

Änderungen werden erst übernommen, wenn sie das Zielproblem lösen, ohne bestehende Fälle zu verschlechtern. Ein natürlicheres Gespräch darf keine ungenauere Datenerfassung erkaufen.

Wie ONE LOOP die Abnahme strukturiert

ONE LOOP legt für jeden Agenten Aufgabe, erwartetes Ergebnis, verbotene Ergebnisse und Handover fest. Die 30 Fälle werden gegen Voice-Schicht, CRM, Kalender und Folgeworkflow geprüft. Ein Abnahmeprotokoll macht sichtbar, welche Version getestet wurde und welche Risiken bewusst offen bleiben.

Fazit

Voice AI wird nicht durch den besten Demo-Call zuverlässig, sondern durch den reproduzierbaren schlechtesten Fall. Ein fester 30-Fälle-Plan schafft eine praktische Balance: breit genug für Sprache, Daten, Aktionen und Fallbacks, klein genug für jede relevante Änderung. Was nicht als erwartetes Ergebnis beschrieben und im System geprüft werden kann, ist noch nicht produktionsreif.