Allgemeine Best Practices für das Design von Kundenservicemitarbeitern

In diesem Leitfaden finden Sie allgemeine Best Practices für die Gestaltung aller Arten von Kundenservicemitarbeitern.

Sehen Sie sich auch den Leitfaden zum Design von Voice-Agents an, der speziell auf das Design von Voice-Agents ausgerichtet ist, und den Leitfaden zu den Best Practices für die Verwendung des Conversational Agents-Dienstes (Dialogflow CX).

Allgemeine Empfehlungen

Agents iterativ entwickeln

Wenn der Agent groß oder komplex ist, erstellen Sie zuerst einen Dialog, in dem nur Anfragen der obersten Ebene behandelt werden. Nachdem Sie die Grundstruktur erstellt haben, testen Sie die Dialogpfade, um zu überprüfen, ob sie alle möglichen Routen abdecken, die ein Endnutzer durchlaufen kann.

Während Sie Ihren Bot weiterentwickeln, sollten Sie die Funktion Testfälle für die testgetriebene Entwicklung verwenden.

Vordefinierte Agents

Conversational Agents (Dialogflow CX) bietet Agent-Vorlagen, die Ihnen den Einstieg erleichtern. Vordefinierte Agents decken gängige Anwendungsfälle wie Finanzdienstleistungen, Telekommunikation und Reisen ab. Sie enthalten bereits Intents und Entitäten, die häufig gestellte Anfragen abdecken. Fügen Sie für Ihr Unternehmen spezifische Routen und Ausführungen hinzu und Sie haben in kürzester Zeit einen funktionierenden Agent.

Integrationen und Dienste verknüpfen

Es gibt mehrere Möglichkeiten, Conversational Agents (Dialogflow CX) zu integrieren. Dieser Abschnitt enthält Best Practices für die Auswahl der Integrationsmethode.

Integrationen

Integrationen für Konversations-Agenten (Dialogflow CX) bieten eine sofort einsatzbereite Benutzeroberfläche für Ihren Agenten. Wenn Sie eine Integration verwenden, müssen Sie die API für Konversations-Agenten (Dialogflow CX) nicht direkt aufrufen, da dies von Integrationen übernommen wird. Diese Integrationen können einen Chatbot bereitstellen, den Sie auf Ihrer Website einbetten, eine Verbindung zu anderen Messaging-Plattformen herstellen oder eine Telefonschnittstelle bereitstellen können.

Conversational Agents (Dialogflow CX) API

Wenn keine der vorgefertigten Integrationen geeignet ist oder Sie die Benutzeroberfläche für Ihr System anpassen möchten, können Sie die API für Konversationsagenten (Dialogflow CX) direkt verwenden. Bei diesem Ansatz müssen Sie die Benutzeroberfläche für Ihren Bot implementieren oder eine vorhandene Benutzeroberfläche verwenden.

Webhooks

Sofern Ihr Agent nicht vollständig mit statischen Daten definiert werden kann, müssen Sie webhooks verwenden, um Ihren Dienst zu verbinden und einen Agenten bereitzustellen, der dynamische Szenarien verarbeiten kann. Das gilt unabhängig davon, ob Sie Integrationen oder die Conversational Agents API (Dialogflow CX) verwenden.

Ressourcen für Kundenservicemitarbeiter

Ressourcen für Conversational Agents (Dialogflow CX) können auf viele Arten verwendet werden, um ein gewünschtes Ergebnis zu erzielen. In diesem Abschnitt finden Sie Ratschläge zur Auswahl der richtigen Ressourcen für die richtigen Szenarien.

Abläufe und Seiten

Abläufe und Seiten bieten Struktur für Kundenservicemitarbeiter. Sie können sich Seiten als Knoten in einem Zustandsautomaten und Flüsse als Gruppen ähnlicher Seiten vorstellen. Über Status-Handler steuern Sie Übergänge zwischen Knoten. Sie werden aufgerufen, wenn eine Absicht übereinstimmt, eine Bedingung erfüllt ist oder ein Ereignis aufgerufen wird.

Ein einfacher Agent funktioniert möglicherweise gut mit einem einzigen Ablauf, aber komplexe Agenten sind fast immer besser mit mehreren Abläufen konzipiert. Jeder Ablauf sollte ein allgemeines Thema für den Kundenservicemitarbeiter darstellen. Jede Seite, die mit dem Ablauf verknüpft ist, sollte dabei helfen, das Thema zu bearbeiten. Außerdem kann jeder Ablauf eigene Einstellungen haben und von einer Teilmenge der Teammitglieder verwaltet werden. Das hilft, die Arbeit beim Entwerfen großer Bots zu verteilen.

Wenn Sie einen großen, komplexen Agenten entwerfen, müssen Sie die Limits für Abläufe pro Agent und Seiten pro Ablauf berücksichtigen. Diese Limits tragen dazu bei, dass Ihr Agent leistungsfähig bleibt.

Wenn Ihr Design zu viele Abläufe pro Kundenservicemitarbeiter enthält, kombinieren Sie ähnliche Themen in einem einzigen Ablauf. Sie können beispielsweise die folgenden Themen zu einem einzigen Ablauf für „Guthaben abrufen“ kombinieren:

• Girokontostand abrufen
• Guthaben abrufen
• Hypothekenrestschuld abrufen
• Guthaben abrufen

Wenn Ihr Agentendesign zu viele Seiten pro Ablauf hat, kombinieren Sie ähnliche Seiten und verwenden Sie viele Routen pro Seite.

Wenn Sie weiterhin Probleme mit dem Ablauf und den Seitenlimits haben, kann das daran liegen, dass Sie zu viel Geschäftslogik in den Agenten selbst eingebunden haben. Sie sollten diese Logik in Webhooks verschieben.

Im Folgenden sind die Detailebenen der Konversationssteuerung für Kundenservicemitarbeiter in absteigender Reihenfolge aufgeführt:

1. Kundenservicemitarbeiter (ein Kundenservicemitarbeiter bearbeitet alle Unterhaltungen)
2. Abläufe (ein Ablauf verarbeitet ein oder mehrere zugehörige Unterhaltungsthemen)
3. Seiten (eine Seite verarbeitet einen oder mehrere zusammenhängende Konversationsschritte)
4. Routen (eine Route verarbeitet einen Nutzer-Intent oder eine Bedingungsüberprüfung)

Intent-Parameter im Vergleich zu Formularparametern

Die Hauptmethode, mit der Ihr System strukturierte Daten vom Endnutzer erhält, sind Parameter. Sie können Parameter entweder für Intents (Intent-Parameter) oder für Seiten (Formularparameter) verwenden.

Der Hauptzweck einiger Seiten besteht darin, bestimmte Informationen vom Endnutzer zu erfassen. Beispielsweise kann eine Seite so konzipiert sein, dass die Kontaktdaten des Endnutzers erfasst werden. In diesem Fall sollten Sie immer Formularparameter verwenden, um diese Informationen zu erfassen.

In einigen Fällen möchten Sie möglicherweise Informationen zu Endnutzern erfassen, während sie von einer Seite zur nächsten wechseln. Wenn der Endnutzer beispielsweise zu Beginn des Gesprächs ein bestimmtes Produkt anfordert, sollten Sie das gewünschte Produkt erfassen, während Sie zur entsprechenden Bestellseite wechseln. Verwenden Sie in diesem Fall Intent-Parameter als Teil von Intent-Routen.

Es gibt auch Situationen, in denen die Verwendung sowohl von Intent- als auch von Formularparametern ideal ist. Wenn der Endnutzer beispielsweise zu Beginn des Gesprächs ein kleines T-Shirt anfordert, sollten Sie den gewünschten Größenparameter („small“) erfassen, während Sie zur Seite für die T-Shirt-Bestellung wechseln. Auf der Seite zur Bestellung des T-Shirts werden möglicherweise zusätzliche Informationen wie die gewünschte Farbe abgefragt. Die Seite für die T-Shirt-Bestellung sollte Formularparameter für Größe und Farbe haben. In diesem Beispiel wurde der Parameter „Größe“ bereits angegeben und weitergeleitet, sodass der Kundenservicemitarbeiter nur die Farbe anfordert. Andere Unterhaltungen können jedoch einen anderen Pfad verfolgen, bei dem der Endnutzer die gewünschte Größe nicht angegeben hat, als die Seite für die Bestellung des T-Shirts aktiv wird. Wenn Sie diesen Parameter auf beide Arten definieren, kann Ihr Bot die Informationen flexibler extrahieren.

Hinweis :Wenn Sie Parameter mit derselben ID oder demselben Anzeigenamen in verschiedenen Intents oder Formularen definieren, müssen der Entitätstyp und andere Einstellungen für alle Definitionen gleich sein. Wenn sich der Entitätstyp oder andere Parametereinstellungen unterscheiden, verwenden Sie für jede Definition eine eindeutige Parameter-ID oder einen eindeutigen Anzeigenamen.

Routen und Routengruppen

Wenn Sie zu einer anderen Seite wechseln, eine Antwortnachricht in die Warteschlange stellen oder einen Webhook aufrufen möchten, wenn ein Intent zugeordnet oder eine Bedingung erfüllt wird, verwenden Sie Routen.

Wenn Sie auf mehreren Seiten dieselben Routen verwenden, sollten Sie Routengruppen verwenden. So vermeiden Sie unnötige Duplikate in Ihrem Agent-Design.

Intent-Wiederverwendung

Wenn Sie mehrere Intents mit ähnlichen Trainingsformulierungen definieren, sollten Sie überlegen, die Intents auf mehreren Seiten wiederzuverwenden. Idealerweise sollten Sie einige allgemeine Intents definieren, die auf vielen Seiten verwendet werden, und einige spezifische Intents, die nur auf einer einzelnen Seite verwendet werden. So vermeiden Sie unnötige Duplikate in Ihrem Agent-Design.

Bestätigungsabsichten sollten beispielsweise am besten als wiederverwendbare Absichten definiert werden. Ein confirmation.yes-Intent könnte folgende Trainingsformulierungen enthalten:

• Ja
• Ja
• Ja
• Ok
• Ja, das tue ich.
• Und ob
• absolut
• Ja, bitte.

Ein confirmation.no-Intent könnte folgende Trainingsformulierungen enthalten:

• no
• nah
• Nein
• Auf keinen Fall
• Nicht für mich
• Auf keinen Fall
• Nein, danke.

Diese wiederverwendbaren Bestätigungsabsichten können in vielen Szenarien für Ihren Kundenservicemitarbeiter verwendet werden.

In einigen Fällen sollten Sie auch spezielle Bestätigungsabsichten erstellen. Wenn Sie beispielsweise eine Bestellung bestätigen möchten, kann es sinnvoll sein, einen speziellen order.confirmation.yes-Intent mit Trainingsformulierungen wie den folgenden zu haben:

• Die Bestellung sieht für mich in Ordnung aus.
• Ich akzeptiere diesen Auftrag

Außerdem einen speziellen order.confirmation.no-Intent mit folgenden Trainingsformulierungen:

• Ich möchte diese Bestellung nicht
• Ich akzeptiere diesen Antrag nicht

Wenn Ihre Bestellbestätigungsseite aktiv ist, sollten Intent-Routen für alle vier dieser Intents vorhanden sein. So wird sichergestellt, dass jede allgemeine oder spezifische Bestätigung des Endnutzers ordnungsgemäß verarbeitet wird.

Standardmäßig auszuschließender Intent

Sie sollten den Standard-Negativ-Intent mit Formulierungen füllen, die Ihre Endnutzer möglicherweise sagen, die aber keinem Intent in Ihrem Agenten entsprechen sollten.

Auftragsausführung

Es gibt viele Möglichkeiten, mithilfe von Auftragsausführungen auf den Endnutzer zu reagieren. Während einer Unterhaltungsrunde kann der Kundenservicemitarbeiter der Antwortwarteschlange mehrere Nachrichten anhängen. Die zusammengesetzte Warteschlange wird am Ende der Unterhaltungsrunde an den Endnutzer gesendet. In diesem Abschnitt werden die einzelnen Optionen zum Erstellen der einzelnen Nachrichten beschrieben.

• Seiteneinstiegs-Auftragsausführung: Diese Auftragsausführung wird aufgerufen, wenn die Seite erstmals aktiv wird. Sie ist nützlich, wenn Sie eine Nachricht benötigen, die den Zweck der Seite beschreibt. Sie sollte nur einmal ausgesprochen werden, solange die Seite aktiv ist. Beispiel:
  • Was möchten Sie über Ihr Girokonto wissen?
  • Welche Art von Produkt möchten Sie kaufen?
  • Ich benötige einige Informationen zum Hemd, das Sie bestellen möchten.
• Routen: Diese Auftragsausführung wird aufgerufen, wenn entweder eine Intent-Route oder eine Bedingungsroute mit Auftragsausführung aufgerufen wird. Das ist nützlich, wenn Sie eine Nachricht benötigen, die dem Endnutzer über die Intent-Übereinstimmung, die erfüllte Bedingung (z. B. eine Bedingung für den Abschluss des Ausfüllens eines Formulars) oder die Weiterleitung informiert. Beispiel:
  • Ja, Ihr internationaler Tarif gilt auch für Japan. (Intent-Abgleich)
  • Sind Sie sicher, dass Sie 300 Hemden kaufen möchten? (Vergleichsbedingung erfüllt)
  • Okay, Ihr Termin ist morgen um 7:00 Uhr. (Ausfüllen eines Formulars)
  • Okay, reden wir jetzt über Erdmännchen. (Übergang)
• Ereignis-Handler: Diese Auftragsausführung wird aufgerufen, wenn ein Ereignis aufgerufen wird. Das ist nützlich, wenn Sie eine Nachricht benötigen, die auf das Ereignis reagiert. Beispiel:
  • Die Aktie, die Sie kaufen möchten, hat gerade um 10 % an Wert gewonnen. (benutzerdefiniertes Ereignis)
  • Können Sie das anders formulieren? (Ereignis vom Typ „Keine Übereinstimmung“)
• Erste Aufforderungen für Formulare: Diese Auftragsausführung wird aufgerufen, wenn der Kundenservicemitarbeiter ein Formular ausfüllt. In diesen Nachrichten sollte dem Endnutzer eine bestimmte Frage gestellt werden. Für jeden Formularparameter gibt es eine eigene anfängliche Promptausführung. Beispiel:
  • Welche Größe soll das Hemd haben?
  • Welche Farbe soll das Hemd haben?
• Handler für die erneute Eingabeaufforderung für Formulare: Diese Ausführung wird aufgerufen, wenn der Agent ein Formular ausfüllt und die Auswahl des Endnutzers für den aktuellen Parameter nicht versteht. Diese Ausführung ist nur erforderlich, wenn sich die Nachricht für die erneute Aufforderung von der ursprünglichen Aufforderungsnachricht unterscheiden soll. Wenn keine Handler für die erneute Eingabeaufforderung vorhanden sind, verwendet der Kundenservicemitarbeiter einfach die erste Aufforderung als Aufforderung zur erneuten Eingabe. Beispiel:
  • Ich verstehe nicht. Geben Sie bitte eine gültige Farbe für das Hemd an.

Benennung

In diesem Abschnitt finden Sie Tipps zur Benennung von Ressourcen für Kundenservicemitarbeiter.

