Zuerst den POC (Proof of Concept) auf eine konkrete, umsetzbare Geschäftsanforderung reduzieren.
Die Auswahl von POC-Aufgaben sollte sich auf Aufgaben konzentrieren, bei denen die Regeln klar definiert sind, die Gesprächsmenge abschätzbar ist, die Ergebnisse überprüft werden können und bei Fehlern eine Korrektur möglich ist. Beispielsweise ist die Erstellung eines Arbeitsauftrags nach der Sammlung von Reparaturdaten sinnvoller als die allgemeine "Bearbeitung aller Kundenanfragen". Es ist wichtig, vor Beginn klare Anweisungen für den Gesprächseinstieg, erforderliche Felder, durchführbare Aktionen, verbotene Aktionen, Bedingungen für die manuellen Übernahme sowie die Quelle für die Unternehmens-API und das Testumfeld festzulegen. Wenn der Umfang nicht klar definiert ist, wird die Überprüfung lediglich zu einer subjektiven Bewertung.
Zuerst sollten wir die bestehenden manuellen Arbeitsabläufe festlegen und dokumentieren, bevor wir über den Einsatz von KI zur Verbesserung dieser Prozesse sprechen.
Ohne einen Vergleichswert ist es unmöglich festzustellen, ob sich die POC verbessert hat. Mindestens sollten Informationen darüber dokumentiert werden, wer derzeit für welche Aufgaben zuständig ist, wie Erfolg definiert wird, welche häufigen Fehler auftreten, wann es zu Wartezeiten kommt und welche Daten erneut eingegeben werden müssen sowie wie der menschliche Eingriff erfolgt. Die Vergleichsbasis muss nicht unbedingt eine schöne KPI sein; eine kleine Anzahl von bestätigten Fällen ist sinnvoller als Annahmen des Anbieters. Bei einem formellen Vergleich sollten die gleichen Aufgaben, ähnliche Bedingungen und eine einheitliche Definition von Erfolg verwendet werden.
Die Testfälle für den Goldstandard müssen sowohl normale, unscharfe als auch fehlgeschlagene Pfade abdecken.
Zunächst erstellen die Mitarbeiter aus den Bereichen Vertrieb, Kundenservice und Systemverantwortung gemeinsam die Eingabeanweisungen, erwarteten Fragen, erforderlichen Felder, erlaubten Aktionen und den endgültigen Zustand. Anschließend wird das System anhand dieser Dokumentation getestet. Die Beispiele sollten nicht ausschließlich aus standardisierten Sätzen bestehen, sondern auch die Möglichkeit beinhalten, dass Benutzer ihre eigenen Formulierungen verwenden, fehlende Daten, Homophone, Hintergrundgeräusche, Stille, Unterbrechungen, API-Timeout und die Interaktion mit echten Personen. Wenn Namen, Adressen, Beträge oder Identifikationsdaten verwendet werden, muss zusätzlich geprüft werden, ob die KI die Informationen korrekt wiederholt, anstatt nur zu prüfen, ob sie den Wortlaut exakt wiedergeben.
Mindest-Testkriterien für einen Proof-of-Concept (POC) für KI-gestützte Sprachdienstleistungen| Kontext | Worauf sollte man achten? | Überprüfbare Ergebnisse |
|---|
| Erfolgreich abgeschlossen | Erforderliche Felder, Reihenfolge der Nachfragen und Werkzeugaufrufe | CRM-Daten / Arbeitsaufträge / Status der Auftragsvergabe stimmen mit den Gesprächsaufzeichnungen überein. |
| Die Informationen sind unklar oder widersprüchlich. | Soll der alte Wert erneut überprüft und überschrieben werden? | Nur die letzten bestätigten Daten werden gespeichert, um doppelte Bestellungen zu vermeiden. |
| Verständnisschwierigkeiten aufgrund von Sprachmissverständnissen | Geringes Selbstvertrauen, wiederholte Fragen und die Notwendigkeit, menschliche Unterstützung zu suchen. | Der Fehler wurde nicht direkt in das offizielle System geschrieben. |
| API-Timeout oder Ablehnung | Antworten, erneutes Ausführen, Bearbeitung und Idempotenz | Es ist nicht notwendig, zunächst den Erfolg zu verkünden; der finale Status kann nachträglich verfolgt werden. |
| Anforderungen an Personen oder Situationen mit hohem Risiko | Die Übergangsroute wird mit dem Kontext verbunden. | Automatische Erfassung von bereits bestätigten Feldern und ungelösten Problemen |
Die Metriken müssen auf die jeweiligen Aufgaben abgestimmt sein und dürfen nicht nur die Erkennungsrate berücksichtigen.
Eine korrekte Spracherkennung bedeutet nicht automatisch, dass die Aufgabe erfolgreich ist. Fehler in der Transkription müssen nicht zwangsläufig Auswirkungen auf das Ergebnis haben. Die Überprüfung sollte folgende Aspekte berücksichtigen: Vollständige Erledigung der Aufgabe, korrekte Angaben in den erforderlichen Feldern, erfolgreiche Nutzung der Tools, Verständnis, alternative Lösungen, planmäßige Übergabe, unerwartete Upgrades, Aufgabe durch den Nutzer, Verzögerungen bei der Antwort und manuelle Korrekturen. Für jeden dieser Aspekte müssen klare Kriterien und Datenquellen festgelegt werden, beispielsweise die "Erfolgreiche Testkonversation" als Grundlage, die durch Telefonaufzeichnungen, Modellereignisse, API-Protokolle und den Zustand des Unternehmenssystems überprüft wird.
Die Überprüfung umfasst sowohl die Qualität der Kommunikation als auch die Ergebnisse des Systems.| Kennzahlen | Definition | Vermeidung von Fehlinterpretationen |
|---|
| Prozentualer Abschluss der Aufgaben | Prozentsatz der Gespräche, die den definierten Umfang erfüllen und den korrekten Endzustand aufweisen. | Ein Gespräch allein kann nicht als abgeschlossene Arbeitsauftrag gewertet werden. |
| Korrektheit der erforderlichen Felder | Spalte zur Bestätigung: Übereinstimmung mit der tatsächlichen Antwort | Durch den Durchschnittswert können wichtige Felder wie Adresse oder Betrag nicht mehr eindeutig identifiziert werden. |
| Werkzeug erfolgreich ausgeführt | Die API-Funktion wurde erfolgreich ausgeführt und hat keine doppelten oder fehlerhaften Nebenwirkungen. | Eine Online-Transaktion kann nicht einfach als Erfolg oder Misserfolg gewertet werden, wenn sie nicht rechtzeitig abgeschlossen wird. |
| Missverständnisse und alternative Lösungen | Das System kann die Häufigkeit von Wiederholungsfragen nicht verstehen oder verarbeiten. | Es ist wichtig, zwischen einer sinnvollen und konstruktiven Befragung und einer ziellosen Wiederholung zu unterscheiden. |
| Manuelle Eingabe | Geplante Übertragung, unerwartete Eskalationen und Benutzeranfragen | Der Einsatz von KI ist nicht per se ein Fehlschlag. Es hängt davon ab, warum er eingesetzt wird. |
Die Höhe des Übergangs muss entsprechend den Kosten für die Fehlerkonfiguration festgelegt werden.
Es gibt keine allgemeine Erfolgsgrenze für alle KI-Telefonanlagen. Die Kosten für die Behebung von Fehlern bei der Abfrage von Öffnungszeiten und der Änderung von Zahlungsinformationen unterscheiden sich erheblich; selbst ein einziger Fehler in der Adresse kann schwerwiegender sein als eine unnatürliche Formulierung. Die Lösung besteht darin, die Fehler in drei Kategorien zu unterteilen: solche, die automatisch wiederholt werden können, solche, die eine manuelle Überprüfung erfordern, und solche, die nicht automatisch durchgeführt werden dürfen. Für jede Kategorie sollten dann Schwellenwerte und Verantwortliche festgelegt werden. Wenn die Datenmenge unzureichend ist, kann man nur sagen, dass der POC (Proof of Concept) bestimmte Probleme noch nicht aufgedeckt hat, und man kann nicht daraus schließen, dass die Anlage in einer realen Umgebung zwangsläufig erfolgreich sein wird.
Die Abnahme muss auch überprüfen, ob das System auch nach einem Fehler noch betriebsbereit ist.
Bei einer formellen Dienstleistung treten zwangsläufig Probleme wie Ausfall der Telekommunikation, Überschreiten von Zeitlimits, Fehler bei Unternehmens-APIs, Überlastung von Warteschlangen und Wartungsarbeiten durch den Anbieter auf. Der POC (Proof of Concept) muss sicherstellen, dass jede Art von Fehler eine eindeutige Rückmeldung erzeugt, den Status der Daten klar darstellt, wer benachrichtigt wird und ob eine sichere Wiederholung nach der Behebung möglich ist. Die Benutzeroberfläche und das Backend müssen Fehler vollständig und verständlich anzeigen, ohne Ausnahmen zu ignorieren und den Eindruck zu erwecken, dass der Fall bereits bearbeitet wurde.
GoGoCha kann nicht als Beweis für eine bestimmte Architektur dienen, sondern nur als allgemeine Prüfdaten.
GoGoCha hat Fallstudien veröffentlicht, die zeigen, dass Falcon Lösungen für KI-basierte Telefonintegrationen, gemeinsame Auftragsabwicklung, Warteschlangen, Echtzeit-Benachrichtigungen sowie die Integration von Website, LINE, App und Backend bereitgestellt hat. Die Fallstudien enthalten jedoch keine öffentlich verfügbaren Daten zu Genauigkeit, durchschnittlicher Verzögerung, Anrufquote, eingesparter Arbeitskraft oder formellen Service Level Agreements (SLAs). Daher können diese Zahlen nicht als Grundlage für die Festlegung von Anforderungen für andere Unternehmen verwendet werden. Die neue Proof-of-Concept-Phase muss weiterhin auf den spezifischen Telefonumfeld, die Sprache der Zielgruppe und die Aufgaben der jeweiligen Firma zugeschnitten sein.
Welche Ergebnisse müssen vor dem Übergang von der Proof of Concept (POC) zur offiziellen Version erstellt werden?
Es ist wichtig, mindestens folgende Elemente zu dokumentieren: Testfälle, die konsistent sind; Detaillierte Ergebnisse; Nicht identifizierte Risiken; Systemarchitektur; Datenfluss; Berechtigungen; Überwachung; Prozesse für manuelle Eingriffe und Wiederherstellung Für die finale Version sind außerdem Tests unter Spitzenlast und mit realen PBX-/SIP-Systemen, Notfallpläne, Aufzeichnungsrichtlinien und Betriebsberechtigungen erforderlich. Der Proof of Concept zeigt lediglich, dass die Weiterentwicklung lohnenswert ist, aber nicht, dass die finale Lösung ohne weitere Anpassungen direkt eingesetzt werden kann.
