Sprach-KI testen Sie, indem Sie Anrufe durch die gesamte Kette schicken, bevor der Assistent mit einem einzigen Kunden spricht: die Telefonleitung, die Spracherkennung, jeden Zweig des Gesprächsablaufs, die Systeme, aus denen er liest und in die er schreibt, und die Übergabe an einen Mitarbeiter. Halten Sie für jeden Testanruf fest, was passieren soll, vergleichen Sie es mit dem, was tatsächlich passiert ist, beheben Sie die Fehler und lassen Sie das Testset erneut laufen. Wiederholen Sie dasselbe Set nach jeder Änderung am Ablauf, denn eine Anpassung an einem Schritt kann einen anderen Schritt stören. Eine Demo im Browser beweist die Idee. Erst Testanrufe über eine echte Telefonleitung beweisen, dass der Assistent für Ihre Anrufer bereit ist.

Kurz zusammengefasst: was ein Testplan abdeckt

• Die gesamte Kette, nicht nur das Gespräch: Audio, Erkennung, Ablauflogik, Backend, Sprachausgabe und Übergabe.
• Ein Testset aus echten Anrufgründen, mit bewusst eingebauten Randfällen.
• Ein festgelegtes Erfolgskriterium pro Testanruf, geprüft im Backend und nicht nur nach Gehör.
• Regressionstests nach jeder Änderung, in einer Testumgebung, bevor die Änderung bei Anrufern ankommt.
• Eine Beobachtungsphase nach dem Go-live, in der abgeschlossene, weitergeleitete und abgebrochene Anrufe pro Schritt zeigen, was die Tests übersehen haben.

Warum Sprach-KI anders getestet wird als ein Chatbot

Ein Chatbot bekommt sauberen Text. Ein Sprachassistent bekommt ein Telefonat, und das meiste, was schiefgeht, passiert, bevor das Sprachmodell ein einziges Wort sieht.

• Telefonaudio ist schmalbandig. Die Dokumentation von Google Speech-to-Text hält fest, dass “most legacy telephony audio, for example, use sample rates of 8000 Hz, which may give less accurate results”, und empfiehlt, Audio in der ursprünglichen Abtastrate zu senden, statt es umzurechnen (Google Cloud). Ein Test im Browser mit einem guten Mikrofon verdeckt das.
• Anrufer machen Pausen, unterbrechen und reden dazwischen. Das System muss erkennen, wann ein Anrufer anfängt und aufhört zu sprechen. Sprachdienste melden das als Voice Activity Events, mit Timeouts für den Fall, dass Sprache nicht beginnt oder nicht endet (Google Cloud). Ob Ihr Ablauf mit einer langen Pause oder einem unterbrechenden Anrufer zurechtkommt, sehen Sie nur in einem echten Gespräch.
• Stille fällt auf. Allein für die Netzwerkverzögerung nennt die von Cisco zitierte ITU-Empfehlung bis zu 150 ms in eine Richtung als für die meisten Anwendungen akzeptabel (Cisco, zu ITU-T G.114). Erkennung, Verarbeitung und Sprachsynthese kommen noch hinzu. Warum das zählt, lesen Sie unter Latenz bei Sprach-KI.
• Der Assistent arbeitet mit Live-Daten. Er prüft Anrufer, schlägt Akten nach und schreibt Ergebnisse zurück. Ein Anruf, der perfekt klang, aber die falsche Akte geändert hat, ist gescheitert.

Wenn Sie noch zwischen einem Text- und einem Sprachkanal abwägen, finden Sie die Unterschiede in Sprach-KI vs. Chatbot.

Was Sie testen: sechs Ebenen der Kette

Ebene	Was schiefgeht	So testen Sie es	Bestanden, wenn
Telefonleitung und Audio	Echo, abgeschnittene erste Wörter, schlechte Qualität im Mobilfunk	Rufen Sie vom Festnetz, von einem Handy mit schwachem Empfang und aus einem lauten Raum an	Das erste Wort der Begrüßung und des Anrufers geht nie verloren
Spracherkennung	Namen, Nummern, Postleitzahlen, Daten und Kennzeichen falsch verstanden	Sprechen Sie die schwierigen Eingaben aus, mit verschiedenen Akzenten und Tempi	Der Wert, den der Assistent bestätigt, entspricht dem, was der Anrufer gesagt hat
Anliegen und Ablauf	Falscher Anrufgrund erkannt, ein Zweig, der im Kreis läuft oder endet	Ein Testanruf pro Zweig, dazu Anrufer, die mitten im Gespräch das Thema wechseln	Jeder Zweig erreicht den vorgesehenen Endzustand
Backend und CRM	Falsche Akte gefunden, nichts zurückgeschrieben, Timeouts	Testkunden in einer Testumgebung, auch ein Kunde, den es nicht gibt	Das Backend zeigt genau die Änderung, die der Anruf machen sollte
Übergabe	Kontext verloren, falsches Team, Anrufer muss alles wiederholen	Fragen Sie an verschiedenen Schritten nach einem Mitarbeiter und lösen Sie die Ausweichpfade aus	Der Kollege sieht, wer anruft und warum, bevor er sich meldet
Sprachausgabe und Timing	Lange Pausen, falsche Aussprache, Reden über den Anrufer hinweg	Hören Sie aufgezeichnete Testanrufe von Anfang bis Ende ab	Keine Pause, die ein Anrufer bemerkt, jeder Name und jede Nummer richtig ausgesprochen

