Chat-Timeouts für Chat-Teilnehmer einrichten

Wenn eine Chat-Konversation zwischen Kundendienstmitarbeitern und Kunden für einen bestimmten Zeitraum inaktiv war (es wurden keine Nachrichten gesendet), sollten Sie Chat-Teilnehmer möglicherweise als inaktiv betrachten und Kundendienstmitarbeiter sogar automatisch vom Chat trennen.

Zu diesem Zweck können Sie mit der Aktion sowohl Leerlauf-Timeouts als auch Timeouts für das automatische Schließen konfigurieren. UpdateParticipantRoleConfig

Tipp

Sie konfigurieren Chat-Timeouts für den Fall, dass Kunden mit Lex interagieren, im Block Flow-Block: „Kundeneingabe abrufen“. Siehe Abschnitt Konfigurierbare Timeouts für Chat-Eingaben während einer Lex-Interaktion.

Sie können vier verschiedene Arten von Timern einstellen.

• Sie geben an, wie viel Zeit vergehen muss, bevor eine Aktion ausgeführt wird.

• Jede Kombination von Timern kann verwendet werden.

  Timer	Aktion am Ende des Timers
  Timeout bei Inaktivität des Kunden	Markiert den Kunden als inaktiv
  Timeout für automatische Trennung der Verbindung zum Kunden	Trennt den Kundendienstmitarbeiter automatisch vom Chat, wenn der Kunde untätig ist.
  Timeout bei Inaktivität des Kundendienstmitarbeiters	Markiert den Kundendienstmitarbeiter als inaktiv.
  Timeout für automatische Trennung der Verbindung zum Kundendienstmitarbeiter	Trennt den Kundendienstmitarbeiter automatisch vom Chat, wenn er nicht aktiv ist.

Geben Sie alle Timer in Minuten an.

• Minimum: 2 Minuten

• Maximum: 480 Minuten (8 Stunden)

Timer gelten für die Rollen der Teilnehmer und für die Dauer des Chats.

• Sie konfigurieren Timer für Teilnehmerrollen wie Kundendienstmitarbeiter und Kunde und nicht für einzelne Teilnehmer.

• Nachdem Sie die Timer festgelegt haben, gelten diese für die Dauer des Chats. Wenn ein Chat übertragen wird, gelten die Timer für die neue Interaktion zwischen Kundendienstmitarbeiter und Kunde.

So funktionieren Chat-Timer

Timer funktionieren wie folgt:

• Timer laufen, wenn sowohl ein Agent als auch ein Kunde mit dem Chat verbunden sind oder wenn ein Kunde und ein benutzerdefinierter Teilnehmer (z. B. ein benutzerdefinierter Bot) verbunden sind.

• Timer werden zum ersten Mal gestartet, wenn ein Agent/ein benutzerdefinierter Teilnehmer dem Chat beitritt, und werden gestoppt, wenn der Agent/der benutzerdefinierte Teilnehmer den Chat verlässt.

• Timer für Inaktivität werden vor Timern für die automatische Trennung der Verbindung ausgeführt, wenn beide für eine Rolle konfiguriert sind. Wenn beispielsweise beide Timer konfiguriert sind, startet der Timer für die automatische Trennung erst, wenn ein Teilnehmer als inaktiv eingestuft wird.

• Wenn nur ein Timertyp für eine Rolle konfiguriert ist, wird dieser Timer sofort gestartet.

• Wenn ein Teilnehmer zu irgendeinem Zeitpunkt eine Nachricht sendet, werden die Timer für diesen Teilnehmer zurückgesetzt. Wenn der Teilnehmer zuvor als untätig markiert wurde, ist er das nun nicht mehr.

• Die Konfiguration, die beim Beitritt des Agents/benutzerdefinierten Teilnehmers festgelegt wurde, gilt so lange, wie der Agent/der benutzerdefinierte Teilnehmer im Chat bleibt. Wenn Sie die Timer-Konfiguration aktualisieren, während ein Agent/ein benutzerdefinierter Teilnehmer und ein Kunde bereits miteinander verbunden sind, wird die neue Konfiguration gespeichert, aber erst angewendet, wenn ein neuer Agent/benutzerdefinierter Teilnehmer eine Verbindung zum Chat herstellt.