Intent-Benennung

Wenn Ihr Agent viele Intents hat, sollten Sie ein Namensschema in Betracht ziehen, mit dem Sie diese besser organisieren können. Es ist üblich, Intent-Namen mit Satzzeichen zu segmentieren, wobei die Genauigkeit von links nach rechts zunimmt. Darüber hinaus sollte ein Intent-Name die Absicht des Endnutzers für eine Unterhaltungsrunde widerspiegeln.

Es gibt viele gute Namensschemas, beispielsweise:

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• account.balance.get
• account.balance.pay
• account.address.get
• account.address.update

Übergänge

In Status-Handlern definierte Übergänge ermöglichen die Steuerung der Unterhaltung durch Ändern der aktiven Seite. In diesem Abschnitt findest du Tipps zur Organisation von Übergängen für Kundenservicemitarbeiter.

Kostenlose Übergänge

Berücksichtigen Sie beim Definieren einer Route, die einen Übergang auslöst, dass es möglicherweise eine ergänzende oder umgekehrte Route gibt.

Beispiel:

• Wenn Sie eine Intent-Route für confirmation.yes haben, sollten Sie eine weitere Route für confirmation.no definieren.
• Wenn Sie eine Bedingungsroute mit einem booleschen Operator = definieren, sollten Sie auch eine weitere Route mit != definieren.

Nutzereingaben verarbeiten

Dieser Abschnitt enthält Richtlinien für Intents und Trainingsformulierungen, damit Ihr Agent die Eingaben von Endnutzern optimal verarbeiten kann.

Mindestens 20 Trainingsformulierungen definieren

Für jeden Intent sollten mindestens 20 Trainingsformulierungen vorhanden sein. Andernfalls hat das NLU-Modell möglicherweise nicht genügend Informationen, um Ihre Absicht richtig zuzuordnen. Dies ist eine Mindestanforderung. Idealerweise sollten Sie mehr definieren, insbesondere für Haupt-Intents großer Bots, für die etwa 50 wünschenswert sind.

Achten Sie auf Voreingenommenheit

Wenn für einen oder mehrere Intents deutlich mehr Trainingsphrasen als für andere Intents vorhanden sind, führt dies aufgrund von ungleich verteilten Daten zu einer Verzerrung des NLU-Modells zugunsten der größeren Intents. Dieser Voreingenommenheit kann auftreten, wenn sich die Anzahl der Trainingsphrasen um eine Größenordnung oder mehr unterscheidet.

In einigen Fällen ist das erwünscht, da Sie einige Intents definieren können, die häufiger als andere abgeglichen werden sollten, da sie Eingaben von Endnutzern entsprechen, die im Live-Traffic häufiger vorkommen.

In anderen Fällen ist dieses Verhalten möglicherweise nicht erwünscht, weil Sie keine Voreingenommenheit zugunsten dieser größeren Absichten wünschen. In diesem Fall sollten Sie die Anzahl der Trainingsphrasen für diese größeren Intents so reduzieren, dass sie in etwa der Größe der anderen Intents entspricht. Beispiel:

Trainingsformulierungen für Intent A	Trainingsformulierungen für Intent B	Voreingenommenheit für Absicht B
20	50	Nein
20	200	Grenzwertig
20	2000	Ja

Verwendung von Entitäten und Anzahl der Trainingssätze

Für alle Entitätstypen, die in einer Absicht verwendet werden:

• Annotieren Sie jedes Beispiel für die Entitätstypen.
• Geben Sie für jeden Entitätstyp mindestens fünf Trainingsformulierungen mit kommentierten Beispielen an.
• Geben Sie mindestens dreimal so viele Trainingsformulierungen wie Entitätstypen an. Wenn Sie beispielsweise 10 verschiedene Entitätstypen für Anmerkungen in einem Intent verwenden, sollten Sie mindestens 30 Trainingsformulierungen haben.

Trainingsformulierungen sollten natürlich sein

Trainingsphrasen sollten dialogorientiert und natürlich sein und dem entsprechen, was Nutzer tatsächlich sagen. Verwenden Sie nach Möglichkeit Eingaben von Endnutzern, die in der Produktion aufgetreten sind, als Trainingsdaten. Achten Sie dabei besonders auf die häufigsten.

Erforderliche Vielfalt von Trainingsformulierungen

Fügen Sie Variationen von Fragen, Befehlen und Verben sowie Synonyme für häufig verwendete Substantive hinzu, damit Ihre Formulierungen ein breites Spektrum möglicher Anfragen abdecken.

Es ist am besten, einige kürzere Wortgruppen wie „Meine Rechnung bezahlen“ sowie längere Wortgruppen und Sätze wie „Ich habe gerade etwas in der Post bekommen, in dem steht, dass ich meinen Kontostand bezahlen muss“ aufzunehmen. Es gibt keinen empfohlenen Anteil kurzer zu langer Wortgruppen. Sie sollten sich jedoch an den tatsächlichen Eingaben der Endnutzer orientieren, die in der Produktion an Ihren Kundenservicemitarbeiter gesendet werden.

