Benutzerdefiniertes CRM

Mit der benutzerdefinierten CRM-Lösung können Unternehmen das CCAI Platform-Portal (Contact Center AI Platform) nutzen, wenn sie ein CRM verwenden, das derzeit keine Standardintegration mit der CCAI Platform bietet. Die benutzerdefinierte CRM-Konfiguration funktioniert, wenn Sie ein selbst entwickeltes oder ein nicht standardmäßiges CRM verwenden.

Kundenservicemitarbeiter bearbeiten Anrufe und Chats. Supervisoren können Berichte über das CCAI Platform-Portal aufrufen und erstellen. Alle Details zum Anruf oder zur Chatsitzung werden in einer Sitzungsmetadatendatei gespeichert. Diese Datei kann mehr als 20 Datenpunkte enthalten, darunter Sitzungsinformationen, Transfers, Dauer der Bearbeitung, Teilnehmer, Diagnoseinformationen und vieles mehr. Die Metadatendatei der Sitzung kann geparst und für die Analyse und das Tracking nach der Sitzung verwendet werden.

Sitzungsmetadaten und vom Nutzer hochgeladene Mediendateien werden an einen externen Speicherdienst gesendet. KI-Agenten können vom Nutzer hochgeladene Mediendateien während der Sitzung direkt im KI-Agenten-Adapter ansehen.

Eine benutzerdefinierte CRM-Lösung wird mit einer Kombination der folgenden Komponenten implementiert. Einige Komponenten sind möglicherweise für Ihre Konfiguration relevant:

  • Generieren der Sitzungsmetadatendatei für jede Anruf- und Chatsitzung

  • Metadaten und Mediendateien an einen externen Speicherdienst senden

  • Allgemeine API-Integration

  • Benutzerdefinierte Lookup-URL

  • CRM-Datensatz per E‑Mail aktualisieren

  • Konto- oder Fallsuche über den Kundenservice-Adapter

Vorbereitung

Wenn Sie die Funktion „Benutzerdefiniertes CRM“ verwenden möchten, müssen Sie zuerst externen Speicher einrichten. Weitere Informationen finden Sie unter Externer Speicher für benutzerdefinierte CRM-Lösungen.

Sitzungsmetadaten

Die Metadatendatei der Sitzung enthält detaillierte Informationen zur Sitzung. Diese E-Mail wird 15 Minuten nach Ende der Sitzung gesendet. Weitere Informationen finden Sie unter Metadatendatei für Sitzungen.

Benutzerdefinierte Methoden für CRM-Interaktion und ‑Integration

Allgemeine API Benutzerdefinierte URL
Kontosuche Ja Ja
Anfragesuche Ja
Update zu Ihrer Anfrage Ja Nein

Generische API

Mit der generischen API-Integrationsmethode können Sie die API Ihres benutzerdefinierten CRM verwenden, um eine bidirektionale Verbindung mit der CCAI-Plattform herzustellen. Diese nahtlose Methode ist mit der standardmäßigen CRM-Integration vergleichbar. Der Kundenservicemitarbeiter muss keine Aktion ausführen, um einen CRM-Eintrag für Anruf- oder Chatsitzungen zu erstellen. Das hängt von der individuellen API-Konfiguration ab. Sie ermöglicht eine nahtlose Suche und Aktualisierung von Datensätzen.

Benutzerdefinierte URL

Mit der Option „Benutzerdefinierter Link“ können Ihre Kundenservicemitarbeiter mit Ihrem CRM interagieren, indem sie einen benutzerdefinierten Link verwenden, der für jede Sitzung erstellt wird. Im Gegensatz zur Standard-CRM-Integration und zur generischen API muss der Kundenservicemitarbeiter Maßnahmen ergreifen, damit ein CRM-Datensatz erstellt wird. In einigen Fällen wird nur ein Tab mit dem benutzerdefinierten Link aus der Sitzung geöffnet. In anderen Fällen muss der Kundenservicemitarbeiter den Datensatz manuell erstellen.

Details und Konfiguration benutzerdefinierter Lookup-URLs

Die grundlegende Funktion der URL besteht darin, eine CRM-Suche durchzuführen. Je nach CRM können jedoch komplexere Prozesse ausgelöst werden, die auf dem Inhalt der benutzerdefinierten URL basieren. Die URL für das benutzerdefinierte CRM kann mit Variablen konfiguriert werden, die Sitzungsinformationen enthalten. Sie ist während der Sitzung im Agent-Adapter verfügbar. Sobald auf die URL zugegriffen wird, wird im benutzerdefinierten CRM eine Suche ausgelöst. So können Kundenservicemitarbeiter während des aktiven Anrufs oder der aktiven Chatsitzung auf ein „Ticket-Pop-up“ zugreifen. Der Prozess für benutzerdefinierte Links hängt ausschließlich davon ab, ob das benutzerdefinierte CRM diesen Link verarbeiten und ihn bei Bedarf ändern oder neu schreiben kann.

Die extern gespeicherten Sitzungsmetadaten, Anrufaufzeichnungen und anderen Dateien werden nicht mit dem CRM-Datensatz verknüpft, sofern nicht auch die aufgeführte E-Mail-Aktualisierungsmethode verwendet wird.

Bei dieser Konfiguration meldet sich der Kundenservicemitarbeiter im CCAI Platform-Portal und in seinem CRM auf separaten Tabs an. Anrufe und Chats werden auf dem Tab „CCAI Platform“ bearbeitet und auf einem CRM-Tab können Sie auf Ticketdetails zugreifen.

Damit diese Konfiguration funktioniert, müssen folgende Voraussetzungen erfüllt sein:

  • Der Kundenservicemitarbeiter muss in seinem Browser in seinem CRM angemeldet sein.

  • Der Agent muss in seinem Browser im CCAI Platform-Portal angemeldet sein.

  • Die benutzerdefinierte Such-URL muss vorkonfiguriert sein.

  • Ihr CRM muss die benutzerdefinierte URL verarbeiten, um den relevanten CRM-Datensatz anzuzeigen.

Benutzerdefiniertes Verhalten bei der Suche nach URLs

  • Die CCAI-Plattform fügt nur Parameter in die URL ein, die nicht leer sind.

  • Die generierte URL mit ANI/UID/E-Mail-Adresse wird nach Beendigung der Sitzung nicht in der CCAI Platform-Datenbank gespeichert.

Benutzerdefinierte Lookup-URL konfigurieren

Aufgrund unterschiedlicher eindeutiger Kennungen sowie CRM-Funktionen und ‑Verhaltensweisen müssen Sie zwei verschiedene URLs erstellen: eine für IVR-/PSTN-/SMS-Sitzungen und eine für Web- und Mobile-SDK-Sitzungen. Bei IVR-/PSTN-/SMS-Sitzungen wird die ANI als eindeutige Kennung verwendet, während bei Web- und Mobile-SDKs wahrscheinlich CUID und E-Mail-Adresse verwendet werden.

Mit den folgenden Variablen können Sie eine Lookup-URL konfigurieren:

Variable Werte
{CUSTOMER_PHONE_NUMBER} Die Telefonnummer des Endnutzers
{ANI} Die Telefonnummer des Endnutzers. Für die Abwärtskompatibilität beibehalten.
{CUID} Benutzerdefinierte Nutzer-ID
{EMAIL} E‑Mail-Adresse des Endnutzers
{MENU_PATH} Der vollständige Menüpfad der Warteschlange.
Beispiel: „Bestellungen/Bestellbestätigung/Bestellinformationen“.
{MENU_ID} Menü-ID
{CHANNEL}

Der Sitzungschannel. Mögliche Werte:

  • Chat
  • voice_call
{TYPE}

Der Sitzungstyp.

Mögliche Werte für Anrufe:

  • Incoming_Call_(app)
  • Scheduled_Call_(app)
  • Incoming_Call_(web)
  • Scheduled_Call_(web)
  • Outbound_Call
  • Outbound_Call_(api)
  • Incoming_Call_(api)
  • IVR_Call
  • IVR_Call_(app)
  • Mailbox

Mögliche Werte für Chats:

  • Mobil
  • Web
  • SMS
{SUPPORT_PHONE_NUMBER} Die Telefonnummer des Supportcenters, die der Endnutzer anruft.
{OUTBOUND_NUMBER} Die Telefonnummer, die ein Kundenservicemitarbeiter für einen ausgehenden Anruf verwendet.
{SESSION_ID}

Die Sitzungs-ID. Mögliche Werte:

  • Anrufer-ID
  • Chat-ID
  • E-Mail-ID
{CUSTOM_AGENT_ID} Das optionale Feld „Agent-ID“ im user-Objekt. Die Agent-ID kann erst abgerufen werden, nachdem die Sitzung eingerichtet und ein Agent zugewiesen wurde. Konfigurieren Sie Ihre Instanz daher so, dass die Erstellung von Anruf- oder Chataufzeichnungen verzögert wird, damit genügend Zeit bleibt, diese Variable zu definieren. Sie können die Erstellung von Anruf- oder Chatdatensätzen unter Einstellungen> „Vorgangsverwaltung“ > „Details zur Erstellung von CRM-Datensätzen“ verzögern. Weitere Informationen finden Sie unter Details zur Erstellung von CRM-Datensätzen.

CCAI Platform-Portal konfigurieren

  1. Melden Sie sich mit einem Konto mit der Administratorrolle im CCAI Platform-Portal an.

  2. Gehen Sie zu Einstellungen > Entwicklereinstellungen.

  3. Wählen Sie im Bereich „CRM“ die Option Benutzerdefiniertes CRM aus.

  4. Geben Sie unter CRM-Suche Ihre benutzerdefinierten URLs ein.

  5. Wählen Sie das Telefonnummernformat aus, das in CRM-Anfragen verwendet werden soll.

  6. Klicken Sie auf Änderungen speichern.

  7. Konfigurieren Sie Ihren externen Speicherdienst, falls noch nicht geschehen. Weitere Informationen finden Sie unter „Externer Speicher“.

CRM-Datensatz per E‑Mail aktualisieren

Bei Konfigurationen wie der benutzerdefinierten Lookup-URL müssen die Sitzungsmetadaten im CRM aktualisiert werden, sobald eine Sitzung abgeschlossen ist. Mit dieser Funktion kann die CCAI Platform Sitzungsdaten automatisch per E-Mail senden. Etwa 15 Minuten nach dem Ende einer Sitzung wird eine E-Mail an einen konfigurierten Ort gesendet. Der Inhalt der E-Mail wird verwendet, um einen Datensatz in Ihrem CRM zu aktualisieren. Diese Funktion kann global und pro Warteschlange konfiguriert werden. Sobald die E-Mail eingegangen ist, kann Ihr CRM so konfiguriert sein, dass ein neuer CRM-Datensatz für die Sitzung erstellt oder ein vorhandener aktualisiert wird.

Details zur E‑Mail-Adresse

  • Gesendet von no-reply@ccaiplatform.com

  • Enthält:

    • Subject line

    • Text mit den Sitzungsmetadaten in JSON-Syntax

    • Anhang im TXT-Format mit Chatprotokoll, sofern zutreffend

  • Die CCAI-Plattform wartet nach dem Ende der Sitzung 15 Minuten, bevor die E‑Mail gesendet wird.

  • E‑Mails werden nur für erfolgreich abgeschlossene Sitzungen gesendet. Sie wird nicht für fehlgeschlagene oder abgebrochene Sitzungen gesendet.

