Conversational Copywriting

Conversational Copywriting ist eine von drei Disziplinen im Conversational Design. Neben dem Thema Conversational Copywriting ist die Technologie und Psychologie ein sehr entscheidender Baustein im gesamtheitlichen Conversational Design. Hierbei ist es wichtig auf ein Gleichgewicht der 3 Komponenten zu achten, um zu vermeiden, dass der Nutzer auf seiner Chatbot-Journey enttäuscht wird.

Bei der Entwicklung von Chatbots sind nicht nur technische Komponenten gefragt, sondern auch designorientierte. Im Conversational Design werden z.B. auch psychologische Aspekte betrachtet. Es stellen sich Fragen wie “Wie motiviere ich den Nutzer in der Konversation?”, “Wie beruhige ich ihn bei kritischen Fragen?” - Die Art der Kommunikation wird dementsprechend im Conversational Copywriting festgelegt. Es stellt das Formulieren der richtigen und passenden Chatbot Nachrichten dar. Beim Conversational Copywriting sollte man sich vor allem an den Konversationsmaximen orientieren.

Konversationsmaxime

  1. Maxime für Qualität: Liefere Informationen, die wahrheitsgetreu sind
  2. Maxime für Quantität: Liefere nur so viel Informationen wie nötig, nicht mehr
  3. Maxime für Relevanz: Liefere nur Informationen, die zielführend sind
  4. Maxime für Modalität: Vermeide mehrdeutige oder unklare Informationen

Diese Maxime legen den Grundstein für eine effektive Kommunikation.

Zudem sollten die Chatbot Nachrichten der Tonalität des Chatbots angepasst werden.

> Zurück zum BOTwiki - Das Chatbot Wiki


Conversational Testing

Conversational Testing ist ein Teil des Conversational Designs, welcher beim Erstellen der Conversational Map bzw. des Conversation Flows zum Tragen kommt. Denn hier werden Gesprächsstränge des Chatbots ausformuliert und in einer echten Konversation nachgespielt. Primär werden dabei die so genannten Happy Paths getestet, um die Tragfähigkeit des Szenarios zu bestätigen. Das Testing könnte folgendermaßen aussehen:

Vorgehensweise

  1. Zwei Gesprächspartner finden sich als Tester zusammen. Einer repräsentiert den Chatbot und einer den User.
  2. Ein Gesprächsstrang aus der Conversational Map wird zum Testen festgelegt.
  3. Die Testperson taucht in die Persönlichkeit des Chatbots ein.
  4. Die Testpersonen setzen sich Rücken an Rücken.
  5. Die Rolle des Nutzers versucht ein bestimmtes Problem mit dem Chatbot zu lösen und der Partner versucht so zu antworten, wie der Chatbot es tun würde.
  6. Das Gespräch wird aufgenommen und transkribiert.
  7. Die Konversation wird gegebenenfalls überarbeitet und somit optimiert.

Ziel des Conversational Testing ist es die Konversation so natürlich wie möglich mit dem User zu gestalten. Beim Conversational Copywriting werden unter Berücksichtigung der Chatbot Tonalität die Nachrichten zwar formuliert, allerdings ist es schwer ein Gefühl dafür zu bekommen, ob dies einer natürlichen Konversation entspricht. Conversational Testing kann zum Beispiel komplexe Formulierungen oder zu verschachtelte Sätze aufdecken.

Denn es gilt: Ein Mensch will in einem Chat genauso schreiben, wie er auch mit seinen Mitmenschen kommuniziert.

Eine weitere Möglichkeit, um die Tragfähigkeit eines Chatbots zu testen ist die Wizard of Oz Methode.

> Zurück zum BOTwiki - Das Chatbot Wiki


Actions on Google

Unter dem Begriff “Actions on Google” versteht man einen von Google entwickelten Service, mit dessen Hilfe Entwickler selbst entwickelte Dienste mit dem Google Assistant verknüpfen können. Sobald der Drittanbieter Dienst von Google getestet, genehmigt und zur Publizierung freigegeben wurde, kann dieser auf Google Assistant kompatiblen Geräten abgerufen werden. Google Actions ist demnach äquivalent zu Amazon Skills, allerdings können nur die Google Assistant fähigen Geräte bedient werden.

Auf welchen Geräten kann eine Action abgerufen werden?