• Wenn ein automatisches Disconnect-Ereignis eintritt, werden alle Teilnehmer außer dem Kunden (z. B. der Agent, ein überwachender Supervisor oder benutzerdefinierte Teilnehmer) getrennt. Wenn der Agent die Verbindung unterbrochen hat und ein Set disconnect flow (TrennungsFlow festlegen) Block konfiguriert wurde, wird der Chat an ihn weitergeleitet.

Ablauf des Timers im Leerlauf

Folgendes passiert, wenn ein Leerlauftimer während einer kundenspezifischen Teilnehmerinteraktion abläuft:

1. Ein Ereignis im Leerlauf wird auf alle Websockets/Streaming-Endpunkte übertragen.

2. Wenn ein Timer für die automatische Trennung konfiguriert ist, wird er gestartet.

3. Wenn der Timer für den Leerlauf abläuft, während sich der Chat-Kontakt in einem Warte-Block befindet, wird der Kontakt in den Zweig „Zeit abgelaufen“ NOT weitergeleitet. Wenn dieses Szenario eintritt, werden keine Maßnahmen ergriffen.

Automatisches Trennen der Verbindung von benutzerdefinierten Teilnehmern

Wenn ein Timer für die automatische Trennung abläuft, wird der benutzerdefinierte Teilnehmer vom Chat getrennt.

Amazon Connect führt einen der folgenden Schritte durch, wenn die Timer für die automatische Trennung ablaufen:

1. Der Chat befindet sich derzeit in einem Wait Block, der für einen benutzerdefinierten Teilnehmer konfiguriert ist.

   • Der benutzerdefinierte Teilnehmer wird vom Chat getrennt, und der Chat setzt den Chatfluss fort, indem der Zweig für den abgebrochenen Bot-Teilnehmer übernommen wird.

2. Der Chat befindet sich derzeit in einem Wait Block, der für den Kunden konfiguriert ist, ODER der Chat befindet sich nicht in einem Warte-Block.

   • Der benutzerdefinierte Teilnehmer wird vom Chat getrennt und es werden keine weiteren Aktionen ausgeführt.

Den Teilnehmern angezeigte Nachrichten

Es werden allen Teilnehmern Nachrichten angezeigt, wenn eines der folgenden Ereignisse eintritt:

• Ein Teilnehmer wird inaktiv.

• Ein inaktiver Teilnehmer sendet eine Nachricht und ist daher nicht mehr inaktiv.

• Es erfolgt eine automatische Trennung. Da der Kundendienstmitarbeiter nicht verbunden ist, kann er die Nachricht nicht sehen.

Diese Ereignisse werden weder in den Protokollen gespeichert noch in Rechnung gestellt.

Die Standardnachrichten (in allen unterstützten Sprachen) werden den Agenten im Contact Control Panel (CCP) für jedes dieser Ereignisse angezeigt.

Die folgende Abbildung zeigt Beispiele für Standardmeldungen, die der Agent im sehen würde, wenn er nicht aktiv ist. CCP Beispiel: Kundendienstmitarbeiter ist inaktiv.

Empfohlene Verwendung

Um die Timeout-Funktion für Chats zu verwenden, empfehlen wir außerdem Folgendes:

1. Betten Sie einen Call to the UpdateParticipantRoleConfigAction in einem Lambda in einen Kontaktablauf ein.

2. Platzieren Sie das Lambda je nach Anwendungsfall entweder unmittelbar nach dem Start des Chats (am Anfang des Flows) oder kurz bevor Sie den Kontakt in eine Warteschlange weiterleiten.

Individuelle Anpassung der Chat-Benutzeroberfläche des Kunden bei Verbindungstrennung

Sie können die Chat-Benutzeroberfläche Ihres Kunden bei einer Verbindungstrennung anpassen. Sehen Sie sich dazu die folgenden Methoden in ChatJS an:

• onParticipantIdle(callback)

• onParticipantReturned(callback)

• onAutoDisconnection(callback)

Verwenden Sie diese Methoden zum Registrieren von Callback-Handlern, die beim Eintreffen neuer Ereignisse ausgelöst werden.