Globale Konfiguration

  1. Melden Sie sich mit einem Konto mit der Administratorrolle im CCAI Platform-Portal an.

  2. Gehen Sie zu Einstellungen > Entwicklereinstellungen.

  3. Achten Sie darauf, dass im CRM-Bereich Benutzerdefiniertes CRM ausgewählt ist.

  4. Aktivieren Sie Sitzungsergebnis per E-Mail senden.

  5. Geben Sie eine E‑Mail-Adresse ein, an die die E‑Mail gesendet werden soll.

  6. Klicken Sie auf Änderungen speichern.

Konfiguration pro Warteschlange

  1. Melden Sie sich mit einem Konto mit der Administratorrolle im CCAI Platform-Portal an.

  2. Gehen Sie zu Einstellungen > Warteschlange und wählen Sie eine beliebige untergeordnete Warteschlange aus.

  3. Aktivieren Sie Sitzungsergebnis per E-Mail senden.

  4. Geben Sie eine E‑Mail-Adresse ein, an die die E‑Mail gesendet werden soll.

    E-Mail-Konfiguration anzeigen

  5. Klicken Sie auf Benutzerdefinierte CRM-Einstellung speichern.

Einstellungen übernehmen und überschreiben

Einstellungen Verhalten
Global = NICHT aktiviert
Warteschlange = NICHT aktiviert
Nicht für alle Warteschlangen senden.
Global = NICHT aktiviert
Warteschlange = Aktiviert
Die Warteschlangeneinstellung (d.h. der Ein-/Aus-Status) überschreibt die globale Einstellung.
E-Mails werden aus einer bestimmten Warteschlange an eine E-Mail-Adresse gesendet, die in der Warteschlangeneinstellung definiert ist.
Global = Aktiviert
Warteschlange = NICHT aktiviert
Die Warteschlangeneinstellung (E-Mail-Adresse, Ein-/Aus-Status) wird von der globalen Einstellung übernommen.
E-Mails werden aus einer bestimmten Warteschlange an eine E-Mail-Adresse gesendet, die in der globalen Einstellung definiert ist.
Global = Aktiviert
Warteschlange = Aktiviert
Die Warteschlangeneinstellung (E-Mail-Adresse) hat Vorrang vor der globalen Einstellung.
E-Mails werden aus einer bestimmten Warteschlange an eine in der Warteschlangeneinstellung definierte E-Mail-Adresse gesendet.
Wenn die E-Mail-Adresse leer ist, werden keine E-Mails gesendet.

Interaktion zwischen Agent und Nutzern

CRM-Datensatzsuche

  1. Melden Sie sich im CCAI Platform-Portal mit einem Konto an, dem die Rolle „Agent“ zugewiesen ist.

  2. Öffnen Sie den Anruf- oder Chatadapter.

  3. Verwenden Sie die Schaltfläche In neuem Browserfenster öffnen, um die Suche auszulösen.

  4. Klicken Sie auf die Schaltfläche Link kopieren, um die Lookup-URL in die Zwischenablage zu kopieren.

Agent-Anzeige

Externer Speicher für benutzerdefinierte CRM-Lösungen

Mit „Externer Speicher für benutzerdefinierte Lösungen“ können Sie einen externen Speicherdienst verwenden, um Metadaten von CCAI Platform-Sitzungen, Anrufaufzeichnungen, Chat-Transkripte und von Verbrauchern hochgeladene Mediendateien zu speichern und abzurufen. Die Dateien werden außerhalb eines CRM gespeichert.

Um externen Speicher zu konfigurieren, müssen Sie Folgendes haben:

  • Ein gültiges CCAI Platform-Konto mit der Rolle „Administrator“ und „Agent“ für die Konfiguration und das Testen

  • Ein externer Speicherdienst

Ordnerstruktur

Die folgende Ordnerstruktur wird in Ihrem externen Speicher unter Ordnerpfad organisiert:

  • ujet-chat-transcripts

  • ujet-media

  • ujet-metadata

  • ujet-voice-recordings

  • ujet-voicemails

Dateiformate und Namenskonventionen

Die folgenden Dateitypen können an den externen Speicherdienst gesendet werden. Dateien werden während der Übertragung mit HTTPS verschlüsselt:

Datei Name
Anrufaufzeichnungen – call-{id}.mp3
– call-{id}.wav
Mediendateien – call-{id}-photo-{photo-id}.jpg
– call-{id}-video-{video-id}.mp4
– chat-{id}-photo-{photo-id}.jpg
– chat-{id}-video-{video-id}.mp4
Chattranskripte – chat-{id}.txt
Sitzungsmetadaten – call-{id}.json
– chat-{id}.json

Interaktion zwischen Agent und Supervisor

Während des Anrufs oder der Chatsitzung werden Fotos und Videos, die vom Kunden über Smart Actions hochgeladen wurden, im Agent-Adapter angezeigt.

Wenn Sie die CRM-Interaktion mit benutzerdefinierter URL in Kombination mit der E-Mail-Aktualisierungsmethode für die Sitzungsmetadatendatei verwenden, können Kundenservicemitarbeiter und Vorgesetzte über Ihren externen Server auf Sitzungsinformationen zugreifen.

Externen Speicherdienst konfigurieren

Führen Sie die folgenden Schritte aus, um Ihren externen Speicher zu konfigurieren:

  1. Melden Sie sich mit einem Konto mit der Rolle „Administrator“ im CCAI Platform-Portal an.

  2. Gehen Sie zu Einstellungen > Entwicklereinstellungen.

  3. Rufen Sie auf der Seite „Entwicklereinstellungen“ den Bereich Externer Speicher auf.

  4. Aktivieren Sie die Speicherung von Informationen außerhalb von CRM-Servern, indem Sie den Schalter auf Ein stellen. Wählen Sie dann die Dateitypen aus, die gespeichert werden sollen.

  5. Wählen Sie im Bereich „Server Setup“ (Serverkonfiguration) Ihren Speichertyp aus und führen Sie die Einrichtungsschritte aus: SFTP server (SFTP-Server), Google Cloud bucket (Google Cloud -Bucket).

SFTP-Server

  1. Geben Sie den SFTP-Host (URL oder IP-Adresse) ein.

  2. Geben Sie die Port-Nummer ein.

  3. Geben Sie die Nutzer-ID für die SFTP-Anmeldung ein.

  4. Wenn der SFTP-Server ein Passwort für die Authentifizierung erfordert, geben Sie es im Feld Passwort ein.

  5. Wenn der SFTP-Server einen privaten Schlüssel für die Authentifizierung erfordert, wählen Sie das Kästchen Privater SSH-Schlüssel aus.

  6. Geben Sie den privaten SSH-Schlüssel ein (kopieren und einfügen).

  7. Geben Sie die Passphrase für den privaten Schlüssel ein. Wenn die Sitzungsinformationen in einem bestimmten Ordner auf dem SFTP-Server gespeichert werden sollen, wählen Sie das Kästchen Ordnerpfad aus und geben Sie den SFTP-Ordnerpfad ein.

  8. Klicken Sie auf Änderungen speichern.

Cloud Storage

  1. Geben Sie den Google Cloud Bucket-Namen des Ziels ein.

  2. Geben Sie die Client-ID ein. Google Cloud

  3. Geben Sie den Google Cloud Clientschlüssel ein.

  4. Wenn die Sitzungsinformationen in einem bestimmten Ordner im Google Cloud Bucket gespeichert werden sollen, wählen Sie das Kästchen Ordnerpfad aus und geben Sie den Google Cloud Ordnerpfad ein.

  5. Klicken Sie auf Verknüpfen und speichern.

Konfiguration des externen Speichers testen

Für CRMs mit vorhandener Standardintegration:

  1. Melden Sie sich in Ihrem CRM an.

  2. Melden Sie sich im CRM mit CCAI Platform-Anmeldedaten mit zugewiesener Agent-Rolle in der CCAI Platform an.

  3. Rufen Sie jemanden an oder starten Sie einen Chat. Der CRM-Datensatz, der mit der Sitzung verknüpft ist, wird angezeigt.

  4. Wenn die Sitzung beendet ist, sollte die Transkriptdatei innerhalb von Sekunden hochgeladen werden.

  5. Rufen Sie den Speicherordner des externen Servers direkt auf und prüfen Sie, ob die Datei verfügbar ist.

Sitzungsdateien an das CRM senden

Wenn der externe Speicher aktiviert ist, können Sie mit den Entwicklereinstellungen für CRM-Speicher- und externen Speicher-URLs Sitzungsdateien senden und festlegen, welche Quelle zum Anzeigen von Dateien im Agent-Adapter verwendet werden soll.

Damit Sie diese Einstellungen aufrufen können, muss der externe Speicher unter Einstellungen > Entwicklereinstellungen > Externer Speicher aktiviert sein. Stellen Sie Enable information storage outside CRM servers (Speicherung von Informationen außerhalb von CRM-Servern aktivieren) auf On (Ein).

CRM-Speicher

  1. Gehen Sie zu Einstellungen > Entwicklereinstellungen > Externer Speicher > CRM-Speicher.

  2. Setzen Sie ein Häkchen neben Sitzungsdateien auch an das CRM senden, um Sitzungsdateien wie Anrufaufzeichnungen oder Chatprotokolle an Ihr CRM und den konfigurierten externen Speicher zu senden.

  3. Klicken Sie auf Änderungen speichern.

Wenn das Kästchen aktiviert ist, werden die Aufzeichnungen sowohl im CRM als auch im externen Speicher gespeichert.

URLs für externen Speicher

Die URL für den externen Speicher wird an zwei Stellen verwendet:

  • Der Agent-Adapter.

  • Berichterstellung: Die Media-URL wird im Bericht sowie in den Menüs wie „Einstellungen“, „Anrufe“ und „Abgeschlossen“ angezeigt.

  1. Gehen Sie zu Einstellungen > Entwicklereinstellungen > Externer Speicher > URLs für externen Speicher.

  2. Wählen Sie die Quelle CRM-URLs oder URLs für externen Speicher aus, um Dateien im Agent-Adapter anzuzeigen.

  3. Klicken Sie auf Änderungen speichern.

CRM-Speicher

  • Wenn das Kästchen für die CRM-Speicherung nicht angeklickt ist, werden die Aufzeichnungen nur im externen Speicher gespeichert und ein Link zum CRM wird verwendet.

  • Wenn das Kästchen aktiviert ist, werden die Aufzeichnungen sowohl im CRM als auch im externen Speicher gespeichert.

URLs für externen Speicher

Die URL wird an zwei Stellen verwendet:

  • Auf einem ist das Media im CCAI Platform-Adapter zu sehen. Der externe Speicher oder das CRM-System.

  • Die andere ist im Bericht enthalten. Wir geben die Media-URL in den Berichten sowie in den Menüs wie „Einstellungen“, „Anrufe“ und „Abgeschlossen“ an.

Benutzerdefiniertes CRM im CCAI Platform-Portal anzeigen

Wenn Sie die benutzerdefinierte CRM-Integration mit Ihrem eigenen benutzerdefinierten CRM verwenden, können Sie Ihr CRM auf einer speziellen Seite im CCAI Platform-Portal laden. Nach der Aktivierung wird der Tab „CRM“ im CCAI Platform Portal geladen und Ihre benutzerdefinierte CRM-Seite wird angezeigt. Dies kann in den Entwicklereinstellungen > CRM konfiguriert werden.