Einerseits können die publizierten Actions über die von Google entwickelten smarten Lautsprecher Google Home und Google Home Mini abrufen werden. Andererseits sind sie auch auf Google Assistant kompatiblen Smartphones oder Tablets verfügbar. Google bedient mit Google Assistant sowohl Android als auch IOS Devices. Bei Geräten, welche das Betriebssystem Android verwenden, ist der Google Assistant vollumfänglich integriert und kann jederzeit vom Benutzer aktiviert werden. Bei IOS Nutzern muss eine separat Google Assistant App heruntergeladen werden.

Wie kann eine publizierte Action abgerufen werden?

Damit Anwender die publizierte Action aufrufen können, müssen der Action innerhalb der Google Actions Developers Console sogenannte “Invocation Phrases” hinterlegt werden. Dies sind Befehle, mit welchen der Benutzer dem Assistant mitteilt, eine bestimmte Action zu öffnen. Der Action können hierbei bis zu 5 Beispielsätze hinterlegt werden. Exemplarisch könnte ein Aufruf wie folgt aussehen:

  • “Ok Google, mit BOTfriends sprechen”

Wie kann eine publizierte Action mit Restriktionen versehen werden? 

Der Entwickler einer Google Action verfügt bei der Veröffentlichung seiner Action über verschiedene Möglichkeiten für Restriktionen. Einerseits kann bei der Publizierung darüber bestimmt werden, in welchen Sprachen die Action verfügbar sein soll (Stand 21.06.2019: 19 kompatible Sprachen). Zum anderen können Gerätespezifische Restriktionen eingerichtet werden. Hierzu müssen innerhalb der Google Actions Developer Console folgende Fragen beantwortet werd

  • Benötigt Ihre Action eine Audioausgabe?
  • Benötigt Ihre Action eine Bildschirmausgabe?
  • Benötigt Ihre Action eine Medienwiedergabe?
  • Benötigt Ihre Action einen Webbrowser?

Je nach Beantwortung der Fragen, werden bestimmte Geräte zugelassen oder ausgeschlossen. Wird beispielsweise ausgewählt, dass eine Bildschirmausgabe unerlässlich ist, wird die Action automatisch für den Google Home und Google Home Mini ausgeschlossen und ist daher auf diesen Devices nicht für den Nutzer abrufbar. Innerhalb der Google Actions Developer Console wird sofort nach Beantwortung der Frage tabellarisch dargestellt, welche Geräte inkludiert bzw. ausgeschossen wurden.

Wie kann eine Google Action entwickelt werden?

Google selbst beschreibt zwei Implementierungsmöglichkeiten. Die erste und einfache Variante ist eine direkte Integration über Google Dialogflow. Nach der Konzeption und Erstellung eines Voice Assistants innerhalb von Dialogflow, kann dieser ohne “Entwickler Know-How” direkt über den Integration Reiter von Dialogflow publiziert werden. Dies ist vor allem dann eine plausible Variante, falls als Natural Language Understanding Service sowieso Dialogflow im Einsatz ist. Eine weitere Integrationsmöglichkeit wird Entwicklern über das Google Actions SDK eingeräumt. Hier stellt Google Client-Libraries zur Erstellung von Google  Actions zur Verfügung. Diese sind für verschiedene Programmiersprachen verfügbar. Diese Variante macht primär dann Sinn, falls serverseitig eine volle Kontrolle über die Interaktion zwischen Google Action App und User gewährleistet werden soll. Des Weiteren ist diese Variante unumgänglich, falls als Natural Language Understanding Service auf eine andere Technologie wie Dialogflow vertraut wird.

 

> Zurück zum BOTwiki - Das Chatbot Wiki


Follow-Up Intents

Follow-Up Intents sind Intents die an einen vorgestellten Intent angeknüpft werden und somit einen Konversationsfluss bilden. Der Output Context des übergeordneten Intents wird automatisch als Input Context in den Follow-Up Intent angelegt. Der Begriff Follow-Up Intent kommt von dem NLP Service Dialogflow, welche die Funktion haben sehr einfach Konversationsflüsse anzulegen, ohne Kontexte manuell zu erstellen und verwalten zu müssen.

In Dialogflow hat man die Möglichkeit zwischen Predefined und Custom Follow-up Intents zu wählen.

Predefined Follow-Up Intents

Dialogflow gibt schon Predefined Follow-Up Intents vor, welche beim Anlegen bereits Trainingsphrasen beinhalten. Das hat den Vorteil, dass man keine Utterances mehr einpflegen muss und somit schneller Konversationen aufbauen kann. Gibt es zum Beispiel nach einer Frage die Möglichkeit mit Ja oder Nein zu antworten, werden diese jeweils als ein Predefined Follow-Up Intent angelegt. Dort befinden sich dann schon Trainingsphrasen wie "Ja", "Klar", "Aufjedenfall", "Ja bitte" oder "Nein", "Nee", "Ne, danke". Neben gängigen Follow-up Intents wie "Ja" oder "Nein" gibt es auch welche für "Abbruch", "Mehr" oder auch "Später". Außerdem gibt es noch einen Fallback Follow-up Intent, welcher dazu dient nicht passende Antworten vom User abzufangen und zur eigentlichen Frage zurückzuführen. Ein Beispiel:

Chatbot: "Möchtest du eine Bestellbestätigung zu deiner Pizza?" (Chatbot erwartet "Ja" bzw. "Nein" als Antwort vom User)

User: "Ich würde gerne eine weitere Pizza bestellen?"

Hier würde der Chatbot in den Fallback Follow-Up Intent springen, da dies keiner Ja/Nein Antwort entspricht. So könnte der Chatbot erneut nach einer Bestellbestätigung fragen, um zum Thema zurückzuführen.

Custom Follow-Up Intents

Bei den Custom Follow-Up Intents müssen vom User manuell die Trainingsphrasen eingepflegt werden. Die Contexte werden weiterhin automatisch angelegt.

Beispiel für Follow-Up Intents in Dialogflow:

Follow-up Intents in Dialgoflow

> Zurück zum BOTwiki - Das Chatbot Wiki


Insult Rate

Unter der der Insult Rate (dt. Beleidigungsrate) versteht man eine KPI in der Chatbot Analytics, die aussagt wie oft der Chatbot vom User beleidigt wird. Gab es beispielsweise zwei von ingesamt 20 Konversationen, bei denen eine Beleidigung vom User kam, ergibt sich daraus eine Insult Rate von 10 %. Oftmals stoßen Chatbots noch an ihre Grenzen, indem sie keine Antworten auf die Fragen der Nutzer haben oder falsche Informationen liefern. Dies resultiert meistens in Frustration beim User, wodurch Beleidigungen hervorgebracht werden. Manchmal treten Beschimpfungen auch ohne jegliche Gründe vom Nutzer auf. Denn die Hemmschwelle zur Beschimpfung im Internet ist aufgrund von Anonymität gering. Vor allem bei Chatbots, wo es sich um keine menschlichen Gesprächspartner handelt. Chatbots werden dementsprechend Opfer von sogenannten Trollen. Trolle kennt man aus den sozialen Netzwerken, die durch gegebene Kommentarfunktionen zu Postings ihre Meinungen auf provokante Weise kundtun. 

Generell gilt die Insult Rate als eine wichtige Metrik, die Aufschluss über User Acceptance oder die Effizienz des Chatbots geben kann. Bei Beobachtung der Insult Rate sollte man jedoch auch im Hinterkopf behalten, um welche Zielgruppe es sich handelt und welche Auswirkungen auch der spezielle Use Case haben kann.

> Zurück zum BOTwiki - Das Chatbot Wiki


Agents in Dialogflow

“Agents” lassen sich am besten als Natural Language Understanding (NLU)-Module beschreiben. Diese Module können in einer App, Website, Produkt oder Dienstleistung integriert werden und transferieren Text- oder gesprochene Benutzeranfragen in aussagekräftige Daten. Diese Transformation tritt auf, wenn die Äußerung eines Benutzers mit einer Absicht (Intent) in dem “Agent” übereinstimmt.

Der übereinstimmende Intent liefert dann eine Antwort an den Benutzer.

Diese Antwort kann ein einfacher Text oder eine gesprochene Bestätigung oder eine Webhook-Antwort. Zur Erstellung der Antwort können Typbezogene Parameter (wie z.B. Temperatur, Datum, Orte) aus der Anfrage erkannt werden. Zur Befüllung der Parameter mit tatsächlichen Werten kommen sogenannte “Actions” zum Tragen. Dabei können Anfragen des Benutzers an externe Dienste weitergeleitet werden um die gewünschten Parameter mit Werten zu befüllen.

Ein Agent ist der zentrale Einstiegspunkt einer Dialogflow Anwendung. Sämtliche Intents mit den dazugehörigen Utterances, Responses und Actions werden über den Agent gepflegt.

Erstellen eines Agents

Das Anlegen eines Agents muss auf der Startseite von Dialogflow durchgeführt werden. Die Erstellung über eine REST-API Schnittstelle ist nicht vorgesehen.

 

Beispiel wie Agents in Dialogflow erstellt werden

 

> Zurück zum BOTwiki - Das Chatbot Wiki

 


Quick Reply/ Schnellantworten/ Chips

