Galerie

G-Force 2008: Für „intelligente“ Kundeninteraktion fehlen die Grammatik-Standards

Die Genesys G-Force-Kundenkonferenz stand dieses Jahr ganz im Zeichen der „intelligent Costumer Front Door“ (iCFD) – einem Konzept, das die „intelligente“ Annahme von Calls in Self Service-Portalen, das „intelligente“ Call Steering zum richtigen Agenten oder zur richtigen Self Service-Applikation und vice versa und somit auch die flexible Mischung von Self- und Assisted Services erreichen soll.

Kernproblem „intelligenter Kundeneingangstore“ ist die korrekte, die Absichten des Anrufers genau treffende Vorqualifizierung: Fehler bei der Erkennung des Anliegens schaffen Kunden-Frust und schädigen das Image des Betreibers.

Gerade bei größeren Voice Portalen, die eine Fülle von Diensten anbieten bzw. Anrufer mit einer großen Bandbreite verschiedener Anliegen unterstützen sollen, kann eine „intelligente“ Anrufannahme neben Kosteneinsparungen und Servicelevelverbesserungen vor allem eine größere Kundenzufriedenheit und damit auch Nutzungsbereitschaft zeitigen.

Doch gerade in großen Portalen wird man mit geführten Dialogen, die den Kunden quasi „an die Hand nehmen“, nicht sehr weit kommen – da die Menus, die das große Servicespektrum sinnvoll abbilden sollen, naturgemäß umfangreich sein müssen, was einer komfortablen Nutzung diametral entgegensteht.

Daher verfolgen Anbieter natürlichsprachiger Sprachportale wie z.B. HFN, SemanticEdge oder Sympalog, aber auch Genesys mit seiner iCFD den Ansatz, dem Nutzer natürlichsprachige Eingaben (oder: Open Prompts) zu ermöglichen nach dem Motto: „Hallo, hier ist Ihr Sprachcomputer – was darf ich für Sie tun?“   

Doch so einfach diese Frage klingt – die Verarbeitung der Antwort des Anrufers ist alles andere als trivial: Die Sprachanwendung muss nämlich in die Lage versetzt werden, alle unterschiedlichen, wahrscheinlichen, aber auch unwahrscheinlichen Äusserungen des Nutzers korrekt verarbeiten zu können. Die Problemstellung besteht dabei nach Aussage aller gesprochener Experten nicht in der Qualität der ASR-Spracherkenner, sondern vor allem in der Qualität der zugrundeliegenden Grammatik: Die muss auf alle möglichen Nutzereingaben vorbereitet sein, um fehlerlos und ohne Nachfragen  de Anrufer in eine Self Service-Applikation bzw. ins richtige Call Center/zum richtigen Agenten routen zu können.

Die Erstellung solcher Grammatiken ist nach wie vor eine „hohe Kunst“, die nur wenige Anbieter beherrschen, weil es laut der befragten Experten weder ausreichende Standards noch entsprechende Tools gebe, mit der die Entwicklung solcher Grammatiken vereinfacht und standardisiert werden kann.

Der vorhandene W3C-Standard beschreibt lediglich „antizipierende“ Grammatiken, die in dem hier diskutierten Szenario schwer umzusetzen sind, da mit zunehmendem Freiheitsgrad der Anwendung auch die Anzahl der Möglichen Antworten rasant wächst und die Wahrscheinlichkeit, alle möglichen Eingaben zu antizipieren, entsprechend sinkt.

Auch dass die Anbeiter solcher Portale im allgemeinen auf bereits in anderen Projekten entwickelte Grammatiken zurückgreifen können, schafft keine Lösung der Problemstellung, weil die die Besonderheiten des neuen Portals nicht mit abbilden können und die Grammatik auf diese Besonderheiten angepasst werden muss. 

Ein anderer Ansatz ist die Entwicklung von Grammatiken auf Basis statistischer Modelle. Das erfordert die Analyse von Gesprächsdaten, die natürlich bei einem neu zu entwickelnden Portal gar nicht vorliegen. Wenn sie vorliegen, weil das Portal bereits in Betrieb ist,  bewirkt die Nutzung von Grammatiken auf Basis statistischer Daten jedoch einen Systembruch: Weil der W3C-Standard „statistische“ Grammatiken gar nicht beschreibt, sind diese grundsätzlich proprietär, was bei der Interaktion der Anwendung mit VXML-Plattformen zu Problemen führen kann. Dies stellt insbesondere für die Anbieter von Hostingplattformen ein Problem dar, weil sie den Entwicklern der Anwendungen, die bei ihnen gehostet werden sollen, keine gültigen Standards vorgeben und die Systemfunktionalität nicht garantieren können.

Dynamische Grammatiken sind ein weiterer Ansatz, um mit „Open Prompting“ fertig zu werden. Dabei wird die Grammatik zur Laufzeit nach entsprechendem Bedarf dynamisch generiert, indem durch den Zugriff auf entsprechende, im System hinterlegte Bibliotheken die benötigten Informationen in die Grammatik integriert werden. Doch auch hier gilt wieder: Es gibt weder Standards, die den Entwicklern Sicherheit böten noch geeignete Entwicklungswerkzeuge, die den Entwicklern die geforderte Sicherheit geben bzw. den Entwicklungsprozess vereinfachen helfen.

Lange Rede, kurzer Sinn: Grammatiken sind aktuell ein Engpassfaktor für den Erfolg von Sprachportalen.

Einerseits erfordern nutzerfreundliche Sprachportale spezielle, sehr große und dennoch robuste Grammatiken, die in der Lage sind, auch ausserhalb enger Kontexte treffsicher die Eingaben der Nutzer zu erkennen.

Andererseits fehlen die nötigen Standards für die verschiedenen Lösungsansätze, sodass derzeit lediglich proprietäre Lösungen vorhanden sind, die eine „Industrialisierung“ der Grammatikentwicklung und damit günstigere Entwicklungskosten für natürlichsprachliche Portale behindern. Dazu kommt, dass aufgrund der fehlenden Standardisierung auch die Entwicklung von Entwicklungswerkzeugen für große, kontextübergreifende Grammatiken nicht richtig in Gang kommt.

Anwendungsentwickler fordern daher entsprechende Standardisierungsbemühungen der W3C für statistische und dynamische Grammatiken, um endlich eine gewisse Sicherheit für die weitere Entwicklung von Grammatik-Typen, aber auch Entwicklungswerkzeugen zu gewinnen.

Nur so ließen sich nachhaltige Durchbrüche in der Grammatikentwicklung erreichen und die Usability von Sprachportalen so steigern, dass es zu relevanten positiven Auswirkungen auf die Nutzerakzeptanz und somit den ROI von Sprachportalen komme. Denn solange die Entwicklung von NLU-Portalen aufgrund der beschriebenen Schwierigkeiten teuer und aufwändig bleibt, werden viele Betreiber weiter auf den geführten, durch starre Menus gesteuerten Dialog setzen – und zur weiteren Zementierung von Vorurteilen gegen den „blöden“ Sprachcomputern mit beitragen. Das kann doch niemand wollen, oder?

Advertisements

Kommentar verfassen

Bitte logge dich mit einer dieser Methoden ein, um deinen Kommentar zu veröffentlichen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s