Mit dieser Funktion können Kundenservicemitarbeiter Live-Support-Sitzungen über die Anruf- und Chat-Adapter der CCAI-Plattform abwickeln und gleichzeitig in Ihrem benutzerdefinierten CRM arbeiten. Dazu gehört die Überprüfung von automatisch geöffneten Konto- und Datensatzdetails sowie sitzungsspezifischen Dateien und Daten, die von Ihrer mobilen App oder von Verbrauchern über das CCAI-Plattformportal übergeben werden.

Benutzerdefinierte CRM-Seite konfigurieren

So konfigurieren Sie eine benutzerdefinierte CRM-Seite:

  1. Klicken Sie im CCAI Platform-Portal auf Einstellungen > Entwicklereinstellungen. Wenn Sie das Menü Einstellungen nicht sehen, klicken Sie auf  Menü.

  2. Klicken Sie im Bereich CRM auf Benutzerdefiniertes CRM.

  3. Stellen Sie den Schalter CRM im CCAI Platform-Portal anzeigen auf „Ein“.

  4. Geben Sie unter Angezeigte URL die URL für Ihre benutzerdefinierte CRM-Seite ein und klicken Sie auf Speichern.

Benutzerdefiniertes URL-Pop-up öffnen

Mit Benutzerdefinierte URL öffnen können Sie ein Pop-up-Fenster mit einer benutzerdefinierten URL aufrufen, wenn ein Kontakt im System nicht gefunden wird. Erstellen Sie einen CRM-Datensatz mit einer temporären Konto-ID und lösen Sie einen benutzerdefinierten Link mit Parametern basierend auf der Konfiguration auf Warteschlangenebene aus.

Screen Pop für einzelne Warteschlangen aktivieren

  1. Rufen Sie Einstellungen > Warteschlange > IVR auf und klicken Sie auf eine Warteschlange, um sie zu bearbeiten.

  2. Rufen Sie im Bereich die Option Benutzerdefinierte URL öffnen auf.

  3. Geben Sie eine URL ein, um ein Screenpop-Fenster aufzurufen.

Fügen Sie die Variablenparameter {ACCOUNT_ID} und {PHONE_NUMBER} in die URL ein.

Ein Beispiel ist unten aufgeführt.

  1. Klicken Sie auf Speichern.

Benutzerdefinierte generische CRM-API-Integration

Mit der generischen API-Integrationsmethode können Sie die API Ihres CRM verwenden, um eine bidirektionale Verbindung mit der CCAI-Plattform herzustellen. Diese nahtlose Methode ist genauso einfach wie die sofort einsatzbereite CRM-Integration.

Der Kundenservicemitarbeiter muss keine Maßnahmen ergreifen, um einen CRM-Eintrag für Anruf- oder Chatsitzungen zu erstellen. Je nach eindeutiger API-Konfiguration kann dies eine nahtlose Suche und Aktualisierung von Datensätzen ermöglichen.

Terminologie

Begriff

Beschreibung

Konto

Sie wird verwendet, um auf die Einheit „Konto/Kontakt/Kunde/Lead“ im CRM zu verweisen. Möglicherweise hat Ihr CRM einen anderen Namen für diese Einheit.

Konten enthalten Datensätze.

Record

Wird verwendet, um auf die Case-/Ticket-/Unterhaltungs-/Vorgangs-Entität im CRM zu verweisen. Möglicherweise hat Ihr CRM einen anderen Namen für diese Einheit.

Datensätze gehören zu Konten.

Kommentar

Wird verwendet, um im CRM auf die Entität „Kommentar/Hinweis“ zu verweisen. In Ihrem CRM hat diese Einheit möglicherweise einen anderen Namen.

Kommentare gehören zu Datensätzen.

API-Einstellungen

In diesem Abschnitt werden die Einstellungen beschrieben, die für die benutzerdefinierten CRM-API-Einstellungen spezifisch sind.

Authentifizierungsmethode

Die CCAI-Plattform unterstützt drei Authentifizierungsmethoden für Ihr CRM:

  • Basisauthentifizierung: Konfigurieren Sie Anmeldedaten, die Nutzername und Passwort enthalten.

  • Benutzerdefinierter Header: Konfigurieren Sie Schlüssel/Wert-Paare für benutzerdefinierte Header: Feldschlüssel und Feldwert. Geben Sie so viele Paare ein, wie Sie benötigen.

  • OAuth: Die CCAI-Plattform unterstützt das branchenübliche Autorisierungsprotokoll OAuth 2.0. Geben Sie OAuth-Informationen an, wenn Sie die Option Include the Redirect URL as part of the Authorization URL and Token URL (Weiterleitungs-URL als Teil der Autorisierungs-URL und Token-URL einfügen) aktivieren müssen.

    Konfigurieren Sie die folgenden Werte:

    • Autorisierungs-URL (erforderlich)

    • Token-URL (erforderlich)

    • Client-ID (erforderlich)

    • Clientschlüssel (erforderlich)

    • Umfang

    • Bundesland

    • Zugriffstyp

Format der Telefonnummer

Wählen Sie das Telefonnummernformat aus, das in CRM-Anfragen verwendet werden soll:

  • Automatisch: Erstellen: +1 222 333 4444, Suche: *222*333*4444

  • E.164: +12223334444

  • US Local: 2223334444

  • US-Standardtelefonnummer Inland: (111) 222-3333

  • International: +1 222 333 4444

Zeitüberschreitung bei API-Anfrage

Konfigurieren Sie das API-Anfrage-Zeitlimit über das Drop-down-Menü auf einen Wert zwischen 1 und 10 Sekunden. Dieses Zeitlimit wird auf alle von Ihnen konfigurierten Endpunkte angewendet.

CRM-Lookup-URLs

Geben Sie Lookup-URLs an, mit denen ein Agent auf das aktuelle Konto und den aktuellen Datensatz verweist.

Geben Sie die Lookup-URLs so ein, wie sie in Ihrem CRM angezeigt werden, wenn Sie ein Konto oder eine Datensatzseite in Ihrem Browser geöffnet haben.

Sie können CRM-Lookup-URLs auch mit dem Web-SDK und den mobilen SDKs verwenden. Sie können die SDKs so konfigurieren, dass sie CRM-Konten suchen und Informationen aufzeichnen, die im Agent-Adapter angezeigt werden sollen. Eine vollständige Liste der CRM-Lookup-URLs finden Sie unter URL-Parameter für Anfragen.

URL zum Nachschlagen von Konten

Verwenden Sie die Variable {ACCOUNT_ID}, um die tatsächliche Konto-ID einzufügen.

Beispiel:

https://www.example.com/contact/{ACCOUNT_ID}

URL für die Datensatzsuche

Verwenden Sie die Variable {RECORD_ID}, um die tatsächliche Datensatz-ID einzufügen.

Beispiel:

https://www.example.com/record/{RECORD_ID}

API-Endpunkte

Dies ist die wichtigste Konfiguration für die generische API.

  1. Damit die Kontosuche für Ihre Kundenservicemitarbeiter verfügbar ist, müssen Sie die Endpunkte Find an account (Konto suchen) und Create an account (Konto erstellen) konfigurieren.

  2. Außerdem können Sie die Endpunkte Einen Datensatz suchen und Einen Datensatz erstellen einrichten, damit Ihre Kundenservicemitarbeiter Datensätze suchen oder erstellen können. Dazu ist die Kontoeinrichtung aus dem vorherigen Schritt erforderlich.

  3. Wenn Sie die Endpunkte Update a record (Eintrag aktualisieren), Upload a file (Datei hochladen) und Comment (Kommentar) eingeben, werden Aktualisierungen von Einträgen ermöglicht. Dazu ist die Aufnahme der Einrichtung aus dem vorherigen Schritt erforderlich.

Endpunktkonfiguration

Legen Sie folgende Einstellungen fest:

  1. Anfrage-URL: API-Endpunkt-URL.

  2. Wählen Sie die Anfragemethode aus POST, GET, PUT oder PATCH aus.

  3. Geben Sie die Parameter der Anfrage an. Sie können die von der CCAI-Plattform definierten Variablen verwenden, um die erforderlichen Informationen zu übergeben (siehe Tabelle unten). Sie können auch Nur-Text oder Zahlen als Werte für Parameter eingeben. Sie können beliebig viele Parameter hinzufügen.

  4. Wenn der Endpunkt POST/PUT/PATCH ist, bietet die CCAI-Plattform genauere Steuerelemente für die Erstellung der Anfrage. Wählen Sie unter Property oder Container die Option Request Data Format (Datenformat anfordern) aus. Gibt das Format des JSON-Requests an.

    • Property. Dies weist darauf hin, dass das Anfrageobjekt eine einfache Eigenschaftszuordnung ist, wenn die CCAI Platform den Anfragetext aus Parametern erstellt.

    • Dies weist darauf hin, dass die zu sendenden Daten des Anfrageobjekts in einer Struktur verschachtelt werden müssen. Wählen Sie Containertyp aus Map oder Array aus. Geben Sie einen Containernamen ein. Er wird als Name des übergeordneten Objekts verwendet, wenn der Anfragetext aus Parametern erstellt wird.

      • Beispiel: Map: { container_name : { ...parameters } }

      • Beispiel: Array: {container_name : [ { ...parameters } ] }

  5. Geben Sie den Speicherort der Antwortdaten ein. Damit wird das Zielantwortobjekt in der JSON-Antwort gesucht.

Anfrage-URL-Parameter

Parameter Variable Kommentar
Agent-ID {AGENT_ID} Die interne Agent-ID.
Benutzerdefinierte Agent-ID {AGENT_CUSTOM_ID} Optionales Feld aus dem Nutzerprofil.
E‑Mail-Adresse des Kundenservicemitarbeiters {AGENT_EMAIL} Die E-Mail-Adresse des antwortenden Kundenservicemitarbeiters (falls zutreffend).
Name des Endnutzers {NAME}
Vorname des Endnutzers {FIRST_NAME} Entnommen aus Name
Nachname des Endnutzers {LAST_NAME} Wird aus Name übernommen. Wenn keine Angabe gemacht wird, lautet der Standardwert „–“.
Externe ID {UJET_ID} Endnutzer-ID der CCAI Platform
E-Mail {EMAIL}
Anruftyp/Sitzungstyp {SESSION_TYPE}
Telefonnummer des Endnutzers {PHONE_NUMBER} Mit der ausgewählten Einstellung formatiert
Anrufer-ID {Call_ID} CCAI Platform-Anruf-ID.
Chat-ID {Chat_ID} CCAI Platform-Chat-ID.
Sprache {LANG}
Benutzerdefinierte UID {CUSTOM_USER_ID} Mobil: Das ist die linke Seite der E-Mail. Beispiel: test.user3 aus test.user3@test.co
Konto-ID {ACCOUNT_ID} Wird durch Aufrufen des Endpunkts „Kontakt suchen/erstellen“ gefunden.
Datensatz-ID {RECORD_ID} Wird durch Aufrufen des Endpunkts „Datensatz suchen/erstellen“ gefunden.
Sitzungs-ID {SESSION_ID} CCAI Platform-Sitzungs-ID
Menüpfad {MENU_PATH}
Ausgehende Telefonnummer {OUTBOUND_PHONE_NUMBER} Mit der ausgewählten Einstellung formatiert
Name der Warteschlange {QUEUE_NAME}
Warteschlangen-ID {QUEUE_ID} Die interne Warteschlangen-ID.
SDK-Name {SDK_NAME} Name des Endnutzers, wie im Web-SDK oder im Mobile SDK angegeben.
E‑Mail-Adresse des SDK-Entwicklers {SDK_EMAIL} E-Mail-Adresse des Endnutzers, wie im Web-SDK oder im Mobile SDK angegeben.
SDK-Smartphone {SDK_PHONE} Telefonnummer des Endnutzers, wie im Web-SDK oder im Mobile SDK angegeben.
SDK-Kennung {SDK_IDENTIFIER} Identifiziert einen Endnutzer oder ein Konto des Web- oder Mobile-SDK. Geben Sie in dieser Property keine personenbezogenen Daten an. Wenn Sie ein Konto erstellen, ist diese Kennung in der Anfrage erforderlich.
SmartAction-Sitzungs-ID {SMART_ACTION_SESSION_ID}
Smart Action: Bestätigung (Demnächst verfügbar)
SmartAction: Texteingabe (Demnächst verfügbar)
Bewertung {RATING} Nur verfügbar, wenn ein Nutzer sie verlassen hat
Feedbacknachricht {FEEDBACK} Nur verfügbar, wenn ein Nutzer sie verlassen hat
Anrufdauer {CALL_DURATION} In mm:ss
Dauer {HOLD_TIME} In mm:ss
Wartezeit {WAIT_TIME} In mm:ss
Dauer der Anrufnachbereitung (Demnächst verfügbar)
Gerätetyp {DEVICE_TYPE}
Verbindung getrennt von {DISCONNECTED_BY}
Kanal {CHANNEL}
Thema der Aufnahme {TICKET_SUBJECT} Als Titel des Datensatzes verwendet
Beschreibung des Datensatzes {TICKET_DESCRIPTION}
HTML-Code für die Datensatzbeschreibung {TICKET_DESCRIPTION_HTML} Wie die Beschreibung, nur für HTML formatiert
Kommentartext {COMMENT_BODY} Nur verfügbar, wenn ein Kommentar hinzugefügt wird (Bewertung speichern, Anruf/Chat beenden, Anruf/Chat gestartet)
Dateidaten {FILE_DATA} Nur im Endpunkt für das Hochladen von Dateien verfügbar, enthält aber die Base64- oder Daten für das Multipart-Formular.