Es ist wichtig, Trainingsformulierungen zu definieren, die sich in Länge, Formulierung und Satzstruktur unterscheiden, um eine gute Schulung für Ihren Kundenservicemitarbeiter zu ermöglichen. Es ist nicht notwendig, Vielfalt um der Vielfalt willen zu schaffen, aber es ist notwendig, genügend Vielfalt zu bieten, damit das NLU-Modell die Absicht des Endnutzers aus einer Vielzahl von Eingaben des Endnutzers erfolgreich erkennen kann. Wenn die Vielfalt nicht ausreicht, besteht die Gefahr einer Überanpassung. Mit anderen Worten: Es besteht die Gefahr, dass das Modell zu eng mit den von Ihnen angegebenen Beispielen verknüpft ist und nicht ausreichend auf andere Beispiele generalisiert werden kann.

Groß- und Kleinschreibung

Die Groß- und Kleinschreibung hängt davon ab, welches NLU-Modell der Kundenservicemitarbeiter verwendet.

Standard-NLU

Beim Standard-NLU-Modell wird die Groß- und Kleinschreibung nicht berücksichtigt. In seltenen Fällen müssen Sie möglicherweise Trainingsphrasen hinzufügen, die sich nur in der Groß- und Kleinschreibung unterscheiden. Dies gilt in der Regel für Situationen, in denen Sie davon ausgehen, dass Endnutzer Text nur in Großbuchstaben eingeben.

Alternative Ansätze könnten sein:

• ML-Klassifizierungsschwellenwert senken
• Endnutzereingaben werden in Kleinbuchstaben geschrieben, bevor sie an Conversational Agents (Dialogflow CX) gesendet werden.

Erweiterte NLU

Im Gegensatz zum Standard-NLU-Modell wird beim erweiterten NLU-Modell zwischen Groß- und Kleinschreibung unterschieden. Wir empfehlen, die relevanten großgeschriebenen Trainingsdaten zu testen und hinzuzufügen, um die Abgleichsraten für die Nutzerabsicht zu erhöhen.

Unnötige Vielfalt von Trainingsformulierungen

Vermeiden Sie unwesentliche Variationen bei Trainingsphrasen, da sie dem NLU-Modell doppelte Informationen liefern. Fügen Sie beispielsweise keine Varianten hinzu, die sich nur in folgenden Punkten unterscheiden:

• Groß- und Kleinschreibung: Wenn Sie das Standard-NLU-Modell verwenden, vermeiden Sie in den meisten Fällen doppelte Wortgruppen wie „Ticket bestellen“ und „Ticket bestellen“. Das erweiterte NLU-Modell ist jedoch groß- und kleinschreibungsempfindlich und erfordert mehr Trainingsphrasen, um die Anzahl der Intent-Übereinstimmungen zu erhöhen. Weitere Informationen finden Sie im Abschnitt Groß- und Kleinschreibung.
• Füllwörter: z. B. „okay, ein Ticket bestellen“ und „ein Ticket bestellen“.
• Interpunktion: z. B. „Können Sie mir bitte helfen?“ und „Können Sie mir bitte helfen!?“

Einheitlichkeit der Anmerkungen

Der für eine Anmerkung ausgewählte Teil der Trainingsformulierung sollte genau den Text enthalten, der zur Übereinstimmung mit einer Entität erforderlich ist, also weder mehr noch weniger Wörter. Achten Sie außerdem darauf, dass ähnliche Teile von Trainingsformulierungen für den gesamten Intent mit Anmerkungen versehen sind.

In der folgenden Tabelle sind beispielsweise gute und schlechte Anmerkungen mit der Systementität @sys.date aufgeführt:

Gut	Fehlerhaft
Abfahrt am 7. September	Abfahrt am 7. September
Am 4. Juli wird	Am 4. Juli

Verwenden Sie semantisch sinnvolle Anmerkungen für Systementitäten.

Die semantische Bedeutung eines für eine Anmerkung ausgewählten Teils einer Trainingsphrase kann vom Rest des Texts in der Trainingsphrase beeinflusst werden. Beispiel:

Trainingsphrase mit Anmerkungen	Semantische Bedeutung des kommentierten Texts
Ich bin 7 Jahre alt.	Das Alter einer Person
Der Vertrag ist 7 Jahre gültig.	Eine Zeitdauer

Die Modelle für maschinelles Lernen von Conversational Agents (Dialogflow CX) berücksichtigen die semantische Bedeutung beim Abgleich von Systementitäten. Die semantische Bedeutung des Teils der Trainingsformulierung muss mit der beabsichtigten semantischen Bedeutung der Systementität übereinstimmen.

Verwenden Sie beispielsweise die Systementität @sys.duration nicht für die Anmerkung des ersten Beispiels „7 Jahre“ oben. Die semantische Bedeutung von „7 Jahre“ entspricht nicht einer einfachen Zeitspanne. Wählen Sie stattdessen „7“ für die Anmerkung aus und verwenden Sie die Systementität @sys.number.

Intents zum Umgang mit nicht konformen Antworten beim Ausfüllen von Formularen definieren