Quick Replies sind eine Interaktionsform in Messaging Plattformen und erscheinen als Buttons unter einer Nachricht. Im Gegensatz zu Cards verschwinden die Quick Replies, nachdem sie betätigt wurden. Mit Hilfe der Quick Replies haben User die Möglichkeit sich durch Inhalte im Chatbot durchzuklicken anstatt ihre Anfrage im Eingabefeld einzutippen. Wird zum Beispiel vom Chatbot ein Button mit der Bezeichnung "Hilfe" angeboten ist es am Ende nichts anderes wie wenn der User "Hilfe" eintippt und abschickt. Die Kommunikation wird damit beschleunigt und die Nutzer bekommen eine Orientierung über die Themenfelder, die der Chatbot anbietet. 

Je nach Output Kanal bzw. Messaging Plattform werden unterschiedliche Namensgebungen für Quick Replies verwendet.

 

Messaging Plattform Bezeichnung
Facebook Messenger Schnellantworten, Quick Reply
Google Assistant Suggestion Chips
Microsoft Botframework Suggested Actions
Slack Slack interactive buttons
Skype HeroCard
Telegram Keyboard Buttons
Viber Keyboards

 

Hier ein Beispiel Bild für Quick Replies im Facebook Messenger: 

Quick Replies

Anwendung in Dialogflow

Wenn man in Dialogflow Intents erstellt oder bearbeitet findet man unter der Rubrik Response mehrere Möglichkeiten als Chatbot zu antworten. Unter anderem hat man die Möglichkeit das Format Quick Reply auszuwählen und in Form einer Liste die Buttons zu benennen. 

Eine Quick Reply Response wird in den Messaging Plattformen als vordefinierte User Antwort dargestellt, die durch das Anklicken an Dialogflow zurückgesendet wird.

 

> Zurück zum BOTwiki - Das Chatbot Wiki

 


Granularität von Intents

Die Granularität von Intents stellt die Detail- und Inhaltstiefe der Intents eines Chatbots dar. Das bedeutet, je granularer ein Chatbot aufgebaut wird, desto individueller kann dieser auf bestimmte Anfragen antworten. Dies wird im folgenden Abschnitt an einem einem Beispiel dargestellt:

  • Fein granularer Intent:

Frage: "Bietet der Bundestag Gruppenführungen an?"

Antwort: "Im Bundestag können auch Gruppenführungen gebucht wurden. Mehr Informationen und zur Buchung finden sie hier: www.bundestag.de/gruppenführungen"

  • Grob granularer Intent:

Frage: "Ist die Gruppenführung im Bundestag barrierefrei?"

Antwort: "Alle Informationen zu Gruppenführungen finden sie hier: www.bundestag.de/gruppenführungen"

Wie granular sollten Intents aufgebaut sein?

Die Granularität hängt sehr stark vom Use Case und der Komplexität ab. Häufig ist es zu Beginn sinnvoll, die Inhalte eines Chatbots nicht zu fein granular aufzuplanen. Man sollte während der Entwicklungs- und vor allem während der Testphase auf die Interaktion des Nutzers mit dem Chatbot achten, um dann noch entscheiden zu können, wie tief Nutzer in das Detail gehen wollen. Natürlich ist es möglich während und nach der Einführung des Chatbots noch an der Granularität zu justieren und neue Intents anzulegen, um die Detailstärke zu gewährleisten.

Welche Probleme auftreten können bei zu granularen Intents

Je tiefer man die Intents detailliert, desto schwieriger wird die Pflege des Contents eines Chatbots. Dabei hilft natürlich eine sprechende Benennung der angelegten Intents, um sicherzustellen, dass mehrere Entwickler an einem Chatbot arbeiten können. Allerdings gibt es noch eine weitere Herausforderung, die auftritt, wenn die Intents zu granular aufgebaut werden. Bei sich stark ähnelnden und sehr nah beieinander liegenden Anfragen ist es für den NLP-Service schwierig die richtige Absicht hinter der Anfrage eines Nutzers zu erkennen. Der NLP-Service muss durch das Erstellen von verschiedenen Fragemöglichkeiten (Utterances) entscheiden, wie sicher er sich ist, dass diese Anfrage zu dieser Absicht gehört. Wenn sich diese Fragemöglichkeiten zu sehr ähneln, sinkt der Confidence Score und die Maschine ist sich nicht mehr sicher welche Absicht sich hinter dieser Anfrage verbirgt.

Insgesamt ist zu sagen, dass ein Mittelweg gewählt werden sollte, der sich durch das Testen mit echten Nutzern herauskristallisieren wird.

 