Funktionen für URL-Parameter anfordern

Es werden Funktionen bereitgestellt, die bei dynamischen CCAI Platform-Variablen helfen. Diese Funktionen sind nur im Abschnitt Anfrageparameter der Endpunkteinstellungen verfügbar.

Der resultierende Wert, der aus einer Funktion erstellt wird, ist ein String. Wenn von der Funktion keine Werte zurückgegeben werden, wird der Parameter vor der Ausführung aus der Parameterliste in der Anfrage entfernt.

Funktion Funktionssyntax Beschreibung
Standardwert =DEFAULT_VALUE(val1, val2) Für den Wert wird val1 verwendet, sofern er nicht null oder leer ist. Andernfalls wird val2 verwendet.
Verkettung Or =CONCAT_OR(val1, val2, val3) Verkettung mehrerer Werte mit or. Beispiel: „val1 or val2 or val3“
Verkettung And =CONCAT_AND(val1, val2, val3) Verkettung mehrerer Werte mit and. Beispiel: „val1 and val2 and val3“

Beispiele

Nachfolgend finden Sie einige Beispiele für die Verwendung der Funktion für den URL-Parameter der Anfrage.

Standard

Im folgenden Beispiel wird DEFAULT_VALUE im Create a Record Endpoint verwendet. Für den Schlüssel und den Wert für die Einrichtung des Kundenservicemitarbeiters wird die Standardfunktion verwendet, um einen Fallback zu haben, wenn die E-Mail-Adresse eines Kundenservicemitarbeiters leer ist. Die E-Mail-Adresse des Kundenservicemitarbeiters kann bei der Erstellung eines Datensatzes aus mehreren Gründen leer sein: Ein Kunde hat den IVR-Anruf möglicherweise beendet, bevor ein zugewiesener Kundenservicemitarbeiter den eingehenden Anruf beantwortet hat. Bei Chats wird ein Datensatz erstellt, bevor ein Kundenservicemitarbeiter antwortet. Auf diese Weise werden erforderliche Parameter möglicherweise auf sichere Standardwerte gesetzt, bis spätere Aktualisierungen erfolgen oder sie bei abgebrochenen Anrufen festgelegt werden.

Feld bearbeiten

Verkettung

Im folgenden Beispiel wird CONCAT_OR im Find an Account by Query-Endpunkt verwendet. Dieses Beispiel bezieht sich speziell auf Zoho CRM, zeigt aber, wie CONCAT_OR verwendet werden kann. CONCAT_AND folgt denselben Regeln, verbindet Werte aber mit and anstelle von or. In den folgenden Fällen sehen Sie die Werte, die zum Zeitpunkt der Ausführung im Endpunkt vorhanden waren, und den resultierenden Wert, der als Anfrageparameter übergeben wurde.

Vorhandene Schlüssel Ergebniswert
ACCOUNT_ID (Id:equals:<uuid>)
ACCOUNT_ID, EMAIL (Id:equals:<uuid>) oder (Email:equals:kim@example)
PHONE_NUMBER, EMAIL (Phone:equals:+12223334444) oder (Email:equals:kim@example)

API-Konto

Die API-Kontoendpunkte unterstützen die Integration mit Konten im CRM.

Aufrufe von Endpunkten, die einen 400-Fehler zurückgeben, werden wiederholt. Bei Aufrufen, die andere Fehler zurückgeben, wird kein Wiederholungsversuch unternommen. Wiederholungen werden eine Woche lang fortgesetzt und nehmen mit einem exponentiellen Rampdown ab. Informationen zu API-Abläufen finden Sie unter Benutzerdefinierte generische CRM-API: Abläufe.

Konto über den Endpunkt „query“ finden (früher „find an account“)

Dieser Endpunkt wird verwendet, um ein Konto anhand der Telefonnummer, E-Mail-Adresse oder internen CRM-ID zu finden. Dies ist der Standardendpunkt, der zum Suchen nach einem Konto verwendet wird.

Beispielantwort:

{
  "id": 123,
  "name": "Kim",
  "phone": "11234567890",
  "email": "Kim@agents.co"
}

Endpunkt zum Suchen eines Kontos anhand der ID

Dieser Endpunkt wird verwendet, um ein Konto anhand der ID zu finden. In der Regel ist diese ID Teil der URL. Bei der URL-Validierung wird auch berücksichtigt, ob die URL nicht mit der ID gebildet wird. In diesem Fall wird dieser Endpunkt nicht verwendet. Dies entspricht den REST-Standards. Wenn bei einem fehlgeschlagenen Lookup ein 404-Fehler zurückgegeben wird, wird als Nächstes „Find by query“ ausgeführt.

Beispielantwort:

{
  "id": 123,
  "name": "Kim",
  "phone": "11234567890",
  "email": "Kim@agents.co"
}

Kontoendpunkt erstellen

Mit diesem Endpunkt wird ein Konto erstellt, wenn wir keines gefunden haben. Bei den meisten CRMs müssen Datensätze mit Konten verknüpft werden. Um einen einheitlichen Ablauf zu erstellen, setzen wir diese Anforderung für alle CRMs durch.

API-Eintrag

Über die API-Datensatzendpunkte können Sie eine Integration mit Datensätzen oder Anfragen in Ihrem CRM vornehmen.

Einen Datensatz per Abfrage finden (früher „find a record“-Endpunkt)

Mit diesem Endpunkt kann ein Datensatz anhand eines Kriteriums gefunden werden. Im Allgemeinen wird damit nach zugehörigen Datensätzen für ein Konto gesucht. Wenn die CCAI-Plattform so konfiguriert ist, dass vorhandene Datensätze wiederverwendet werden, wird der gefundene Datensatz verwendet. Dies ist der Standardendpunkt, der zum Suchen eines Datensatzes verwendet wird.

Beispielantwort:

{
  "id": 456,
  "subject": "Record title",
  "status": "open", // enumerated status open/closed, or 1,2,3
  "contactId": 123, // contact attached to ticket
  "phone": "11234567890", // contact phone
}

Datensatzendpunkt erstellen

Dieser Endpunkt wird zum Erstellen eines Datensatzes verwendet. Ein neuer Datensatz wird erstellt, wenn in der Anfrage Find a record kein Datensatz gefunden wird oder wenn CCAI Platform so konfiguriert ist, dass keine vorhandenen Datensätze wiederverwendet werden.

Beispielanfrage:

{
  "id": 123,
  "subject": "Record title", 
  "description": "A longer description of the record, can be formatted in html",
  "phone": "11234567890", // can be saved in multiple formats
  "contactId": 123,
  "sourceType": "PHONE", // PHONE/CHAT
  "menu": "queue1",
  "direction": "outgoing",
  "rating": 5, // 1-5 scale
  "feedback": "the agent was great!" // description of rating
}

Datensatzendpunkt aktualisieren

Dieser Endpunkt wird zum Aktualisieren eines Datensatzes verwendet. Dadurch werden Titel und Beschreibung des Datensatzes aktualisiert. Dieser Endpunkt kann optional auch verwendet werden, um den Datensatz gemäß CCAI Platform-Ereignissen zu aktualisieren, z. B. CSAT-Bewertung speichern, Anruf- oder Chat-Ende-Ereignisse, ausgewählte Warteschlangen, Nutzer bestätigen und andere.

Datei-Endpunkt hochladen

Dieser Endpunkt wird zum Hochladen eines Anhangs verwendet.

Wählen Sie den Typ für Ihren Upload-Endpunkt aus.

  • Base64-codiertes Formular

  • Mehrteiliges Formular

Auswählen, welche Dateien angehängt werden sollen

  • Anrufaufzeichnungen

  • Chattranskripte

  • Mailboxnachrichten

  • Google Fotos

  • Videos

  • Metadatendatei für Sitzungen

Wählen Sie unter ID und Attachment URL (Anhangs-URL) den Attachment Type (Anhangstyp) aus. Gibt das Format des Antwort-JSON an.

  • ID

  • Anhangs-ID: Geben Sie den Speicherort eines Parameters in der JSON-Antwort für die ID des Anhangs ein. Diese ist für die URL des Attachment Builders als {ATTACHMENT_ID} verfügbar.

  • URL des Attachment Builders: Geben Sie die URL zum Herunterladen der Dateianhänge ein. RECORD_ID und ATTACHMENT_ID sind verfügbare Variablen.

    Beispiel: https://www.example.com/Accounts/{RECORD_ID}/Attachments/{ATTACHMENT_ID}

  • URL des Anhangs

    Geben Sie den Speicherort eines Parameters in der JSON-Antwort für die Download-URL der Datei ein.

Klicken Sie das Kästchen Kommentar zum CRM-Datensatz hinzufügen an, wenn CCAI Platform einen Kommentar zu einem Datensatz hinterlassen soll, wenn eine Datei hochgeladen wurde. Die Einstellung „Textformat“ des Kommentar-Endpunkts wird für diese Kommentare berücksichtigt.

Das folgende Beispiel zeigt ein Multipart-Formular mit POST/PUT/PATCH:

{
  "file": <file data>
  "id": 123, // optional, this can also just be part of the URL;
             // for example https://example-customer.com/upload/record/{RECORD_ID}
}

Beispielantwort:

Beispiel A: Eine Download-URL ist vorhanden

{
  "id": 123,
  "url": "https://some-hosted-url.com"
}

Beispiel B

In diesem Fall ist keine Download-URL vorhanden, aber es gibt einen Download-Anhang-Endpunkt, der diese ID verwendet. Beispiel: https://www.customer-api.com/record/{RECORD_ID}/Attachments/{ATTACHMENT_ID}

{
  "id": 123
}
Kommentarendpunkt