Sie können Intents definieren, um nicht konforme Antworten beim Ausfüllen von Formularen zu verarbeiten. Angenommen, Ihr Kundenservicemitarbeiter fragt: „Wann reisen Sie?“ und der Endnutzer antwortet: „Ich weiß es noch nicht.“ Diese Antwort erfüllt nicht den Prompt für den Formularparameter. Wenn Ihr Kundenservicemitarbeiter jedoch einen Intent-Pfad hat, der mit dieser Antwort übereinstimmt, kann er die Situation gut bewältigen.

Vermeiden Sie @sys.any

Verwenden Sie den Systementitätstyp @sys.any nicht. Sie sollten sie nur verwenden, wenn Sie alle anderen Möglichkeiten ausgeschöpft haben, einschließlich der Erstellung benutzerdefinierter Entitäten. Dieser Entitätstyp ist sehr weit gefasst und kann zu unerwünschtem Verhalten führen.

Wenn Sie diesen Entitätstyp verwenden, sollten Sie mehrere Teile einer einzelnen Trainingsphrase nicht mit diesem Entitätstyp annotieren. Andernfalls entsteht eine Unklarheit und das Verhalten des Kundenservicemitarbeiters ist nicht definiert.

Die Verwendung von @sys.any mit Formularparametern ist weniger gefährlich, da der Kundenservicemitarbeiter beim Anfordern von Formularparametern bestimmte Informationen erwartet.

Hinweis: Einige Systementitäten sind nicht verfügbar, wenn Sie die Bereitstellung Ihrer Kundenservicemitarbeiter regionalisieren. Manchmal wird @sys.any als Problemumgehung empfohlen.

Anmerkungen sollten eine Vielzahl von Entitätswerten enthalten

Wenn Sie annotierte Trainingsformulierungen definieren, sollten Sie in den Formulierungen eine Vielzahl von Beispielen für Entitätswerte verwenden. Verwenden Sie für die Anmerkungen nicht immer dasselbe Entitätsbeispiel. Das folgende Beispiel zeigt gute und schlechte Anmerkungen für einen Produktentitätstyp:

Gut	Fehlerhaft
Ich möchte ein Hemd kaufen.	Ich möchte ein Hemd kaufen.
Einen neuen Hut bestellen	Neues Hemd bestellen
Smartwatch in den Einkaufswagen legen	Lege ein Hemd in meinen Einkaufswagen

Benutzerdefinierte Entitäten sollten vielfältig sein

Benutzerdefinierte Entitäten sollten eine Vielzahl von Beispielen abdecken. Das NLU-Modell bietet eine Vielfalt an grammatischen Formen, aber Sie müssen alle möglichen Elemente einschließen.

Vermeiden Sie Entitäten mit aggressiver Übereinstimmung

Definieren Sie keine Entitäten, die praktisch allgemeingültig sind. Das beeinträchtigt die Leistung und Qualität von ML. Fast alles in jeder Trainingsformulierung wird sonst als mögliche Übereinstimmung gewertet.

Zuordnungs- und Listenentitäten sollten sich auf eindeutige Werte konzentrieren

Entitätstypen für Zuordnungen und Listen sollten einen begrenzten Umfang haben, der unterschiedliche Werte eines Informationstyps erfasst. Halten Sie Ihre Entitäten prägnant, kurz und einfach.

Wenn Ihre Entitätswerte kompliziert sind, kann es daran liegen, dass Trainingsformulierungen für Intents besser auf Ihre Situation zugeschnitten sind. Beispiele für Endnutzereingaben:

• „Wie kann ich mit Tarif A einen Auslandsanruf führen?“
• „Daten-Roaming im Ausland mit Tarif B verwenden“

Erstellen Sie nicht Entitätstypen sowohl für die Aktionen als auch für die Tarife, z. B.:

Entitätstyp „Aktionen“	Entitätstyp „Pläne“
„Wie kann ich einen Auslandsanruf starten?“	„Plan A“
„Daten-Roaming im Ausland verwenden“	„Plan B“

Verwenden Sie stattdessen Trainingsformulierungen und Intent-Zuordnung, um die Aktionen zu erfassen, und Entitäten, um die Tarife zu erfassen.

RegExp-Entitäten verwenden, um nicht aus Wörtern bestehende IDs zu erfassen

Wenn Sie Endnutzereingaben erfassen, die keine Wortidentitäten enthalten, sollten Sie RegExp-Entitäten verwenden. Wenn Sie beispielsweise Produkt-IDs wie „AA-256“ oder „AC-436“ erfassen möchten, verwenden Sie eine reguläre Ausdrucks-Entität wie „[A-Z]{2}-\d{3}“.

Zusammengesetzte Entitäten nicht verschachteln

Verwenden Sie in zusammengesetzten Entitäten nicht mehr als eine Verschachtelungsebene. Jede Verschachtelungsebene beeinträchtigt die Qualität erheblich.

Ähnliche Intents vermeiden

Jeder Intent sollte die Absicht des Endnutzers erfassen. Wenn Sie verschiedene Intents mit ähnlichen Trainingsformulierungen definieren, ist die Zuordnung möglicherweise nicht zuverlässig, da das NLU-Modell nicht mit ausreichender Sicherheit bestimmen kann, welcher Intent übereinstimmt.