Die schwierigen Eingaben verdienen eigene Tests. Wie ein Sprachassistent damit umgeht, lesen Sie in den Beiträgen zur Adressvalidierung, zur Kennzeichenerkennung, zu Datumsangaben und zur Prüfung von Anrufern.

Das Testset aus echten Anrufen bauen

Das beste Testset beginnt bei den Gründen, aus denen Kunden heute anrufen, nicht beim Ablaufdiagramm.

1. Listen Sie Ihre wichtigsten Anrufgründe auf und die Formulierungen der Anrufer, mit Umwegen und halben Sätzen. Klären Sie mit Ihrem Datenschutzbeauftragten, welche Aufnahmen und Transkripte Sie dafür verwenden dürfen.
2. Schreiben Sie für jeden Grund einen normalen Verlauf, dann die Randfälle: eine unbekannte Kundennummer, zwei Anliegen in einem Anruf, ein Anrufer, der sich korrigiert, Stille, “Ich möchte jemanden sprechen”, ein Backend, das nicht antwortet.
3. Verwenden Sie Testdaten, keine Produktivakten. Legen Sie Testkunden in einer Testumgebung an, damit ein gescheiterter Test kein echtes Kundenkonto ändern kann.
4. Notieren Sie neben jedem Testanruf das erwartete Ergebnis: welcher Zweig, welcher Wert erfasst, was in welches System geschrieben wird und wie der Anruf endet.
5. Lassen Sie Kollegen aus dem Kundenservice anrufen. Sie wissen, wie Kunden sprechen, und finden die Stellen, an denen der Ablauf hakt, schneller als die Menschen, die ihn gebaut haben.

Die Erkennung dort messen, wo es zählt

Für die Spracherkennung gibt es ein Standardmaß: die Wortfehlerrate (Word Error Rate, WER). Die Dokumentation von Microsoft definiert sie als die Zahl der eingefügten, ausgelassenen und ersetzten Wörter, geteilt durch die Zahl der Wörter in einem von Menschen erstellten Transkript. Eine WER von 5 bis 10% bezeichnet Microsoft als gute Qualität, 20% als akzeptabel und 30% oder mehr als schlecht. Zum Messen brauchen Sie Audio mit von Menschen erstellten Transkripten, und Microsoft empfiehlt 30 Minuten bis 5 Stunden repräsentatives Audio (Microsoft Learn).

Für einen Sprachassistenten sagt die gesamte WER weniger aus als die Genauigkeit bei den Wörtern, auf die der Ablauf angewiesen ist. Ein falsch verstandenes Füllwort kostet nichts. Eine falsch verstandene Ziffer in einer Policennummer schickt den Anruf in die falsche Richtung. Bewerten Sie die Werte, die der Assistent dem Anrufer bestätigt, deshalb gesondert.

Erfolgskriterien: vor dem Test festlegen

Ein Test ohne festgelegtes Ergebnis wird zur Meinung. Halten Sie für jeden Testanruf fest:

• Ergebnis: vom Assistenten abgeschlossen, an einen Mitarbeiter weitergeleitet oder abgebrochen. Das sind dieselben drei Ergebnisse, die Sie verfolgen, sobald der Assistent live ist.
• Weg: Ist der Anruf dem Zweig gefolgt, dem er folgen sollte?
• Daten: Stimmt der erfasste Wert, und stimmt die Änderung im Backend?
• Übergabe: Wenn weitergeleitet, ist der Kontext beim richtigen Team angekommen?
• Erlebnis: Gab es eine Pause, eine Wiederholung oder eine falsche Aussprache, die einem Anrufer auffallen würde?

Legen Sie vorab fest, was vor dem Go-live bestehen muss. Die meisten Teams werten eine falsche Änderung im Backend oder eine Übergabe ohne Kontext als blockierend, eine etwas holprige Formulierung dagegen als etwas für das nächste Release.

Nach jeder Änderung erneut testen

Anrufgründe ändern sich, und damit auch die Abläufe. Ein neuer Zweig für einen Anrufgrund kann verändern, wie der Assistent einen anderen erkennt. Deshalb läuft dasselbe Testset nach jeder Änderung erneut:

1. Nehmen Sie die Änderung in einer Testumgebung vor, nie direkt auf der Live-Leitung.
2. Lassen Sie das vollständige Regressionsset laufen, nicht nur die Tests für den geänderten Schritt.
3. Vergleichen Sie mit dem letzten freigegebenen Lauf. Ein Test, der vorher bestanden hat und jetzt scheitert, ist das Erste, was Sie sich ansehen.
4. Erst freigeben, dann live schalten, und wissen, wie Sie zur vorherigen Version zurückkehren, wenn die Live-Zahlen etwas anderes zeigen.

Wie ein Release-Prozess für Sprachassistenten mit Versionen und einem Weg zurück aussehen kann, lesen Sie unter Versionskontrolle für KI-Agenten.

Compliance-Prüfungen gehören ins Testset

• Lassen Sie Ihre Begrüßung (Hinweis auf KI, Gesprächsaufzeichnung) vor dem Go-live von Ihrer Rechts- oder Datenschutzabteilung prüfen.

Nach dem Go-live: echte Anrufe zeigen, was die Tests übersehen haben

Kein Testset ist vollständig. Starten Sie mit einem Anrufgrund oder einem Teil der Anrufer und erweitern Sie, wenn die Zahlen stimmen. Sehen Sie sich in den ersten Wochen pro Schritt des Ablaufs an, wie viele Anrufe abgeschlossen, weitergeleitet und abgebrochen wurden: Der Schritt, an dem Anrufer auflegen oder nach einem Menschen fragen, ist die Stelle, an der Ihr Testset eine Lücke hatte. Nehmen Sie diese Anrufe in das Regressionsset auf. Wie Sie diese Zahlen lesen, erklärt So messen Sie Sprach-KI.

Häufig gestellte Fragen

Wie testet man Sprach-KI am Telefon? Rufen Sie den Assistenten über eine echte Telefonleitung an, mit einem Testset aus Ihren eigenen Anrufgründen. Halten Sie für jeden Testanruf fest, welchem Zweig er folgen soll, welche Werte erfasst werden, was sich im Backend ändern soll und wie der Anruf endet, und vergleichen Sie das mit dem tatsächlichen Verlauf. Testen Sie den normalen Verlauf und die Randfälle jedes Schritts, und wiederholen Sie das Set nach jeder Änderung.

Wie viele Testanrufe braucht man vor dem Go-live? Zählen Sie Abdeckung, nicht Anrufe. Jeder Zweig des Ablaufs braucht mindestens einen normalen Verlauf und seine Randfälle, jede schwierige Eingabe (Namen, Nummern, Daten) Tests mit verschiedenen Stimmen, und jeder Weg zu einem Mitarbeiter einen Übergabetest. Für die Erkennungsgenauigkeit empfiehlt Microsoft 30 Minuten bis 5 Stunden repräsentatives Audio mit von Menschen erstellten Transkripten.

Kann man Sprach-KI ohne echte Kundendaten testen? Ja, und das sollten Sie auch. Verwenden Sie Testkunden in einer Testumgebung, damit ein gescheiterter Test kein echtes Kundenkonto ändern kann. Echte Gesprächsaufnahmen helfen, realistische Testsätze zu bauen; klären Sie mit Ihrem Datenschutzbeauftragten, welche Aufnahmen und Transkripte Sie verwenden dürfen.

Was muss man nach einer Änderung am Ablauf erneut testen? Das gesamte Regressionsset, nicht nur den geänderten Schritt. Ein neuer Zweig oder Prompt kann verändern, wie der Assistent andere Anrufgründe erkennt. Vergleichen Sie deshalb jedes Ergebnis mit dem letzten freigegebenen Lauf, bevor die Änderung live geht.

Was ist der Unterschied zwischen Testen und Monitoring? Getestet wird, bevor Anrufer etwas davon merken, mit Anrufen, die Sie selbst entworfen haben, und Ergebnissen, die Sie vorher festgelegt haben. Monitoring findet nach dem Go-live statt, auf echten Anrufen: abgeschlossen, weitergeleitet und abgebrochen pro Schritt des Ablaufs. Das Monitoring zeigt, was Ihr Testset übersehen hat, und diese Anrufe wandern zurück ins Testset.

So testen Teams auf AssistYou

AssistYou ist die Plattform, mit der Kundenservice-Teams zuverlässige Sprachassistenten bauen, und unser Team hilft Ihnen bei der Einrichtung. Ihr Team gestaltet den Ablauf im Flow Designer, passt ihn dort an und sieht jedes Gespräch im Portal, und jede Änderung wird getestet, bevor sie live geht. Nach dem Go-live zeigt Agent Statistics, wie viele Anrufe der KI-Sprachassistent abgeschlossen, an einen Mitarbeiter weitergeleitet oder abgebrochen hat, mit den Abbrüchen pro Schritt direkt am Ablauf im Flow Designer. Mehr dazu auf der Produktseite, oder kontaktieren Sie unser Vertriebsteam, um einen Testplan für Ihre eigenen Anrufgründe durchzugehen.

← Zurück zum Blog