Dieser Endpunkt wird verwendet, um einem Datensatz einen Kommentar hinzuzufügen. Wenn der Endpunkt konfiguriert ist, fügt die CCAI Platform Datensätzen mit den Ereignissen Kommentare hinzu:

  • Anruf- oder Chatbeginn

  • Anruf oder Chat beenden

  • CSAT-Bewertung und ‑Kommentar

  • Benutzerdefiniertes Datenpaket

  • Kommentare übertragen

  • Verfügungscode und Notizen

  • Fragen und Antworten der Umfrage

Wählen Sie für Kommentare Textformat aus. Wenn das Kästchen Text in HTML umwandeln aktiviert ist, wird der Text im HTML-Format oder als Nur-Text angezeigt.

Beispielanfrage, POST/PUT/PATCH:

{
  "comment": "Some text",
 // string can also be formatted on ujet side as html
  "id": 123,
 // optional, this can also just be part of the URL;
 // for example https://example-customer.com/comment/record/{RECORD_ID}
}

Benutzerdefinierte generische CRM-API: Abläufe

Dieser Abschnitt enthält Flussdiagramme für die generischen API-Abläufe für benutzerdefinierte CRMs.

Einfache Flussdiagramme

Einfaches Flussdiagramm

Vorgang zum Suchen oder Erstellen eines Kontos

Vorgang zum Suchen oder Erstellen eines Kontos

Datensatzfluss suchen oder erstellen

Datensatzfluss suchen oder erstellen

Ablauf von Aktionen nach Anrufen oder Chats

Ablauf von Aktionen nach Anrufen oder Chats

Ablauf für das Aktualisieren von Datensätzen

Ablauf für das Aktualisieren von Datensätzen

Kommentarablauf

Kommentarablauf

Ablauf beim Hochladen von Dateien

Ablauf beim Hochladen von Dateien

Agent-Adapter

Ein benutzerdefiniertes CRM bietet eine allgemeine Methode zum Einbinden von Adaptern (UI-Widgets) in CRM-Systeme. Das CRM-System muss in der Lage sein, die Aktivierung und Auslösung der Adapter zu verarbeiten.

Für die Integration von Benutzeroberflächenadaptern ist in der Regel eine CRM-Software oder -Anwendung erforderlich. Wir bieten diese Funktion bereits für mehrere CRM-Softwarelösungen wie Salesforce, Kustomer und Zendesk an.

iFrame

Agent-Adapter lassen sich nahtlos in ein CRM oder ein anderes Tool einbinden, indem Sie ein iFrame-Tag verwenden. Weitere Informationen zum HTML-iFrame-Tag

Das CRM muss jedoch festlegen, wie die Adapter dem Nutzer präsentiert werden. Beispielsweise können UI-Schaltflächen zum Ein- und Ausblenden der Adapter enthalten sein. Außerdem können die Adapter so gestaltet werden, dass sie gezogen werden können, sodass der Kundenservice-Mitarbeiter sie nach Belieben auf dem Bildschirm neu positionieren kann. Die folgenden Beispiele zeigen das URL-Format.

Anrufadapter: https://tenant.loc.ccaiplatform.com/agent/?type=call&from=custom

Chat-Adapter: https://tenant.loc.ccaiplatform.com/agent/?type=chat&from=custom

iFrame-Vorlage

Anrufadapter: html <iframe src="https://tenant.loc.CCAI Platformlatform.com/agent/?type=call&from=custom" allow="microphone; camera; geolocation" width="290" height="600"></iframe>

Chat-Adapter: html <iframe src="https://tenant.loc.CCAI Platformlatform.com/agent/?type=chat&from=custom" allow="microphone; camera; geolocation" width="450" height="590"></iframe>

URL-Parameter

Mit URL-Parametern können Sie der Software zusätzliche Informationen zur Verfügung stellen, z. B. den Interaktionstyp (Anruf oder Chat), die Quelle der Interaktion (benutzerdefiniert) und andere relevante Details.

Wenn die CRM-Einstellung des Mandanten nicht in den Listen verfügbar ist, muss der Parameter From immer auf Custom festgelegt werden.

Typ

  • Anruf
  • Chat

Von

  • Benutzerdefiniert (muss mit der CRM-Einstellung des Mandanten übereinstimmen) Für alle anderen CRMs als die in den Listen muss immer custom angegeben werden. Wenn kein CRM eingerichtet ist, können Sie diesen Parameter überspringen.

Ereignisse in Agent-Adaptern

Agent-Adapter senden Ereignisse, die vom CRM-System abgefangen werden können. Das CRM-System verarbeitet dann Aktualisierungen des CRM. Dazu muss das CRM auf die Posts des übergeordneten Fensters warten und die Post-Daten lesen. Anhand der Daten können Aktionen ausgelöst werden, z. B. das Öffnen eines Ticket-Tabs für eine bestimmte Sitzungs-ID.

Sowohl der Anruf- als auch der Chat-Adapter haben bestimmte Ereignisse, die zur Verbesserung der CRM-Funktionen genutzt werden können.

Anrufadapter

  • Neuer Anruf
  • Anrufbearbeitung gestartet
  • Schwärzung von Anrufen beendet
  • Anruf beenden

Chat-Adapter

  • Neuer Chat
  • Aktiver Chat
  • Eingehende Chatnachricht
  • Ausgehende Chatnachricht
  • Chat beenden
  • Geschlossener Chat

Beide Adapter

  • Agent-Anmeldung
  • Bildschirmfreigabe gestartet
  • Änderung der Fernbedienung für die Bildschirmfreigabe
  • Bildschirmfreigabesitzung – vollständiges Gerät geändert
  • Bildschirmfreigabe beendet
  • Übertragen
  • Party hinzugefügt
  • Kundenservicemitarbeiter stellt Verbindung zur Sitzung her
  • Agent abmelden
  • Agent Assist hinzugefügt

Daten für Ereignisse

  • call_id: Dies ist eine Kennung für einen eingehenden Sprachanruf mit IVR (Interactive Voice Response).

  • chat_id: Eine Kennung für einen eingehenden Messaging-Anruf (Web- oder mobiler Chat).

  • cobrowse_session_id: Dies ist eine Kennung für eine Bildschirmfreigabesitzung. Eine Bildschirmfreigabesitzung kann in einem Anruf oder einer Chatsitzung gestartet werden.

  • session_type: Dies ist der Typ der Sitzung, z. B. Sprache, Chat oder Messaging.

  • va_data_parameters: Alle Variablen, die in der Warteschlange konfiguriert sind und an den Virtual Agent gesendet werden sollen. Dies ist nur für Ereignisse erforderlich, an denen der virtuelle Kundenservicemitarbeiter beteiligt ist. Optional.

  • session_variable: Alle Variablen aus dem Virtual Agent, die in der Nutzlast an die CCAI Platform gesendet werden. Optional.

  • custom_sip_headers: Dadurch können benutzerdefinierte SIP-Header aus eingehenden SIP-Anrufen im POST-Ereignislog angezeigt werden. Nur erforderlich, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: Enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Chat-Prompts mit nicht signierten benutzerdefinierten Daten. Optional.

Agent-IDs

  • agent_id: Eine Kennung für einen Kundenservicemitarbeiter.
  • from_agent_id: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den ursprünglichen Kundenservicemitarbeiter anzugeben.
  • to_agent_id: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den Ziel-Kundenservicemitarbeiter anzugeben.
  • agent_custom_id: Dies ist eine Agent-ID aus dem Nutzerprofil, sofern sie im Profil eingegeben wurde. Optional.
  • from_agent_custom_id: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den ursprünglichen Kundenservicemitarbeiter anzugeben.
  • to_agent_custom_id: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den Ziel-Kundenservicemitarbeiter anzugeben.
  • agent_email: Dies ist die E-Mail-Adresse des Kundenservicemitarbeiters.
  • from_agent_email: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den ursprünglichen Kundenservicemitarbeiter anzugeben.
  • to_agent_email: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den Ziel-Kundenservicemitarbeiter anzugeben.

IDs für virtuelle Kundenservicemitarbeiter

  • virtual_agent_id: Die ID-Nummer, die einem bestimmten Virtual Agent zugewiesen ist.

Warteschlangen-IDs

  • queue_id: Dies ist die Kennung für eine CCAI Platform-Warteschlange. Sie ist nur vorhanden, wenn der Anruf aus einer Warteschlange stammt.
  • from_queue_id: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die ursprüngliche Warteschlange anzugeben.
  • to_queue_id: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die Zielwarteschlange anzugeben.
  • queue_path: Dies ist der Pfad für eine CCAI Platform-Warteschlange. Er ist nur vorhanden, wenn der Anruf aus einer Warteschlange stammt.
  • from_queue_path: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die ursprüngliche Warteschlange anzugeben.
  • to_queue_path: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die Zielwarteschlange anzugeben.

Campaign ID

  • campaign_id: Die Kampagnen-ID der CCAI Platform. Sie werden nur berücksichtigt, wenn der Anruftyp ein Kampagnenanruf ist.
  • campaign_name: Ein Kampagnenname für die CCAI Platform. Sie werden nur berücksichtigt, wenn der Anruftyp ein Kampagnenanruf ist.

Meldung

  • message: Ereignis, das angibt, dass eine neue Verbrauchernachricht empfangen wurde, sowie Nachrichteninhalte.

Sitzungstypen

  • session_type: ein CCAI Platform-Sitzungstyp.
  • cobrowse_session_remote_control: Gibt den Status einer angeforderten Screen Share-Sitzung mit Fernbedienung an. Werte: off, requested, rejected, on.
  • cobrowse_session_full_device: Gibt den Status einer Bildschirmfreigabesitzung für das gesamte Gerät an. Werte: off, requested, rejected, on.

Teilnehmer

  • type: Teilnehmer-Typ – end_user; agent; (aus participants.type der Antwort von /api/v1/calls oder /api/v1/chats).

  • cobrowse_session_requested_by: gibt an, wer eine Bildschirmfreigabesitzung gestartet hat. Mögliche Werte sind agent oder end_user.

  • cobrowse_session_ended_by: Gibt an, wer eine Bildschirmfreigabesitzung beendet hat. Mögliche Werte sind agent, end_user oder api.

  • end_user_id: participants.end_user_id der /api/v1/calls- oder /api/v1/chats-Antwort. Dieses Feld ist nur vorhanden, wenn type: end_user.

Interaktions-/Sitzungstypen

Anruftypen

  • Eingehende Sprachanrufe: Standard-PSTN-Anrufe.
  • Voice Inbound (IVR using Mobile): Fallback-PSTN-Anrufe, die über das Mobile SDK getätigt werden.
  • Eingehende Anrufe (Mobilgeräte): Werden von Nutzern mit installiertem Mobile SDK platziert.
  • Voice Callback (Web): Wird über das Web-SDK initiiert.
  • Voice Inbound (API): Über API initiiert.
  • Sprachnachricht geplant (Mobil): Die Planung erfolgte über ein installiertes Mobile SDK.
  • Voice Scheduled (Web): Geplant über ein installiertes Web-SDK.
  • Voice Outbound: Wird von einem Kundenservicemitarbeiter durch Wählen einer Nummer initiiert.
  • Voice Outbound (API): Über API initiiert.
  • Sprachkampagne: Wird über einen Outbound Dialer (Kampagne) gestartet.

Chattypen

  • Messaging (WhatsApp): Über WhatsApp initiiert.
  • Eingehende Nachrichten (SMS)
  • Ausgehende Nachrichten (SMS)
  • Messaging Outbound (SMS über API)
  • Messaging (Web): Wird über ein installiertes Web-SDK initiiert.
  • Messaging (Mobil): Wird über ein installiertes Mobile SDK initiiert.