> Zurück zum BOTwiki - Das Chatbot Wiki

 


Chatbot Training

Beim Chatbot Training spricht man von einer Verbesserung des Sprachverständnisses und einer Optimierung der Absichtserkennung hinter einer Nutzereingabe. Für das Chatbot Training ist es zum einen wichtig bestehende Nutzerabsichten mit weiteren Fragemöglichkeiten (Utterances) anzureichern und somit sicherzustellen, dass die Erkennungsrate (Confidence Score) ansteigt und somit die Absichten noch besser erkannt werden. Zum anderen ist es wichtig während des Betriebs die eingegangenen Fragen zu überprüfen und herauszufinden, ob Anfragen eingehen, für die kein Intent bzw. Absicht hinterlegt ist. In diesem Fall spielt der Chatbot die Fallback Message aus und kann auf die Frage keine Antwort geben. Um dies zu verbessern sollte der Chatbot trainiert werden und für die Anfragen, für die noch kein Inhalt vorliegt, Intents anzulegen.

Wann trainiert man den Chatbot? 

Das Chatbot Training sollte schon während der Entwicklungsphase stattfinden, um von Beginn an sicherzustellen, dass die passenden Inhalte auf die Anfragen ausgespielt werden. Trotzalledem ist das Training während des Chatbot Betriebs am Wichtigsten, weil dort “echte” Nutzer mit dem Chatbot interagieren und meist erst im Livebetrieb die Schwachstellen bzw. Inhaltslücken zum Vorschein kommen. Im Training ist sehr gut zu erkennen, mit welcher inhaltlichen Erwartungshaltung Nutzer auf den Chatbot zugehen und im Falle, dass Nutzer andere/weitere Inhalte erwarten, sollte zügig eingegriffen werden und der Chatbot weiter antrainiert werden.

Wie kann man den Chatbot trainieren? 

Dieses Training findet in den meisten Fällen direkt in den NLP-Services, wie beispielsweise Dialogflow statt. Hier findet man in einer extra dafür vorgesehenen Sektion Nutzerinterkationen vor, in der man erkennen kann, wie die NLP-Engine Intents zu Nutzeranfragen matched. Hierbei gibt es 3 mögliche Szenarien:

  1. der NLP-Service trifft mit der Nutzeranfrage den richtigen Intent
  2. der NLP-Service weist einer Nutzeranfrage einem falschen, bestehenden Intent zu
  3. der NLP-Service kann für die eingegebene Anfrage keinen Intent finden und spielt den Fallback-Intent aus

Beispiel Bild für die Trainingssektion in Dialogflow:

Trainingssektion in Dialogflow

 

> Zurück zum BOTwiki - Das Chatbot Wiki

 


Edge Case

Unter Edge Cases versteht man nicht erwartungsgemäße Ausgänge einer Konversation, die selten auftreten und somit Ausnahmen in der Konversation darstellen. Diese Edge Cases erstellt man unter anderem innerhalb der Conversational Map bzw. den Conversation Flows. Das Gegenstück zu Edge Cases stellen der Happy Paths dar. Hierbei beschreibt man die erwartungsgemäßen Ausgänge einer Konversation, die am häufigsten vom Nutzer genommen werden.

Beispiel für den Happy Path am Use Case "Pizza bestellen"

An diesem Beispiel wird dargestellt wie eine "glückliche" Konversation zwischen User und Chatbot aussehen kann bei einer Pizza Bestellung. Alle Informationen, welche der Nutzer dem Chatbot mitgibt können verarbeitet werden und es entstehen keine Missverständnisse.

Beispiel für den Happy Path

Beispiel für den Edge Case am Use Case "Pizza bestellen"

An diesem Beispiel erkennt man, dass es allerdings auch großes Fehlerpotenzial geben kann, wenn der User Antworten sendet, welche der Chatbot nicht verarbeiten kann. In der unteren Grafik wird gezeigt, dass der User eine Adresse eingibt, die außerhalb von Deutschland ist. In diesem Fall kann keine Lieferung stattfinden. Solche Edge Cases sollte man im Vorhinein bedenken und in der Conversational Map abbilden. Man sollte sich fragen, wie in solchen Situationen mit dem User umgegangen wird. Zum Beispiel informiert man den Nutzer, dass man nur innerhalb von Deutschland liefert oder man gibt ihm die Möglichkeit die Adresse erneut einzugeben im Falle eines Missverständnisses.

Beispiel für Edge Cases in Konversationen

> Zurück zum BOTwiki - Das Chatbot Wiki