Wenn zwei Wortgruppen dieselbe Absicht haben, sollten sie zum selben Intent gehören. Beispielsweise sollten „Ausstellungsdatum der aktuellen Rechnung ändern“ und „Mehr Zeit zum Bezahlen“ zur selben Absicht gehören, da in beiden Fällen eine Änderung des Fälligkeitsdatums angefordert wird. Die Fragen „Kann ich mit Tarif A ein Auslandsgespräch führen?“ und „Kann ich mit Tarif A Daten-Roaming im Ausland verwenden?“ können jedoch zu unterschiedlichen Absichten gehören, da der Endnutzer in jedem Fall etwas anderes möchte.

Ähnliche Entitätstypen vermeiden

Sie sollten vermeiden, mehrere Entitätstypen mit ähnlichen Entitätseinträgen zu definieren, da dies zu Unklarheiten beim NLU-Modell führen kann.

Ereignisse ohne Übereinstimmung in der Produktion verwenden, um Ihre Intents zu verbessern

Wenn Sie Ihren Agenten in der Produktion ausführen, ist es unvermeidlich, dass einige Endnutzereingaben zu Ereignissen ohne Übereinstimmung führen. Sie haben drei Möglichkeiten, diese Gelegenheiten zu nutzen, um Ihren Kundenservice zu verbessern:

• Fügen Sie die Endnutzereingabe dem gewünschten Intent als Trainingsformulierung hinzu. Dies ist jedoch nicht immer die beste Option. Wenn Sie dies für den Intent häufig tun, kann dies zu einer Intent-Voreingenommenheit führen.
• Optimieren Sie die Trainingsformulierungen für den gewünschten Intent, damit sie alle die Absicht genau widerspiegeln. In einigen Fällen können Intents mit unterschiedlichen Trainingsformulierungen die Zuordnung des Intents verhindern.
• Wenn Intents, die nicht mit der Endnutzereingabe abgeglichen werden sollen, Trainingsformulierungen enthalten, die mit der Endnutzereingabe übereinstimmen könnten, löschen Sie diese Trainingsformulierungen.

Vermeiden Sie Sonderzeichen.