Anruf- oder Chattyp

  • Bildschirmfreigabesitzung: Wird von einem Kundenservicemitarbeiter oder Endnutzer während eines Anrufs oder Chats gestartet.

Ereignistypen

Das sind die Ereignistypen, die vom Agent-Adapter gesendet werden:

Agent-Anmeldung

Ein Agent-Anmeldeereignis tritt auf, wenn sich der Agent im Adapter anmeldet.

Hier ist ein Beispiel für ein Agent_Login-Ereignis:

{
  "type": "Agent_Login",
    "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "Kim@example.com",
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: die Agent-ID

  • Optional: agent_custom_id: die benutzerdefinierte Kennung des Agents, sofern sie im Profil des Agents eingegeben wurde.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

Neuer Anruf

Ein neues Anrufereignis tritt ein, wenn ein Kundenservicemitarbeiter einen Anruf entgegennimmt. Dieses Ereignis enthält Informationen wie den Beginn des Anrufs, den zuständigen Kundenservicemitarbeiter und den Ursprungsort des Anrufs.

Hier ein Beispiel für ein New_Call-Ereignis:

{
  "type": "New_Call",
  "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "Kim@example.com",
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "call_id": 103646,
    "session_type": "Voice Campaign (UJET)"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: die Agent-ID

  • agent_custom_id: Die benutzerdefinierte Kennung des Agenten, sofern sie im Profil des Agenten eingegeben wurde. Optional.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

  • queue_id: Die Kennung der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • queue_path: der Pfad der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • campaign_id: die Kennung der Kampagne. Dieses Feld ist für einen Kampagnenaufruf enthalten. Optional.

  • campaign_name: der Name der Kampagne. Dieses Feld ist für einen Kampagnenaufruf enthalten. Optional.

  • call_id: die Anruf-ID

  • session_type: Der Sitzungstyp

  • virtual_agent_id: Die Kennung des virtuellen Agenten. Dieses Feld ist für Ereignisse mit dem virtuellen Kundenservicemitarbeiter enthalten. Optional.

  • va_data_parameters: Die in der Warteschlange konfigurierten Variablen, die an den virtuellen Kundenservicemitarbeiter gesendet werden sollen. Dieses Feld ist für Ereignisse mit dem virtuellen Kundenservicemitarbeiter enthalten. Optional.

  • session_variable: Alle Variablen des virtuellen Kundenservicemitarbeiters, die an die Contact Center AI Platform gesendet werden. Optional.

  • custom_sip_headers: Ermöglicht, dass benutzerdefinierte SIP-Header (Session Initiation Protocol) aus eingehenden SIP-Anrufen im POST-Ereignislog angezeigt werden. Dieses Feld ist enthalten, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Chat mit nicht signierten benutzerdefinierten Daten. Optional.

Anrufbearbeitung gestartet

Das Ereignis „Anrufschwärzung gestartet“ tritt ein, wenn eine Anrufschwärzung gestartet wurde und keine Aufzeichnung erfolgt. Die Ereignisdaten bestehen aus der ID des Kundenservicemitarbeiters, der den Anruf bearbeitet hat, und der Anruf-ID.

  • agent_id: die ID des Kundenservicemitarbeiters, der den Anruf bearbeitet hat
  • call_id: die ID des Anrufs

Hier sehen Sie ein Beispiel für das Ereignis „Anrufschwärzung gestartet“:

{
  "agent_id": 2896,
  "call_id": 97939
}

Schwärzung von Anrufen beendet

Das Ereignis „Anrufschwärzung beendet“ tritt ein, wenn eine Anrufschwärzung beendet wurde und die Aufzeichnung fortgesetzt wird. Dieses Ereignis besteht aus der ID des Kundenservicemitarbeiters, der den Anruf bearbeitet hat, und der call ID.

  • agent_id: die ID des Kundenservicemitarbeiters, der den Anruf bearbeitet hat
  • call_id: die ID des Anrufs

Hier sehen Sie ein Beispiel für Ereignisdaten, die angeben, dass die Schwärzung eines Anrufs beendet wurde:

{
  "agent_id": 2896,
  "call_id": 97939
}

Anruf beenden

Ein Ereignis zum Beenden eines Anrufs tritt ein, wenn ein Anruf beendet wird. Dieses Ereignis enthält Informationen wie das Ende des Anrufs, den zuständigen Kundenservicemitarbeiter und den Ursprung des Anrufs.

Hier ist ein Beispiel für ein End_Call-Ereignis:

{
  "type": "End_Call",
  "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "Kim@example.com",
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "call_id": 103646,
    "session_type": "Voice Campaign (UJET)"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: die Agent-ID

  • agent_custom_id: Die benutzerdefinierte Kennung des Agenten, sofern sie im Profil des Agenten eingegeben wurde. Optional.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

  • queue_id: Die Kennung der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • queue_path: der Pfad der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • campaign_id: die Kennung der Kampagne. Dieses Feld ist für einen Kampagnenaufruf enthalten. Optional.

  • campaign_name: der Name der Kampagne. Dieses Feld ist für einen Kampagnenaufruf enthalten. Optional.

  • call_id: die Anruf-ID

  • session_type: Der Sitzungstyp

  • virtual_agent_id: Die Kennung des virtuellen Agenten. Dieses Feld ist für Ereignisse mit dem virtuellen Kundenservicemitarbeiter enthalten. Optional.

  • va_data_parameters: Die in der Warteschlange konfigurierten Variablen, die an den virtuellen Kundenservicemitarbeiter gesendet werden sollen. Dieses Feld ist für Ereignisse mit dem virtuellen Kundenservicemitarbeiter enthalten. Optional.

  • session_variable: Alle Variablen des virtuellen Kundenservicemitarbeiters, die an die Contact Center AI Platform gesendet werden. Optional.

  • custom_sip_headers: Ermöglicht, dass benutzerdefinierte SIP-Header (Session Initiation Protocol) aus eingehenden SIP-Anrufen im POST-Ereignislog angezeigt werden. Dieses Feld ist enthalten, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Neuer Chat

Ein neues Chat-Ereignis tritt ein, wenn ein Kundenservicemitarbeiter eine Chatsitzung übernimmt. Dieses Ereignis gibt an, wann der Chat gestartet wurde, und enthält Informationen dazu, welcher Kundenservicemitarbeiter den Chat bearbeitet hat, aus dem der Chat stammt.

Hier ein Beispiel für ein New_chat-Ereignis:

{
  "type": "New_Chat",
  "data": {
    "chat_id": 73522,
    "session_type": "messaging inbound (web chat)",
    "agent_id": 1,
    "agent_email": "ariel@example.com",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • chat_id: die Chat-ID

  • session_type: Der Sitzungstyp

  • agent_id: die Agent-ID

  • agent_custom_id: Die benutzerdefinierte Kennung des Agenten, sofern sie im Profil des Agenten eingegeben wurde. Optional.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

  • queue_id: Die Kennung der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • queue_path: Der Pfad der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Chat beenden

Ein „End chat“-Ereignis tritt ein, wenn eine Chatsitzung beendet wird. Dieses Ereignis gibt an, wann der Chat beendet wurde, und enthält Informationen wie den Agenten, der den Chat bearbeitet hat, und den Ursprung des Chats.

Hier ein Beispiel für ein End_Chat-Ereignis:

{
  "type": "End_Chat",
  "data": {
    "chat_id": 73522,
    "session_type": "Messaging Inbound (Web Chat)",
    "agent_id": 1,
    "agent_email": "ariel@example.com",
    "queue_id": null,
    "queue_path": null,
    "agent_custom_id": null
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • chat_id: die Chat-ID.

  • session_type: Der Sitzungstyp.

  • agent_id: die Agent-ID.

  • agent_custom_id: die benutzerdefinierte Kennung des Agenten, sofern sie im Profil des Agenten eingegeben wurde. Optional.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

  • queue_id: Die Kennung der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • queue_path: der Pfad der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Aktiver Chat

Ein aktives Chat-Ereignis tritt auf, wenn der Kundenservicemitarbeiter im Chat-Adapter zu einem Chat-Tab wechselt.

Hier ist ein Beispiel für ein Active_Chat-Ereignis:

{
  "type": "Active_Chat",
  "data": {
    "chat_id": 73521,
    "session_type": "messaging inbound (web chat)",
    "agent_id": 1,
    "agent_email": "ariel@example.com",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • chat_id: die Chat-ID

  • session_type: Der Sitzungstyp

  • agent_id: die Agent-ID

  • agent_custom_id: die benutzerdefinierte Kennung des Agenten, sofern sie im Profil des Agenten eingegeben wurde. Optional.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

  • queue_id: Die Kennung der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • queue_path: der Pfad der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Eingehende Chatnachricht

Ein Ereignis für eine eingehende Chatnachricht weist darauf hin, dass eine neue Kundennachricht eingegangen ist. Sie enthält den Inhalt der Nachricht.

Für ein Ereignis für eine eingehende Chatnachricht werden Daten für die folgenden Felder erfasst:

  • chat_id: Identifiziert die Chatsitzung.

  • session_type: Gibt den Typ der Sitzung an, die erstellt wird, z. B. eingehende Nachrichten über den Webchat.

  • agent_id: Gibt den Agenten an, der die Chatsitzung bearbeitet.

  • agent_custom_id: Dieses Feld ist nur vorhanden, wenn das Profil des Agenten eine benutzerdefinierte ID enthält. Optional.

  • agent_email: die E-Mail-Adresse des Kundenservicemitarbeiters, der die Chatsitzung bearbeitet. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt. Optional.

  • queue_id: die ID der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt.

  • queue_path: Der Pfad der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt.

  • message: Ein Ereignis, das angibt, dass eine neue Verbrauchernachricht empfangen wurde, sowie der Inhalt der Nachricht

  • custom_data_secured: Ermöglicht die Übertragung von gesicherten benutzerdefinierten SDK-Daten. Optional.

  • custom_data_not_secured: Ermöglicht die Übertragung von ungesicherten benutzerdefinierten SDK-Daten. Optional.

Hier ein Beispiel für ein Chat_Inbound_Message-Ereignis:

{
  "type": "Chat_Inbound_Message",
  "data": {
    "chat_id": 73522,
    "session_type": "messaging inbound (web chat)",
    "agent_id": 1,
    "agent_email": "ariel@example.com",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel",
    "message" : "Can you help me with my order tracking number?"
  }
}

Ausgehende Chatnachricht

Ein Chat-Ereignis für ausgehende Nachrichten tritt ein, wenn eine neue Verbrauchernachricht empfangen wird. Sie enthält den Inhalt der Nachricht.

Für das Ereignis „Chat-Ausgangsnachricht“ werden Daten für die folgenden Felder erfasst:

  • chat_id: Identifiziert die Chatsitzung.

  • session_type: Gibt den Typ der Sitzung an, die erstellt wird, z. B. eingehende Nachrichten über den Webchat.

  • agent_id: Gibt den Agenten an, der die Chatsitzung bearbeitet.

  • agent_custom_id: Dieses Feld ist nur enthalten, wenn das Profil des Agenten eine benutzerdefinierte ID hat. Optional.

  • agent_email: die E-Mail-Adresse des Kundenservicemitarbeiters, der die Chatsitzung bearbeitet. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt. Optional.

  • queue_id: die ID der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt.

  • queue_path: Der Pfad der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt.

  • message: Das Ereignis gibt an, dass eine neue Verbrauchernachricht empfangen wurde, und enthält den Nachrichteninhalt.

  • custom_data_secured: Ermöglicht die Übertragung von gesicherten benutzerdefinierten SDK-Daten. Optional.

  • custom_data_not_secured: Ermöglicht die Übertragung von ungesicherten benutzerdefinierten SDK-Daten. Optional.

Hier ein Beispiel für ein Chat_Outbound_Message-Ereignis:

{
  "type": "Chat_Outbound_Message",
  "data": {
    "chat_id": 73522,
    "session_type": "messaging inbound (web chat)",
    "agent_id": 1,
    "agent_email": "ariel@example.com",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel",
    "message" : "Please give me a moment to look up your account information"
  }
}

Geschlossener Chat

Ein verworfenes Chat-Ereignis tritt auf, wenn der Kundenservicemitarbeiter den Chat-Tab im Chat-Adapter schließt.

Hier ein Beispiel für ein Dismissed_Chat-Ereignis:

{
  "type":"Dismissed_Chat",
  "data":{"chat_id":73522,
    "session_type":"Messaging Inbound (Web Chat)",
    "agent_id":1,
    "agent_email":"ariel@example.com"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • chat_id: die Chat-ID

  • session_type: Der Sitzungstyp

  • agent_id: die Agent-ID

  • agent_custom_id: die benutzerdefinierte Kennung des Agenten, sofern sie im Profil des Agenten eingegeben wurde. Optional.

  • agent_email: Die E-Mail-Adresse, die mit dem Konto des Kundenservicemitarbeiters verknüpft ist.

  • queue_id: Die Kennung der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • queue_path: der Pfad der Warteschlange, aus der der Anruf stammt. Dieses Feld ist enthalten, wenn der Anruf aus einer Warteschlange stammt. Optional.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: Enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Bildschirmfreigabe gestartet

Das Ereignis Screen Share session started (Bildschirmfreigabesitzung gestartet) wird ausgelöst, wenn eine Bildschirmfreigabesitzung von einem Kundenservicemitarbeiter oder einem Endnutzer gestartet wird. Eine Bildschirmfreigabe-Sitzung kann während eines Anrufs oder Chats gestartet werden. Weitere Informationen finden Sie unter Bildschirmfreigabe.

Hier ist ein Beispiel für ein JSON-Objekt für ein Ereignis, das angibt, dass eine Bildschirmfreigabesitzung gestartet wurde:

{
  "type": "Cobrowse_Session_Started",
  "data": {
    "agent_id": 5,
    "chat_id": 791,
    "cobrowse_session_id": "Y1zYY6XIYX4oapqpEz3qHw",
    "cobrowse_session_requested_by": "agent",
    "cobrowse_session_remote_control": "off",
    "cobrowse_session_full_device": "off"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: Die Agenten-ID.

  • call_id: Die Kennung für einen eingehenden Anruf über den IVR-Channel (Interactive Voice Response). Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Anrufs gestartet wurde.

  • chat_id: Die Kennung für einen eingehenden Chat im Web- oder Mobilkanal. Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Chats gestartet wurde.

  • cobrowse_session_id: Die Kennung für eine Bildschirmfreigabesitzung.

  • cobrowse_session_requested_by: Gibt an, wer eine Bildschirmfreigabesitzung gestartet hat. Mögliche Werte sind agent und end-user.

  • cobrowse_session_remote_control: Gibt den Status einer Screen-Sharing-Sitzung für die Fernbedienung an. Mögliche Werte sind on, rejected, requested und off.

  • cobrowse_session_full_device: Gibt den Status einer Sitzung zur Bildschirmfreigabe für das gesamte Gerät an. Mögliche Werte sind on, rejected, requested und off.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: Enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Änderung der Fernbedienung für die Bildschirmfreigabe

Ein Ereignis vom Typ „Screen Share session remote control changed“ (Änderung der Fernbedienung einer Bildschirmfreigabesitzung) tritt ein, wenn sich der Status einer Bildschirmfreigabesitzung mit Fernbedienung ändert. Dieses Ereignis gibt den Status der Bildschirmfreigabesitzung für die Fernbedienung an. Weitere Informationen finden Sie unter Bildschirmfreigabe.

Hier ist ein Beispiel für ein JSON-Objekt für ein Cobrowse_Session_Remote_Control_Changed-Ereignis:

{
  "type": "Cobrowse_Session_Remote_Control_Changed",
  "data": {
    "agent_id": 5,
    "chat_id": 791,
    "cobrowse_session_id": "Y1zYY6XIYX4oapqpEz3qHw",
    "cobrowse_session_remote_control": "requested"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: die Agent-ID.

  • call_id: Die Kennung für einen eingehenden Anruf über den IVR-Channel (Interactive Voice Response). Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Anrufs gestartet wurde.

  • chat_id: Die Kennung für einen eingehenden Chat im Web- oder Mobilkanal. Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Chats gestartet wurde.

  • cobrowse_session_id: Die Kennung für eine Bildschirmfreigabesitzung.

  • cobrowse_session_remote_control: Gibt den Status einer Screen Share-Sitzung mit Fernbedienung an. Mögliche Werte sind on, rejected, requested und off.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: Enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Bildschirmfreigabesitzung – vollständiges Gerät geändert

Das Ereignis „Bildschirmfreigabesitzung – vollständiges Gerät geändert“ tritt ein, wenn sich der Status einer Bildschirmfreigabesitzung für ein vollständiges Gerät ändert. Dieses Ereignis gibt den Status der Bildschirmfreigabesitzung für das gesamte Gerät an. Weitere Informationen finden Sie unter Bildschirmfreigabe.

Hier ein Beispiel für ein Cobrowse_Session_Full_Device_Changed-Ereignis:

{
  "type": "Cobrowse_Session_Full_Device_Changed",
  "data": {
    "agent_id": 5,
    "cobrowse_session_id": "9-Kshrag-gn6ZSuIxoMtWQ",
    "cobrowse_session_full_device": "rejected"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: die Agent-ID.

  • call_id: Die Kennung für einen eingehenden Anruf über den IVR-Channel (Interactive Voice Response). Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Anrufs gestartet wurde.

  • chat_id: Die Kennung für einen eingehenden Chat im Web- oder Mobilkanal. Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Chats gestartet wurde.

  • Cobrowse_session_id: Die Kennung für eine Bildschirmfreigabesitzung.

  • Cobrowse_session_full_device: Gibt den Status einer Sitzung zur Bildschirmfreigabe für das gesamte Gerät an. Mögliche Werte sind on, rejected, requested und off.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Bildschirmfreigabe beendet

Ein „Screen Share session started“-Ereignis tritt auf, wenn eine Bildschirmfreigabesitzung von einem Kundenservicemitarbeiter, einem Endnutzer oder der API beendet wird. Weitere Informationen finden Sie unter Bildschirmfreigabe konfigurieren.

Hier ein Beispiel für ein Cobrowse_Session_Ended-Ereignis:

{
  "type": "Cobrowse_Session_Ended",
  "data": {
    "agent_id": 5,
    "cobrowse_session_id": "9-Kshrag-gn6ZSuIxoMtWQ",
    "cobrowse_session_requested_by": "end_user",
    "cobrowse_session_ended_by": "agent",
    "cobrowse_session_remote_control": "on",
    "cobrowse_session_full_device": "rejected"
  }
}

Im Folgenden finden Sie Beschreibungen der Felder für Ereignisdaten:

  • agent_id: die Agent-ID.

  • call_id: Die Kennung für einen eingehenden Anruf über den IVR-Channel (Interactive Voice Response). Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Anrufs gestartet wurde.

  • chat_id: Die Kennung für einen eingehenden Chat im Web- oder Mobilkanal. Dieses Feld ist enthalten, wenn die Bildschirmfreigabesitzung während eines Chats gestartet wurde.

  • cobrowse_session_id: Die Kennung für eine Bildschirmfreigabesitzung.

  • cobrowse_session_ended_by: Gibt an, wer die Bildschirmfreigabesitzung beendet hat. Mögliche Werte sind agent, end-user und api.

  • cobrowse_session_remote_control: Gibt den Status einer Screen Share-Sitzung mit Fernbedienung an. Mögliche Werte sind on, rejected, requested und off.

  • cobrowse_session_full_device: Gibt den Status einer Sitzung zur Bildschirmfreigabe für das gesamte Gerät an. Mögliche Werte sind on, rejected, requested und off.

  • custom_data_secured: Enthält signierte benutzerdefinierte Daten von Ihrem Server. Optional.

  • custom_data_not_secured: enthält nicht signierte benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Benutzerdefinierte Daten für Chat ohne Signatur (optional). Optional.

Übertragen

Ein Übertragungsereignis tritt auf, wenn ein Anruf oder Chat übertragen wird. Es kann sich entweder um eine warme oder eine kalte Übertragung handeln.

Die folgenden Ereignisfelder sind Teil eines Übertragungsereignisses.

  • chat_id oder call_id: Identifiziert den Anruf oder die Chatsitzung.

  • session_type: Gibt den Typ der Sitzung an, die erstellt wird, z. B. eine eingehende Nachricht über den Webchat.

  • campaign_id: Die ID der Kampagne. Dieses Feld ist nur vorhanden, wenn der Anruftyp ein Kampagnenanruf ist. Optional.

  • campaign_name: der Name der Kampagne. Dieses Feld ist nur vorhanden, wenn der Anruftyp ein Kampagnenanruf ist. Optional.

  • from_agent_id: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den ursprünglichen Kundenservicemitarbeiter anzugeben.

  • from_agent_custom_id: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den ursprünglichen Kundenservicemitarbeiter anzugeben. Optional.

  • from_agent_email: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den ursprünglichen Kundenservicemitarbeiter anzugeben.

  • to_agent_id: Wird verwendet, wenn Anrufe oder Chats von einem Kundenservicemitarbeiter an einen anderen weitergeleitet werden, um den Ziel-Kundenservicemitarbeiter anzugeben.

  • to_agent_custom_id: Wird verwendet, wenn Anrufe oder Chats von einem Kundenservicemitarbeiter an einen anderen weitergeleitet werden, um den Ziel-Kundenservicemitarbeiter anzugeben. Optional.

  • to_agent_email: Wird beim Weiterleiten von Anrufen oder Chats von einem Kundenservicemitarbeiter an einen anderen verwendet, um den Ziel-Kundenservicemitarbeiter anzugeben.

  • from_queue_id: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die ursprüngliche Warteschlange anzugeben.

  • from_queue_path: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die ursprüngliche Warteschlange anzugeben.

  • to_queue_id: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die Zielwarteschlange anzugeben.

  • to_queue_path: Wird beim Weiterleiten von Anrufen oder Chats von einer Warteschlange in eine andere verwendet, um die Zielwarteschlange anzugeben.

  • virtual_agent_id: Die ID, die einem virtuellen Agenten zugewiesen ist. Optional.

  • va_data_parameters: Alle Variablen, die in der Warteschlange konfiguriert sind und an den virtuellen Kundenservicemitarbeiter gesendet werden sollen. Dies ist nur für Ereignisse erforderlich, an denen der virtuelle Kundenservicemitarbeiter beteiligt ist. Optional.

  • session_variable: Alle Variablen aus dem virtuellen Kundenservicemitarbeiter, die in der Nutzlast an die CCAI-Plattform gesendet werden. Optional.

  • custom_sip_headers: Ermöglicht, dass benutzerdefinierte SIP-Header aus eingehenden SIP-Anrufen im POST-Ereignisprotokoll angezeigt werden. Er ist nur erforderlich, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

  • custom_data_secured: Ermöglicht die Übertragung von gesicherten benutzerdefinierten SDK-Daten. Optional.

  • custom_data_not_secured: Ermöglicht die Übertragung von ungesicherten benutzerdefinierten SDK-Daten. Optional.

Hier sehen Sie ein Beispiel für ein Umstiegsereignis:

{
  "type": "Transfer_Chat",
  "data": {
    "chat_id": 103646,
    "session_type": "Messaging Inbound (SMS)",
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "from_agent_id": 1,
    "from_agent_custom_id": "007",
    "from_agent_email": "Ira@example.com",
    "to_agent_id" : 5
    "to_agent_custom_id": "100"
    "to_agent_email" : "ariel@example.com"
    "from_queue_id": 8469,
    "from_queue_path": "Developers / Ariel",
    "to_queue_id" : 1234,
    "to_queue_path" : "Schemes / Auric"
  }
}

Party hinzugefügt

Ein Ereignis vom Typ „Party added“ bezieht sich auf jede Übertragung. Es kann sich entweder um eine Anruf- oder eine Chatweiterleitung handeln.

Ein Ereignis vom Typ „Party hinzugefügt“ enthält die folgenden Daten:

  • chat_id oder call_id: Identifiziert die Anruf- oder Chatsitzung.

  • session_type: Gibt den Typ der Sitzung an, die erstellt wird, z. B. eine eingehende Nachricht über den Webchat.

  • agent_custom_id: Dieses Feld ist nur vorhanden, wenn das Profil des Agenten eine benutzerdefinierte ID enthält. Optional.

  • agent_email: die E-Mail-Adresse des Kundenservicemitarbeiters, der den Anruf oder die Chatsitzung bearbeitet.

  • queue_id: die ID der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt. Optional.

  • queue_path: Der Pfad der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt. Optional.

  • campaign_id: Die ID der Kampagne. Dieses Feld ist nur enthalten, wenn der Anruftyp ein Kampagnenanruf ist. Optional.

  • campaign_name: der Name der Kampagne. Dieses Feld ist nur enthalten, wenn der Anruftyp ein Kampagnenanruf ist. Optional.

  • type: Der Teilnehmer-Typ, z. B. „end_user“ oder „agent“. Dieses Feld wird als Teil der Antwort „participants.type“ von /api/v1/calls oder /api/v1/chats zurückgegeben.

  • end_user_id: die end_user_id. Dieses Feld wird als Teil der Antwort von /api/v1/calls oder /api/v1/chats zurückgegeben. Dieses Feld ist nur für Anrufe oder Chats von Endnutzern vorhanden, die von einem Kundenservicemitarbeiter an einen anderen weitergeleitet werden, um den Ziel-Kundenservicemitarbeiter anzugeben. Optional.

  • virtual_agent_id: Die Kennung, die einem virtuellen Agenten zugewiesen ist. Optional.

  • va_data_parameters: Alle Variablen, die in der Warteschlange konfiguriert sind und an den virtuellen Kundenservicemitarbeiter gesendet werden sollen. Dies ist nur für Ereignisse erforderlich, an denen der virtuelle Kundenservicemitarbeiter beteiligt ist. Optional.

  • session_variable: Alle Variablen aus dem virtuellen Kundenservicemitarbeiter, die in der Nutzlast an die CCAI-Plattform gesendet werden. Optional.

  • custom_sip_headers: Dadurch können benutzerdefinierte SIP-Header aus eingehenden SIP-Anrufen im POST-Ereignisprotokoll angezeigt werden. Er ist nur erforderlich, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

  • custom_data_secured: Ermöglicht die Übertragung von gesicherten benutzerdefinierten SDK-Daten. Optional.

  • custom_data_not_secured: Ermöglicht die Übertragung von ungesicherten benutzerdefinierten SDK-Daten. Optional.

Hier ist ein Beispiel für ein Party_Added-Ereignis.

{
  "type": "Party_Added",
  "data": {
    "chat_id": 103646,
    "session_type": "Messaging Inbound (SMS)",
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "ariel@example.com",
    "queue_id": 8469,
    "queue_path": "Developers / Ariel",
    "type" : "agent"
  }
}

Kundenservicemitarbeiter stellt Verbindung zur Sitzung her

Das Ereignis „Kundenservicemitarbeiter stellt Verbindung zu Sitzung her“ tritt ein, wenn ein Kundenservicemitarbeiter eine Verbindung zu einer Sitzung herstellt. Es gibt zwei verschiedene Arten von Ereignissen. Der Typ wird dadurch bestimmt, ob es sich um einen Anruf oder einen Chat handelt.

Die folgenden Ereignisfelder sind Teil eines Ereignisses, bei dem sich ein Kundenservicemitarbeiter mit einer Sitzung verbindet.

  • agent_id: Gibt den Agenten an, der den Anruf oder die Chatsitzung bearbeitet.

  • agent_email: die E-Mail-Adresse des Kundenservicemitarbeiters, der den Anruf oder die Chatsitzung bearbeitet.

  • agent_custom_id: Dieses Feld ist nur vorhanden, wenn das Profil des Agenten eine benutzerdefinierte ID enthält. Optional.

  • chat_id oder call_id: Identifiziert die Anruf- oder Chatsitzung.

  • virtual_agent_id: Die ID, die einem bestimmten virtuellen Agenten zugewiesen ist. Optional.

  • campaign_id: Die ID der Kampagne. Dieses Feld ist nur enthalten, wenn der Anruftyp ein Kampagnenanruf ist. Optional.

  • campaign_name: der Name der Kampagne. Dieses Feld ist nur enthalten, wenn der Anruftyp ein Kampagnenanruf ist. Optional.

  • queue_id: die ID der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt. Optional.

  • queue_path: Der Pfad der Warteschlange, aus der die Chatsitzung stammt. Dieses Feld ist nur enthalten, wenn der Chat aus einer Warteschlange stammt. Optional.

  • session_type: Gibt den Typ der Sitzung an, die erstellt wird, z. B. eine eingehende Nachricht über den Webchat.

  • virtual_agent_id: Die ID, die einem virtuellen Agenten zugewiesen ist. Optional.

  • va_data_parameters: Alle Variablen, die in der Warteschlange konfiguriert sind, um an den virtuellen Kundenservicemitarbeiter gesendet zu werden. Dies ist nur für Ereignisse erforderlich, an denen der virtuelle Kundenservicemitarbeiter beteiligt ist. Optional.

  • session_variable: Alle Variablen aus dem virtuellen Kundenservicemitarbeiter, die in der Nutzlast an UJET gesendet werden. Optional.

  • custom_sip_headers: Dadurch können benutzerdefinierte SIP-Header aus eingehenden SIP-Anrufen im POST-Ereignisprotokoll angezeigt werden. Er ist nur erforderlich, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

  • custom_data_secured: Ermöglicht die Übertragung von gesicherten benutzerdefinierten SDK-Daten. Optional.

  • custom_data_not_secured: Ermöglicht die Übertragung von ungesicherten benutzerdefinierten SDK-Daten. Optional.

Hier ein Beispiel für Agent_Joined_Chat-Ereignisdaten:

{
  "type": "Agent_Joined_Chat",
  "data": {
    "chat_id": 103646,
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "ariel@example.com",
    "queue_id": 8469,
    "queue_path": "Developers / Ariel",
    "session_type": "Messaging Inbound (SMS)",
  }
}

Agent abmelden

Ein Agent-Abmeldeereignis tritt auf, wenn sich ein Kundenservicemitarbeiter vom Agent-Adapter abmeldet.

Die folgenden Ereignisfelder sind Teil eines Agent_Logout-Ereignisses.

  • agent_id: die ID des Agenten, der sich angemeldet hat

  • agent_email: die mit dem Agentenkonto verknüpfte E-Mail-Adresse.

  • agent_custom_id: die benutzerdefinierte ID des KI-Agenten, sofern sie im Profil des KI-Agenten eingegeben wurde. Optional.

Hier ist ein Beispiel für ein Agent_Logout-Ereignis:

{
  "type": "Agent_Logout",
  "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "ariel@example.com",
  }
}

Agent Assist wurde gestartet

Ein „Agent Assist started“-Ereignis tritt ein, wenn ein Kundenservicemitarbeiter Agent Assist während eines Anrufs oder einer Chatsitzung aktiviert.

Hier ist ein Beispiel für ein Agent_Assist_Started-Ereignis:

{
  "type": "Agent_Assist_Started",
  "data": {
    "conversation_id": "12345",
    "queue_id": "65",
    "agent_id": "1",
    "session_id": "78534G4RT4284",
    "queue_language_id": "en",
    "timestamp": "12:45:15"
  }
}

Hier sind die Ereignisfelder:

  • conversation_id: die Unterhaltungs-ID

  • queue_id: die Warteschlangen-ID

  • agent_id: die Agent-ID

  • session_id: die Sitzungs-ID

  • queue_language_id: die Sprache der Warteschlange

  • timestamp: der Zeitstempel

Pop-up-Benachrichtigungen im Hintergrund

Mit der Funktion „Screen Pop“ können Kundenservicemitarbeiter im Hintergrund einen CRM-Screen Pop ausführen. Das bedeutet, dass Kundeninformationen auf dem Bildschirm des Kundenservicemitarbeiters angezeigt werden, ohne dass dieser etwas tun muss. So wird für einen reibungsloseren Ablauf für Verbraucher gesorgt und die Bearbeitungszeit für Kundenservicemitarbeiter wird verkürzt.

CRM-Datensatz-Pop-up

Das Ereignis CRM_Record_Pop ist ein serverseitiges Ereignis, das ausgelöst wird, wenn ein Ticket abgerufen werden muss. Dieses Ereignis enthält einen Parameter namens recordUrl, der die URL des CRM-Datensatzes enthält. So können Sie einen Screen Pop ausführen, indem Sie POST-Ereignisse abonnieren, wenn Sie eingebettete Adapter verwenden.

Im folgenden Beispiel wird gezeigt, wie Sie einen Ereignis-Listener hinzufügen, der auf Nachrichten wartet, die von einem anderen Frame oder Fenster gesendet werden. Dieses Code-Snippet ermöglicht die Kommunikation zwischen verschiedenen Frames oder Fenstern und dynamische Aktualisierungen der im iFrame angezeigten Inhalte auf Grundlage empfangener Nachrichten.

// name is the html property of the iframe
const iframeTarget = document.querySelector('iframe[name="target_iframe_adapter"]')

// example usage of add event listener
// https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
window.addEventListener('message', (e) => {
  try {
    const data = JSON.parse(e.data)
    const type = data.type
    console.log('EventListener: ', JSON.stringify(data))

    if (type === 'CRM_Record_Pop') {
      const recordUrl = data.data.recordUrl
      if (!recordUrl) {
        return
      }
      console.log(`Opening <strong>recordUrl</strong> in iframe <strong>${iframeTarget.getAttribute('name')}</strong>`)

      // changing an iframe target to the record URL pop 
      iframeTarget.src = recordUrl
    } else if (type === 'New_Chat') {
      console.log(`<strong>Chat started...</strong>`)

      // handling here for new_chat events
    } else if (type === 'End_Chat') {
      console.log(`<strong>Chat ended...</strong>`)
      // handling here for end_chat events
    } if (.... //other event types) {
      // code handling for other types
    }else {
      console.log(JSON.stringify(data))
    }
  } catch (e) {
    log(e, true)
  }
}, false)