Sonderzeichen wie {, _, # und [ werden in Trainingsformulierungen ignoriert. Eine Ausnahme bilden Emoticons, die wie erwartet funktionieren.

Vermeiden Sie Füllwörter.

Füllwörter sind Wörter, die Sie ignorieren können und trotzdem den Text verstehen. Beispiel:

• gefallen
• Können Sie bitte
• Hmmm
• Wie wäre es mit

Es ist unnötig, aber harmlos, Füllwörter in Trainingsphrasen zu verwenden, da diese vom NLU-Modell ignoriert werden. Sie sollten jedoch keine Trainingsformulierungen definieren, die sich nur durch Füllwörter unterscheiden.

Definieren Sie keine Entitäten, die aus Füllwörtern bestehen.

Mit ML-Einstellungen experimentieren

Mit den ML-Einstellungen können Sie anpassen, wie die Eingaben von Endnutzern verarbeitet werden. In den meisten Fällen funktionieren die Standardeinstellungen gut. Sie können die Einstellungen jedoch optimieren, um die Leistung Ihrer Kundenservicemitarbeiter zu verbessern.

Auf den Endnutzer reagieren

Dieser Abschnitt enthält Richtlinien für die Verwendung der Auftragsausführung, um auf den Endnutzer zu reagieren.

Endnutzer begrüßen

Ein neu erstellter Agent hat eine automatisch erstellte Intent-Route für den Begrüßungs-Intent. Sie sollten diese Route bearbeiten, um eine Bestätigungsnachricht mit einer Begrüßung für den Endnutzer einzufügen. Diese Nachricht sollte den Bot beschreiben und dem Endnutzer einen Eindruck davon vermitteln, was er kann.

Informationen zu Endnutzern bestätigen

Es ist oft am besten, in den Antworten Informationen zu wiederholen, die der Endnutzer angegeben hat. So weiß der Endnutzer, dass der Kundenservicemitarbeiter seine Anfrage verstanden hat.

Wenn ein Intent zugeordnet wird und eine Weiterleitung erfolgt, informieren Sie den Endnutzer darüber, dass die Unterhaltung auf Grundlage seiner Anfrage fortgesetzt wird. Beispiel:

Dialog	Beschreibung
Endnutzer: Ich habe Fragen zu meinem Girokonto. Kundenservicemitarbeiter: Okay, was möchten Sie über Ihr Girokonto wissen?	Die Eingabe des Endnutzers führte zu einer Intent-Übereinstimmung und es wurde eine Route mit einer Ausführungsmeldung und einem Übergang zu einer Seite mit Fragen zur Kontoprüfung ausgeführt. Beachten Sie, dass der Kundenservicemitarbeiter bestätigt, dass der Endnutzer Informationen zu seinem Girokonto benötigt.

Wiederholen Sie die vom Endnutzer bereitgestellten Daten, sobald das Ausfüllen des Formulars abgeschlossen ist. Beispiel:

Dialog	Beschreibung
Endnutzer: Morgen Kundenservicemitarbeiter: Okay, Ihr Termin für den Haarschnitt ist morgen um 19:00 Uhr. Kann ich sonst noch etwas für Sie tun?	Der Endnutzer hat den Formularparameter „Datum“ angegeben, der der letzte Formularparameter auf der aktiven Seite war. Der Kundenservicemitarbeiter hat die Uhrzeit und das Datum eines geplanten Haarschnitts bestätigt.

Gespräch leiten

Der Kundenservicemitarbeiter sollte die Unterhaltung mit dem Endnutzer immer leiten. Das geht ganz einfach, indem Sie jede Antwort mit einer Frage wie der folgenden beenden:

• Kann ich sonst noch etwas für Sie tun?
• Was möchten Sie über Beagles wissen?
• Möchten Sie diese Bestellung stornieren oder senden?
• Wie kann ich Ihnen helfen?
• Reisen Sie allein oder mit jemandem?

Achten Sie beim Definieren dieser Fragen darauf, nicht mehrere Fragen zu stellen, z. B.:

• Sind Sie noch da? Um welchen Dienst geht es?
• Möchten Sie diese Bestellung trotzdem aufgeben? Möchten Sie noch etwas hinzufügen?

Der Endnutzer antwortet möglicherweise nur auf eine der Fragen und Ihr Kundenservicemitarbeiter geht nicht richtig mit dieser Situation um.

Umgang mit Fehlern und unerwarteten Endnutzereingaben

In diesem Abschnitt finden Sie Tipps zum Umgang mit Fehlern und unerwarteten Endnutzereingaben.

Event-Handler für integrierte Ereignisse erstellen

Sie sollten gegebenenfalls Event-Handler für die eingebundenen Ereignisse erstellen. Die Verarbeitung dieser Ereignisse ähnelt dem Abfangen von Ausnahmen bei der Softwareprogrammierung. Je nach Situation können Sie die Ereignisse mit parameterspezifischen, seitenspezifischen oder flussspezifischen Event-Handlern verarbeiten.

Webhook-Fehler behandeln

Wenn der Webhook-Dienst ausfällt, ist es wichtig, dass dein Kundenservicemitarbeiter den Fehler ordnungsgemäß beheben kann. Dazu definieren Sie Event-Handler für die webhookspezifischen vordefinierten Ereignisse. So gehen Sie am besten vor, wenn Webhook-Fehler auftreten:

• Gib über den Status-Handler kein Umstellungsziel an, das den Webhook-Aufruf auslöst. Andernfalls wird der Webhook-Fehler-Ereignis-Handler nicht aufgerufen. Legen Sie stattdessen das Übergangsziel in der Webhook-Antwort vom Webhook-Dienst fest.

• Wählen Sie eine Seite aus, auf der ein Fehlerzähler auf null initialisiert werden kann. Diese Seite sollte vor der Seite aktiv sein, die einen Webhook-Aufruf auslöst. Die Eingabeausführung für diese Seite sollte den Fehlerzähler mit einer Voreinstellung für den Auftragsausführungsparameter auf 0 initialisieren. Beispiel:

  Parameter	Wert
  webhook-error-count	0

• Erstellen Sie eine Webhook-Fehlerseite, die Webhook-Fehlerereignisse verarbeitet:

  • Die Auftragsausführung für die Eingabe sollte den Fehler für den Endnutzer bestätigen und einen Sitzungsparameter für den Fehlerzähler mit einer Voreinstellung für den Auftragsausführungsparameter inkrementieren. Beispiel:

    Parameter	Wert
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • Definieren Sie eine Bedingungsroute mit der Bedingung, dass die Fehleranzahl unter dem zulässigen Maximum liegt. (z. B. $session.params.webhook-error-count <= 3). Diese Route sollte eine Ausführung haben, die den Endnutzer darüber informiert, dass der Kundenservicemitarbeiter es noch einmal versuchen wird. Das Übergangsziel dieser Route sollte auf PREVIOUS_PAGE oder auf eine beliebige Seite festgelegt sein, auf der ein weiterer Aufruf des Webhooks versucht werden kann.

  • Definiere eine Bedingungsroute mit der Bedingung, dass die Fehleranzahl über dem zulässigen Höchstwert liegt (z. B. $session.params.webhook-error-count > 3). Diese Route sollte eine Ausführung haben, die den Endnutzer darüber informiert, dass der Kundenservicemitarbeiter keinen weiteren Versuch unternimmt. Für diese Route sollte ein Übergangsziel auf eine Seite festgelegt sein, die keine Webhook-Wiederholungen auslöst.

• Der Webhook-Ereignis-Handler sollte ein Umstellungsziel haben, das zur Webhook-Fehlerseite führt.

Tools

In diesem Abschnitt finden Sie Tipps zur Verwendung von Tools zur Verbesserung des Designs von Kundenservicemitarbeitern.

Validierungstool verwenden

Sie sollten Ihren Kundenservicemitarbeiter immer mit dem Bestätigungstool prüfen. Mit diesem Tool können einige der in diesem Leitfaden beschriebenen Probleme gefunden werden.

Funktion „Testfälle“ verwenden

Sie sollten immer Testfälle für Ihren Bot definieren. Diese Testfälle können helfen, Regressionen zu verhindern, während Ihr Bot weiterentwickelt wird, um mehr Szenarien zu bewältigen.