Benutzerdefiniertes CRM

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

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

Sitzungsmetadaten und von Nutzern hochgeladene Mediendateien werden an einen externen Speicherdienst übertragen. Kundenservicemitarbeiter können die von Nutzern hochgeladenen Mediendateien während der Sitzung direkt im Agentenadapter sehen.

Eine benutzerdefinierte CRM-Lösung wird mit einer Kombination der folgenden Komponenten implementiert. Einige Komponenten können für Ihre Konfiguration relevant sein oder auch nicht:

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

• Metadaten und Mediendateien an einen externen Speicherdienst übertragen

• Generische API-Integration

• Benutzerdefinierte Such-URL

• CRM-Datensatzaktualisierung per E‑Mail

• Konto- oder Fallsuchfunktion im Agentenadapter

Vorbereitung

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

Sitzungsmetadaten

Die Sitzungsmetadatendatei enthält detaillierte Informationen zur Sitzung. Diese wird 15 Minuten nach Ende der Sitzung gesendet. Weitere Informationen finden Sie unter Sitzungsmetadatendatei.

Benutzerdefinierte CRM-Interaktions- und Integrationsmethoden

	Generische API	Benutzerdefinierte URL
Kontosuche	Ja	Ja
Anfragesuche	Ja
Aktualisierung der Supportanfrage	Ja	Nein

Generische API

Die Integrationsmethode „Generische API“ bietet die Möglichkeit, die API Ihres benutzerdefinierten CRM-Systems zu verwenden, um eine bidirektionale Verbindung mit der CCAI Platform herzustellen. Diese nahtlose Methode fühlt sich genauso an wie die standardmäßige CRM-Integration. Der Kundenservicemitarbeiter muss keine Maßnahmen ergreifen, um einen CRM-Eintrag für Anruf- oder Chatsitzungen zu erstellen. Dies hängt von der jeweiligen 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 über einen benutzerdefinierten Link, der für jede Sitzung erstellt wird, mit Ihrem CRM-System interagieren. Im Gegensatz zur Standard-CRM-Integration und der generischen API-Umgebung muss der Agent aktiv werden, damit ein CRM-Eintrag erstellt wird. In einigen Fällen reicht es aus, einen Tab mit dem benutzerdefinierten Link aus der Sitzung zu öffnen. In anderen Fällen muss der Kundenservicemitarbeiter den Datensatz möglicherweise manuell erstellen.

Details und Konfiguration der benutzerdefinierten Such-URL

Die grundlegende Funktion der URL besteht darin, eine CRM-Suche durchzuführen. Je nach CRM können jedoch basierend auf dem Inhalt der benutzerdefinierten URL komplexere Prozesse ausgelöst werden. Die URL für das benutzerdefinierte CRM kann mit Variablen konfiguriert werden, die Sitzungsinformationen enthalten, und ist während der Sitzung im Agentenadapter zugänglich. Wenn die URL aufgerufen wird, wird das benutzerdefinierte CRM-System angewiesen, eine Suche durchzuführen. Über diese CRM-Suche können Kundenservicemitarbeiter ein „Ticket-Pop-up“ für die aktive Anruf- oder Chatsitzung verwenden. Der Prozess für benutzerdefinierte Links hängt ausschließlich davon ab, ob das benutzerdefinierte CRM-System diesen Link verarbeiten und bei Bedarf ändern oder neu schreiben kann.

Die extern gespeicherten Sitzungsmetadaten, Anrufaufzeichnungen und anderen Dateien werden nur dann mit dem CRM-Eintrag verknüpft, wenn auch die aufgeführte Methode zur E-Mail-Aktualisierung verwendet wird.

In dieser Konfiguration meldet sich der Kundenservicemitarbeiter auf separaten Tabs im CCAI Platform-Portal und im CRM an. Anrufe und Chats werden auf dem Tab „CCAI Platform“ bearbeitet und Ticketdetails werden auf einem CRM-Tab aufgerufen.

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

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

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

• Die benutzerdefinierte Such-URL muss vorkonfiguriert sein

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

Verhalten der benutzerdefinierten Such-URL

• Die CCAI Platform fügt der URL nur Parameter hinzu, die nicht leer sind.

• Die CCAI Platform speichert die generierte URL mit ANI/UID/E-Mail-Adresse nicht in der CCAI Platform-Datenbank, nachdem die Sitzung beendet wurde.

Konfiguration der benutzerdefinierten Such-URL

Aufgrund unterschiedlicher eindeutiger Kennungen und 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 beim Web- und mobilen SDK wahrscheinlich die CUID und die E-Mail-Adresse verwendet werden.

Die folgenden Variablen können zum Konfigurieren einer Such-URL verwendet werden:

Variable	Werte
{CUSTOMER_PHONE_NUMBER}	Die Telefonnummer des Endnutzers.
{ANI}	Die Telefonnummer des Endnutzers. Wird aus Gründen der 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 Sitzungs-Channel. 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: Anruf-ID Chat-ID E‑Mail-ID
{CUSTOM_AGENT_ID}	Das optionale Feld für die Agent-ID im user-Objekt. Die Agenten-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 Chat-Datensätzen verzögert wird, damit diese Variable definiert werden kann. Sie können die Erstellung von Anruf- oder Chat-Datensätzen unter Einstellungen > Betriebsverwaltung > Details zur Erstellung von CRM-Datensätzen verzögern. Weitere Informationen finden Sie unter Details zur Erstellung von CRM-Einträgen.

Konfiguration des CCAI Platform-Portals

1. Melden Sie sich im CCAI Platform-Portal mit einem Konto an, dem die Administratorrolle zugewiesen ist.

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-Datensatzaktualisierung per E‑Mail

In Konfigurationen wie der benutzerdefinierten Such-URL müssen die Sitzungsmetadaten nach Abschluss einer Sitzung im CRM aktualisiert werden. 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 Speicherort gesendet. Der Inhalt der E-Mail wird verwendet, um einen Eintrag in Ihrem CRM zu aktualisieren. Diese Funktion kann global und pro Warteschlange konfiguriert werden. Nachdem die E‑Mail eingegangen ist, kann Ihr CRM so konfiguriert werden, dass ein neuer CRM-Eintrag für die Sitzung aktualisiert oder erstellt wird.

Details zur E‑Mail-Adresse

• Gesendet von [e-mail]

• Enthält:

  • Subject line

  • Text mit den Sitzungsmetadaten in JSON-Syntax

  • Anhang im TXT-Format mit Chattranskript, falls zutreffend

• Die CCAI Platform wartet nach dem Ende der Sitzung 15 Minuten und sendet dann die E‑Mail.

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

Globale Konfiguration

1. Melden Sie sich im CCAI Platform-Portal mit einem Konto an, dem die Administratorrolle zugewiesen ist.

2. Gehen Sie zu Einstellungen > Entwicklereinstellungen.

3. Achten Sie darauf, dass im Bereich „CRM“ die Option Benutzerdefiniertes CRM ausgewählt ist.

4. Aktivieren Sie Sitzungsergebnis per E-Mail senden.

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

6. Klicken Sie auf Änderungen speichern.

Warteschlangenspezifische Konfiguration

1. Melden Sie sich im CCAI Platform-Portal mit einem Konto an, dem die Administratorrolle zugewiesen ist.

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

3. Aktivieren Sie Send session outcome via Email (Sitzungsergebnis per E-Mail senden).

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

   

5. Klicken Sie auf Benutzerdefinierte CRM-Einstellung speichern.

Übernahme und Überschreiben von Einstellungen

Einstellungen	Verhalten
Global = NICHT aktiviert Warteschlange = NICHT aktiviert	Nicht für alle Warteschlangen senden.
Global = NICHT aktiviert Warteschlange = Aktiviert	Die Warteschlangeneinstellung (d.h. der Status „Ein“ oder „Aus“) überschreibt die globale Einstellung. E-Mails werden von einer bestimmten Warteschlange an eine E-Mail-Adresse gesendet, die in der Einstellung Warteschlange definiert ist.
Global = Aktiviert Warteschlange = NICHT aktiviert	Die Warteschlangeneinstellung (E‑Mail-Adresse, Ein/Aus-Status) übernimmt die globale Einstellung. E‑Mails werden von 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) überschreibt die globale Einstellung. E-Mails werden von 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 Chat-Adapter.

3. Klicken Sie auf den Button In neuem Browserfenster öffnen, um die Suche zu starten.

4. Klicken Sie auf Link kopieren, um die Such-URL in die Zwischenablage zu kopieren.

Externer Speicher für benutzerdefinierte CRM-Lösungen

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

Zum Konfigurieren des externen Speichers müssen Sie Folgendes haben:

• Ein gültiges CCAI Platform-Konto mit zugewiesener Administrator- und Agentenrolle für die Konfiguration und das Testen

• Ein externer Speicherdienst

Hinweis: Die CCAI Platform fungiert als Nutzer des Dienstes, richtet Ihren externen Speicher jedoch nicht ein und verwaltet ihn auch nicht.

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 übertragen 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

Agenten- und Supervisor-Erfahrung

Während des Anrufs oder Chats werden Fotos und Videos, die der Nutzer mithilfe von Smart Actions hochgeladen hat, im Agentenadapter angezeigt.

Wenn Sie die CRM-Interaktion mit benutzerdefinierter URL in Kombination mit der Methode zur E-Mail-Aktualisierung der Sitzungsmetadatendatei verwenden, können Kundenservicemitarbeiter und Supervisoren ü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 im CCAI Platform-Portal mit einem Konto an, dem die Administratorrolle zugewiesen ist.

2. Gehen Sie zu Einstellungen > Entwicklereinstellungen.

3. Gehen Sie auf der Seite „Entwicklereinstellungen“ zum Abschnitt Externer Speicher.

4. Aktivieren Sie die Informationsspeicherung außerhalb von CRM-Servern, indem Sie den Schalter auf An stellen. Wählen Sie dann die zu speichernden Dateitypen aus.

5. Wählen Sie im Bereich „Servereinrichtung“ den Speichertyp aus und führen Sie die Einrichtungsschritte aus: SFTP-Server, Google Cloud -Bucket.

SFTP-Server

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

2. Geben Sie die Portnummer 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 in das Feld Passwort ein.

5. Wenn der SFTP-Server einen privaten Schlüssel für die Authentifizierung erfordert, setzen Sie ein Häkchen bei Privater SSH-Schlüssel.

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, aktivieren Sie das Kästchen Ordnerpfad und geben Sie den SFTP-Ordnerpfad ein.

8. Klicken Sie auf Änderungen speichern.

Cloud Storage

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

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

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

4. Wenn die Sitzungsinformationen in einem bestimmten Ordner im Bucket Google Cloud gespeichert werden sollen, setzen Sie ein Häkchen bei Ordnerpfad und geben Sie den Google Cloud Ordnerpfad ein.

5. Klicken Sie auf Verknüpfen und speichern.

Konfiguration des externen Speichers testen

Für CRM-Systeme mit bestehender Standardintegration:

1. Melden Sie sich in Ihrem CRM an.

2. Melden Sie sich im CRM mit den CCAI Platform-Anmeldedaten und der zugewiesenen Agentenrolle in der CCAI Platform an.

3. Anruf starten oder chatten 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 in den Entwicklereinstellungen für die URLs des CRM-Speichers und des externen Speichers Sitzungsdateien senden und festlegen, welche Quelle zum Anzeigen von Dateien im Agentenadapter verwendet werden soll.

Wenn Sie diese Einstellungen aufrufen möchten, muss der externe Speicher unter Einstellungen > Entwicklereinstellungen > Externer Speicher aktiviert sein. Aktivieren Sie die Option Enable information storage outside CRM servers (Informationsspeicherung außerhalb von CRM-Servern aktivieren).

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.

Hinweis: Wenn das Kästchen für den CRM-Speicher nicht angekreuzt ist, werden die Aufzeichnungen nur im externen Speicher gespeichert und der Link zum CRM wird verwendet.

Wenn das Kästchen angeklickt 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 KI-Agenten-Adapter.

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

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

2. Wählen Sie die Quell-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 es wird ein Link zum CRM verwendet.

• Wenn das Kästchen angeklickt 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:

• Eine zeigt die Medien im CCAI Platform-Adapter. Der externe Speicher oder das CRM.

• Der andere ist im Bericht enthalten. Die Medien-URL wird in den Berichten sowie in Menüs wie „Einstellungen“, „Anrufe“ und „Abgeschlossen“ angezeigt.

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 dedizierten Seite im CCAI Platform-Portal laden. Nach der Aktivierung wird der CRM-Tab im CCAI Platform-Portal geladen und Ihre benutzerdefinierte CRM-Seite angezeigt. Dies kann unter Entwicklereinstellungen > CRM konfiguriert werden.

Mit dieser Funktion können Kundenservicemitarbeiter Echtzeit-Support-Sitzungen über die Anruf- und Chat-Adapter der CCAI Platform abwickeln und gleichzeitig in Ihrem benutzerdefinierten CRM arbeiten. Dazu gehört die Überprüfung automatisch geöffneter Konto- und Eintragsdetails sowie sitzungsspezifischer Dateien und Daten, die von Ihrer mobilen App oder von Nutzern über das CCAI Platform-Portal übergeben werden.

Hinweis: Damit Ihr CRM im CCAI Platform-Portal angezeigt werden kann, muss es in einem iFrame angezeigt werden dürfen, der auf einer separaten Domain gehostet wird.

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 das Dreistrich-Menü .

2. Klicken Sie im Bereich CRM auf Benutzerdefiniertes CRM.

3. Klicken Sie auf den Ein/Aus-Button CRM im CCAI Platform-Portal anzeigen, um die Option zu aktivieren.

4. Geben Sie unter Angezeigte URL die URL für Ihre benutzerdefinierte CRM-Seite ein und klicken Sie dann 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 nicht im System gefunden wird. Erstellen Sie einen CRM-Eintrag mit einer temporären Konto-ID und lösen Sie einen benutzerdefinierten Link mit Parametern basierend auf der Konfiguration auf Warteschlangenebene aus.

Hinweis: Wenn die URL nicht festgelegt ist, folgt die CCAI Platform dem üblichen Suchprozess und erstellt keinen CRM-Eintrag mit einem temporären Konto.

Pop-up-Fenster für einzelne Warteschlangen aktivieren

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

2. Gehen Sie im Bereich zu Benutzerdefinierte URL öffnen.

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

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

Ein Beispiel wird bereitgestellt.

1. Klicken Sie auf Speichern.

Benutzerdefinierte allgemeine API-Integration für CRM

Die allgemeine API-Integrationsmethode bietet die Möglichkeit, die API Ihres CRM-Systems zu verwenden, um eine bidirektionale Verbindung mit der CCAI Platform herzustellen. Diese nahtlose Methode fühlt sich genauso an wie die standardmäßige CRM-Integration.

Der Kundenservicemitarbeiter muss nichts weiter tun, um einen CRM-Eintrag für Anruf- oder Chatsitzungen zu erstellen. Je nach der individuellen API-Konfiguration kann sie eine nahtlose Datensatzsuche und -aktualisierung ermöglichen.

Terminologie

Begriff	Beschreibung
Konto	Sie wird verwendet, um auf die Entität „Konto/Kontakt/Kunde/Lead“ im CRM zu verweisen. In Ihrem CRM hat diese Entität möglicherweise einen anderen Namen. Konten enthalten Datensätze.
Record	Damit wird auf die Entität „Fall/Ticket/Unterhaltung/Vorfall“ im CRM verwiesen. In Ihrem CRM hat diese Entität möglicherweise einen anderen Namen. Datensätze gehören zu Konten.
Kommentar	Sie wird verwendet, um auf die Entität „Kommentar/Notiz“ im CRM zu verweisen. In Ihrem CRM hat diese Entität möglicherweise einen anderen Namen. Kommentare gehören zu Datensätzen.

API-Einstellungen

In diesem Abschnitt werden die Einstellungen für die benutzerdefinierte CRM API beschrieben.

Authentifizierungsmethode

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

• Basisauthentifizierung: Konfigurieren Sie Authentifizierungsdaten, 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 Platform unterstützt das branchenübliche Autorisierungsprotokoll OAuth 2.0. Geben Sie OAuth-Informationen an, wenn Sie die Option Weiterleitungs-URL als Teil der Autorisierungs-URL und Token-URL einbeziehen 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: [phone], Suchen: *222*333*4444

• E.164: [phone]

• US Local: 2223334444

• US-Standardformat: [phone]

• International: [phone]

Zeitüberschreitung bei API-Anfrage

Konfigurieren Sie das Zeitlimit für API-Anfragen über das Drop-down-Menü auf 1–10 Sekunden. Dieses Zeitlimit wird auf alle von Ihnen konfigurierten Endpunkte angewendet.

CRM-Such-URLs

Geben Sie Such-URLs an, mit denen ein Agent auf das aktuelle Konto und den aktuellen Datensatz verwiesen wird.

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

Sie können CRM-Such-URLs auch mit dem Web SDK und den mobilen SDKs verwenden. Sie können die SDKs so konfigurieren, dass CRM-Konto- und Datensatzinformationen gesucht und im Agent-Adapter angezeigt werden. Eine vollständige Liste der CRM-Such-URLs finden Sie unter Anfrage-URL-Parameter.

URL für die Kontosuche

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 Generic API.

1. Damit Ihre Kundenservicemitarbeiter die Kontosuche verwenden können, müssen Sie die Endpunkte Konto suchen und Konto erstellen konfigurieren.

2. Außerdem können Sie die Endpunkte Eintrag suchen und Eintrag erstellen einrichten, damit Ihre Agenten Einträge suchen oder erstellen können. Dafür ist die Kontoeinrichtung aus dem vorherigen Schritt erforderlich.

3. Wenn Sie schließlich die Endpunkte Eintrag aktualisieren, Datei hochladen und Kommentieren eingeben, werden Aktualisierungen von Einträgen aktiviert. Dazu ist die Einrichtung der Aufzeichnung 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.

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

4. Wenn der Endpunkt POST/PUT/PATCH ist, bietet die CCAI-Plattform detailliertere Steuerelemente für die Erstellung der Anfrage. Wählen Sie unter Property oder Container die Option Datenformat anfordern aus. Es gibt das Format der JSON-Anfrage an.

   • Property. Dies gibt an, dass das Anfrageobjekt eine einfache Attributzuordnung ist, wenn die CCAI Platform den Anfragetext aus Parametern erstellt.

   • Dies gibt an, dass die zu sendenden Anfrageobjektdaten in einer Struktur verschachtelt sein müssen. Wählen Sie als Containertyp entweder 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. Es wird verwendet, um das Zielantwortobjekt in der JSON-Antwort zu finden.

URL-Parameter anfordern

Parameter	Variable	Kommentar
Agent-ID	{AGENT_ID}	Die interne Agenten-ID.
Benutzerdefinierte Agenten-ID	{AGENT_CUSTOM_ID}	Optionales Feld aus dem Nutzerprofil.
E-Mail-Adresse des KI-Agenten	{AGENT_EMAIL}	Die E-Mail-Adresse des antwortenden Kundenservicemitarbeiters, falls zutreffend.
Name des Endnutzers	{NAME}
Vorname des Endnutzers	{FIRST_NAME}	Aus Name entnommen
Nachname des Endnutzers	{LAST_NAME}	Wird aus Name übernommen. Wenn keine Angabe gemacht wird, wird „--“ verwendet.
Externe ID	{UJET_ID}	CCAI Platform-Endnutzer-ID
E-Mail	{EMAIL}
Anruftyp/Sitzungstyp	{SESSION_TYPE}
Telefonnummer des Endnutzers	{PHONE_NUMBER}	Mit der ausgewählten Einstellung formatiert
Anruf-ID	{Call_ID}	CCAI Platform-Anruf-ID.
Chat-ID	{Chat_ID}	CCAI Platform-Chat-ID.
Sprache	{LANG}
Benutzerdefinierte UID	{CUSTOM_USER_ID}	Auf Mobilgeräten: auf der linken Seite der E-Mail. Beispiel: test.user3 von [e-mail]
Konto-ID	{ACCOUNT_ID}	Wird durch Aufrufen des Endpunkts „Kontakt suchen/erstellen“ gefunden.
Eintrags-ID	{RECORD_ID}	Wird durch Aufrufen des Endpunkts „Datensatz suchen/erstellen“ gefunden.
Sitzungs-ID	{SESSION_ID}	CCAI Platform-Sitzungs-ID
Pfad	{MENU_PATH}
Telefonnummer für ausgehende Anrufe	{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}	Nutzername des Endnutzers, wie im Web SDK oder Mobile SDK angegeben.
SDK-E‑Mail-Adresse	{SDK_EMAIL}	E-Mail-Adresse des Endnutzers, wie im Web SDK oder Mobile SDK angegeben.
SDK Phone	{SDK_PHONE}	Telefonnummer des Endnutzers, wie im Web SDK oder Mobile SDK angegeben.
SDK-ID	{SDK_IDENTIFIER}	Identifiziert einen Endnutzer oder ein Konto des Web- oder Mobile SDK. Geben Sie in dieser Property keine personenidentifizierbaren Informationen an. Beim Erstellen eines Kontos ist diese Kennung in der Anfrage erforderlich.
SmartAction-Sitzungs-ID	{SMART_ACTION_SESSION_ID}
SmartAction: Überprüfung		(Demnächst verfügbar)
SmartAction: Texteingabe		(Demnächst verfügbar)
Bewertung	{RATING}	Nur verfügbar, wenn ein Nutzer sie hinterlassen hat
Feedbacknachricht	{FEEDBACK}	Nur verfügbar, wenn ein Nutzer sie hinterlassen hat
Anrufdauer	{CALL_DURATION}	In mm:ss
Haltedauer	{HOLD_TIME}	In mm:ss
Wartezeit	{WAIT_TIME}	In mm:ss
Dauer der Nachbereitung von Anrufen		(Demnächst verfügbar)
Gerätetyp	{DEVICE_TYPE}
Verbindung getrennt von	{DISCONNECTED_BY}
Kanal	{CHANNEL}
Betreff des Datensatzes	{TICKET_SUBJECT}	Als Titel des Datensatzes verwendet
Beschreibung aufnehmen	{TICKET_DESCRIPTION}
HTML-Beschreibung des Datensatzes	{TICKET_DESCRIPTION_HTML}	Entspricht der 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 zum Hochladen von Dateien verfügbar, enthält aber die Base64- oder Daten für mehrteilige Formulare.

Funktionen für Anfrage-URL-Parameter

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 von einer Funktion erstellt wird, ist ein String. Wenn die Funktion keine Werte zurückgibt, wird der Parameter vor der Ausführung aus der Parameterliste in der Anfrage entfernt.

Funktion	Funktionssyntax	Beschreibung
Standardwert	=DEFAULT_VALUE(val1, val2)	Der Wert verwendet val1, sofern er nicht null oder leer ist, und wird standardmäßig auf val2 zurückgesetzt.
Verkettung Or	=CONCAT_OR(val1, val2, val3)	Verkettung mehrerer Werte mit or. Beispiel: „val1 oder val2 oder val3“
Verkettung And	=CONCAT_AND(val1, val2, val3)	Verkettung mehrerer Werte mit and. Beispiel: „val1 and val2 and val3“

Beispiele

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

Standard

Im folgenden Beispiel wird DEFAULT_VALUE in Create a Record Endpoint verwendet. Für den Schlüssel und den Wert für die Einrichtung des KI-Agenten wird die Standardfunktion verwendet, um einen Fallback für den Fall zu haben, dass der Wert für die E-Mail-Adresse eines KI-Agenten leer ist. Die E-Mail-Adresse des Kundenservicemitarbeiters kann aus verschiedenen Gründen beim Erstellen des Datensatzes leer sein: Ein Kunde hat den IVR-Anruf möglicherweise beendet, bevor ein zugewiesener Kundenservicemitarbeiter den eingehenden Anruf angenommen hat, oder bei Chats wird ein Datensatz erstellt, bevor ein Kundenservicemitarbeiter antwortet. Auf diese Weise können erforderliche Parameter auf sichere Werte voreingestellt werden, bis sie später aktualisiert werden, oder sie können für abgebrochene Aufrufe festgelegt werden.

Verkettung

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

Hinweis: Wenn zum Zeitpunkt der Ausführung keine CCAI Platform-Variablen verfügbar sind, wird der vollständige Stringeintrag an dieser Position entfernt. Im ersten Fall, wenn nur ACCOUNT_ID vorhanden ist, werden die Strings Phone:equals und Email:equals ignoriert und nicht im endgültigen Wert zurückgegeben.

Schlüssel vorhanden	Resultierender Wert
ACCOUNT_ID	(Id:equals:<uuid>)
ACCOUNT_ID, EMAIL	(Id:equals:<uuid>) oder (Email:equals:kim@example)
PHONE_NUMBER, EMAIL	(Phone:equals:[phone]) oder (Email:equals:kim@example)

API-Konto

Die API-Kontoendpunkte unterstützen die Integration in 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. Die Wiederholungsversuche werden eine Woche lang fortgesetzt und nehmen exponentiell ab. Informationen zu API-Abläufen finden Sie unter Benutzerdefinierte generische CRM-API: Abläufe.

Konto über Abfrageendpunkt finden (früher „Kontoendpunkt finden“)

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 eines Kontos verwendet wird.

Beispielantwort:

{
  "id": 123,
  "name": "Kim",
  "phone": "11234567890",
  "email": "[e-mail]"
}

Konto nach ID-Endpunkt suchen

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. Dabei werden REST-Standards eingehalten. Wenn bei einer fehlgeschlagenen Suche ein 404-Fehler zurückgegeben wird, wird als Nächstes die Suche per Abfrage durchgeführt.

Beispielantwort:

{
  "id": 123,
  "name": "Kim",
  "phone": "11234567890",
  "email": "[e-mail]"
}

Kontoendpunkt erstellen

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

API-Eintrag

Die API-Eintragsendpunkte bieten die Möglichkeit, Einträge oder Fälle in Ihr CRM-System einzubinden.

Datensatz per Abfrage suchen (früher „Datensatz-Endpunkt suchen“)

Dieser Endpunkt wird verwendet, um einen Eintrag anhand eines Kriteriums zu finden. Im Allgemeinen wird dies verwendet, um zugehörige Einträge für ein Konto zu finden. Wenn die CCAI Platform 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
}

Eintragsendpunkt erstellen

Dieser Endpunkt wird zum Erstellen eines Datensatzes verwendet. Ein neuer Datensatz wird erstellt, wenn ein Datensatz nicht über die Anfrage Datensatz suchen gefunden wird oder wenn die CCAI Platform so konfiguriert ist, dass vorhandene Datensätze nicht 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
}

Eintragsendpunkt aktualisieren

Dieser Endpunkt wird verwendet, um einen Eintrag zu aktualisieren. Der Titel und die Beschreibung des Datensatzes werden aktualisiert. Dieser Endpunkt kann optional auch verwendet werden, um den Datensatz gemäß CCAI Platform-Ereignissen zu aktualisieren, z. B. CSAT-Bewertung speichern, Ereignisse zum Beenden von Anrufen oder Chats, ausgewählte Warteschlangen, Nutzer überprüfen und andere.

Endpunkt zum Hochladen einer Datei

Dieser Endpunkt wird zum Hochladen eines Anhangs verwendet.

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

• Base64-codiertes Formular

• Mehrteiliges Formular

Dateien zum Anhängen auswählen

• Anrufaufzeichnungen

• Chattranskripte

• Mailboxnachrichten

• Google Fotos

• Videos

• Sitzungsmetadaten-Datei

Wählen Sie unter Anhangstyp die Option ID oder Anhangs-URL aus. Es gibt das Format der JSON-Antwort 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 Anhang-Builders als {ATTACHMENT_ID} verfügbar.

• URL des Attachment Builders: Geben Sie die URL ein, um den Dateianhang herunterzuladen. RECORD_ID und ATTACHMENT_ID sind verfügbare Variablen.

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

• Anhang-URL

  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-Eintrag hinzufügen an, wenn die CCAI Platform einen Kommentar zu einem Eintrag hinterlassen soll, wenn eine Datei hochgeladen wurde. Die Einstellung „Text Format“ des Kommentar-Endpunkts wird für diese Kommentare berücksichtigt.

Das folgende Beispiel ist ein mehrteiliges 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:

Hinweis: Dies hängt von den Funktionen Ihres Back-Ends ab. Wenn Sie eine Download-URL für die CCAI Platform hosten, verwenden Sie Beispiel A. Andernfalls können Sie auch eine URL wie in Beispiel B erstellen.

Beispiel A: Eine Download-URL ist vorhanden

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

Beispiel B

In diesem Fall gibt es keine Download-URL, aber einen Endpunkt für den Download von Anhängen, der diese ID verwendet. Beispiel: https://www.customer-api.com/record/{RECORD_ID}/Attachments/{ATTACHMENT_ID}

{
  "id": 123
}

Kommentar-Endpunkt

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

• Anruf oder Chat starten

• Anruf oder Chat beenden

• CSAT-Bewertung und -Kommentar

• benutzerdefiniertes Datenpaket

• Kommentare übertragen

• Dispositionscode und Notizen

• Fragen und Antworten der Umfrage

Wählen Sie Textformat für Kommentare aus. Wenn das Kästchen Text in HTML konvertieren aktiviert ist, wird der Text im HTML-Format ausgegeben, andernfalls im Nur-Text-Format.

Beispielanfrage, POST/PUT/PATCH:

{
  "comment": "Some text",
 // string can also be formatted on CCAI Platform 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

Die Integration des benutzerdefinierten CRM (generische API) der CCAI Platform funktioniert als eine Reihe von Abläufen. Zu Beginn eines Anrufs, Chats oder einer Voicemail führt die Plattform die konfigurierten Konto- und Datensatzschritte aus, um ein Konto und einen Datensatz (z. B. ein Ticket oder einen Fall) in Ihrem CRM zu finden oder zu erstellen. Während und nach der Interaktion werden auch Aktionen wie Kommentare, Aktualisierungen von Datensätzen und Dateiuploads ausgeführt. Die folgenden Flussdiagramme zeigen, wann die einzelnen Schritte ausgeführt werden und was für die Ausführung konfiguriert werden muss.

Wann die Abläufe ausgeführt werden

Diese Abläufe werden an verschiedenen Punkten einer Interaktion ausgeführt. Die Schritte „Konto“ und „Aufzeichnen“ werden während der Interaktion ausgeführt. Aufzeichnungen, Transkripte und Voicemails werden nach Beendigung der Interaktion hochgeladen, zusammen mit dem Kommentar, dem Update-Datensatz und anderen Aktionen nach der Sitzung. Anhänge wie Fotos, Videos, Dokumente und Audioaufnahmen werden hochgeladen, wenn sie während der Interaktion geteilt werden. Bevor einer dieser Abläufe ausgeführt wird:

• Der Trigger für die Aktion ist aufgetreten, z. B. ist eine Datei zum Hochladen verfügbar oder der Anruf, Chat oder die Mailboxnachricht wurde beendet.
• Die entsprechende Aktion ist in Ihren benutzerdefinierten CRM-Einstellungen aktiviert. Beispielsweise ist der Dateityp für den Upload aktiviert oder der API-Kommentar- oder API-Aktualisierungsendpunkt ist konfiguriert.
• Für alle Vorgänge, bei denen Daten in das CRM geschrieben werden (Hochladen in einen Datensatz, Posten eines Kommentars oder Aktualisieren eines Datensatzes), sind die erforderlichen Endpunkte konfiguriert und es ist ein Datensatz für die Sitzung vorhanden. Wenn der Eintrag noch nicht erstellt wurde, wird die Aktion von der Plattform zurückgehalten und automatisch ausgeführt, sobald der Eintrag vorhanden ist.

Für das Hochladen einer Datei in einen externen Speicher ist kein Eintrag erforderlich. Die Aufzeichnungsanforderung gilt für CRM-Schreibvorgänge.

In einigen Konfigurationen fungiert das Konto als Sitzungseintrag: Wenn die Erstellung des Eintrags übersprungen wird und Sitzungsdaten an das CRM-Konto gesendet werden, werden die Endpunkte für Kommentare, Uploads und Aktualisierungen auf Kontoebene anstelle der Endpunkte auf Eintragsebene verwendet. In den Diagrammen umfasst „Aufzeichnung“ ein Konto, das als Sitzungsaufzeichnung fungiert, wenn diese Konfiguration aktiviert ist.

Informationen zur Reihenfolge von Konto, Datensatz und Post-Sitzung, zum Timing von Wiederholungsversuchen und zum Fehlerverhalten finden Sie unter Fehlerbehandlung, Wiederholungsversuche und Reihenfolge von Aufrufen in Custom CRM (Generic API).

Flussdiagramme

In diesen Flussdiagrammen tauchen drei Ergebnisse immer wieder auf:

Ergebnis	Bedeutung
Übersprungen	Die Aktion ist durch die Konfiguration deaktiviert, sodass nichts gesendet wird.
Litigation Hold	Die Aktion ist konfiguriert, wartet aber, bis der Datensatz vorhanden ist, und wird dann automatisch ausgeführt.
Konfiguration unvollständig	Ein erforderlicher Endpunkt fehlt, daher kann die Aktion nicht ausgeführt werden.

Grundlegender Ablauf

Bei einer Interaktion wird der Kontoschritt, dann der Aufzeichnungsschritt und anschließend alle Aktionen nach der Sitzung ausgeführt. Die einzelnen Schritte werden nur ausgeführt, wenn die entsprechenden Einstellungen und Endpunkte konfiguriert sind. Uploads in den externen Speicher werden ohne Datensatz ausgeführt. Andere Aktionen nach der Sitzung schreiben in das CRM und warten, bis ein Datensatz vorhanden ist. Diese Übersicht zeigt den Pfad nach der Sitzung. Dateien, die während der Interaktion freigegeben werden, folgen dem Ablauf zum Hochladen von Dateien, sobald sie verfügbar sind.

Konto finden oder erstellen

Die Plattform sucht das Konto anhand einer angegebenen ID, Telefonnummer, E‑Mail-Adresse oder einer konfigurierten Abgleichsmethode. Wenn kein Konto gefunden wird und die Kontoerstellung aktiviert ist, wird ein Konto erstellt. Wenn keine Identifikationsdetails vorhanden sind, wird ein anonymes Konto erstellt. Ein gefundenes oder erstelltes Konto wird dann mit der Sitzung verknüpft.

Datensatz suchen oder erstellen

Wenn der Aufzeichnungsmodus aktiviert ist, verwendet die Plattform einen vorhandenen Datensatz für die Sitzung wieder, sofern er noch verwendbar ist. Andernfalls wird ein neuer Datensatz erstellt. Die Datensatz-ID kann mit der Anfrage oder von einem Datensatz stammen, der bereits mit der Interaktion verknüpft ist. Wenn eine Datensatz-ID mit der Anfrage angegeben wird, fügt die Plattform auch einen Kommentar hinzu, in dem angegeben wird, ob der Datensatz wiederverwendet oder ein neuer erstellt wurde.

Eintrag aktualisieren

Sobald ein Eintrag vorhanden ist, sendet die Plattform eine Aktualisierungsanfrage, die aus Ihrer konfigurierten Vorlage erstellt wurde. Wenn der Update-Endpunkt auf einen Platzhalterwert festgelegt ist, wird das Update übersprungen.

Aktionen nach der Sitzung

Nach einer Sitzung können mehrere unabhängige Aktionen ausgeführt werden, die jeweils durch ein eigenes Ereignis ausgelöst werden: ein beendeter Anruf, Chat oder eine beendete E‑Mail, eine eingereichte Bewertung, eine beantwortete Umfrage oder eine Aufzeichnung, ein Transkript oder eine Voicemail, die nach der Sitzung verfügbar wird. Dateiuploads folgen dem Ablauf „Datei hochladen“. Die Aktionen „Kommentieren“ und „Aktualisieren“ schreiben in das CRM und warten, bis ein Eintrag vorhanden ist.

Kommentar

Ein Kommentar kann durch eine Aktion vom Typ „Abgeschlossen“, „Bewertung“, „Umfrage“ oder „Datei-Upload“ gepostet werden. Dafür sind ein API-Kommentarendpunkt und ein vorhandener Eintrag erforderlich. Es wird gewartet, bis der Eintrag vorhanden ist. Der Kommentar wird je nach Kommentareinstellung als HTML oder Nur-Text gepostet.

Ablauf zum Hochladen von Dateien

Der externe Speicher wird pro Dateityp aktiviert. Wenn sie für einen Dateityp aktiviert ist, wird die Datei im externen Speicher abgelegt, andernfalls im CRM. Mit einer separaten Einstellung kann die Datei auch in das CRM-System hochgeladen werden, nachdem sie an den externen Speicher gesendet wurde. Schreibvorgänge im CRM (Dateianhang oder Kommentar) werden nur ausgeführt, wenn ein Datensatz vorhanden ist.

Agentenadapter

Ein benutzerdefiniertes CRM bietet eine allgemeine Methode zur Integration von Adaptern (UI-Widgets) in CRM-Systeme. Das CRM-System muss in der Lage sein, die Art und Weise zu verarbeiten, wie die Adapter darin aktiviert und ausgelöst werden.

Für die Einbindung von Benutzeroberflächenadaptern ist in der Regel eine CRM-Software oder ‑Anwendung erforderlich. Wir bieten diese Funktion bereits für verschiedene CRM-Software wie Salesforce, Kustomer, Zendesk und andere an.

iFrame

Agentenadapter können mithilfe eines iFrame-Tags nahtlos in ein CRM-System oder ein anderes Tool eingebunden werden. Weitere Informationen zum HTML-iFrame-Tag finden Sie unter HTML-iFrame-Tag.

Das CRM muss jedoch die Darstellung der Adapter für den Nutzer verwalten. Sie kann beispielsweise UI-Schaltflächen zum Ein- und Ausblenden der Adapter enthalten. Außerdem können die Adapter so konzipiert werden, dass sie ziehbar sind, sodass der Agent 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.ccaiplatform.com/agent/?type=call&from=custom" allow="microphone; camera; geolocation" width="290" height="600"></iframe>

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

Beachten Sie beim Einbetten der Adapter Folgendes:

• Das Attribut allow ist erforderlich. Der Anrufadapter verwendet WebRTC und benötigt microphone. camera und geolocation sind für die Bildschirmfreigabe und standortbezogene Funktionen erforderlich. Wenn die Berechtigungen nicht an den iFrame delegiert werden, werden sie vom Browser im Hintergrund blockiert und der Agent kann keine Anrufe entgegennehmen.

• Betten Sie einen Adapter pro iFrame ein. Jeder Adapter hat eine eigene Echtzeitverbindung. Die Anruf- und Chat-Adapter sind also zwei separate iFrames und posten Ereignisse unabhängig voneinander.

• Der Adapter erkennt, dass er eingebettet ist, weil sich sein übergeordnetes Fenster in einem anderen Ursprung befindet. Stellen Sie die Hostseite über Ihre eigene Domain und nicht über die Mandantendomain der CCAI Platform bereit.

URL-Parameter

URL-Parameter können verwendet werden, um der Software zusätzliche Informationen bereitzustellen, z. B. die Art der Interaktion (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 Von immer auf Benutzerdefiniert festgelegt werden.

Typ

• Anruf
• Chat

Von

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

Ereignisse in KI-Agenten-Adaptern

Agentenadapter posten Ereignisse, die vom CRM-System abgefangen werden können, das dann Aktualisierungen am CRM verarbeitet. Dazu muss das CRM die Posts aus dem übergeordneten Fenster abhören und die Post-Daten lesen. Basierend auf den Daten können Aktionen wie das Öffnen eines Ticket-Tabs für eine bestimmte Sitzungs-ID ausgelöst werden.

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

Anrufadapter

• Neuer Anruf
• Nutzer ist beigetreten
• Anrufentfernung gestartet
• Anrufentfernung beendet
• Anruf beenden

Chat-Adapter

• Neuer Chat
• Aktiver Chat
• Eingehende Chatnachricht
• Ausgehende Chatnachricht
• Formular gesendet
• Formular ausgefüllt
• Chat beenden
• Geschlossener Chat

Beide Adapter

• Agentenanmeldung
• Bildschirmfreigabe gestartet
• Fernbedienung für Bildschirmfreigabe geändert
• Bildschirmfreigabe für das gesamte Gerät geändert
• Bildschirmfreigabe beendet
• Übertragen
• Party hinzugefügt
• Kundenservicemitarbeiter verbindet sich mit der Sitzung
• Agent-Abmeldung
• Agent Assist hinzugefügt
• Virtueller Taskassistent ist beigetreten
• Virtueller Aufgabenassistent links
• Sitzungsvariablen für den virtuellen Aufgabenassistenten empfangen
• CRM-Datensatz-Pop-up
• Seite des Drittanbieters öffnen

Nachrichtenformat

Jedes Ereignis wird mit der window.postMessage()-API des Browsers vom Adapter-iFrame an das direkte übergeordnete Fenster (window.parent) gesendet. Das übergeordnete Fenster empfängt es als MessageEvent.

Die Nachricht hat die folgenden Eigenschaften:

• event.data ist ein JSON-String, kein Objekt. Rufen Sie immer JSON.parse(event.data) auf, bevor Sie es lesen. Da andere Skripts auf der Seite möglicherweise auch postMessage() mit Nicht-JSON-Nutzlasten verwenden, sollten Sie den Parse-Vorgang in ein try/catch-Konstrukt einbinden.

• Das geparste Objekt hat genau zwei Schlüssel auf oberster Ebene:

  {
    "type": "<event type>",
    "data": { ... }
  }
  

  type ist einer der Strings, die unter Ereignistypen aufgeführt sind. data enthält die Ereignisfelder, die unter Daten für Ereignisse beschrieben sind. Alle ereignisspezifischen Felder befinden sich innerhalb von data, nie auf der obersten Ebene.

• Leere Felder werden weggelassen. Vor dem Posten entfernt der Adapter alle Felder in data, deren Wert null, undefined oder ein leerer String ist. Behandeln Sie jedes Feld so, als wäre es möglicherweise nicht vorhanden, und verlassen Sie sich nicht darauf, dass ein Schlüssel mit einem null-Wert vorhanden ist.

• Der Adapter postet mit dem Zielursprung *, sodass die Nachricht an die Seite gesendet wird, auf der der iFrame eingebettet ist. Der Adapter schränkt nicht ein, wer die Ereignisse empfangen kann. Ihr Listener sollte event.origin mit dem Host Ihres Mandanten (z. B. https://tenant.loc.ccaiplatform.com) vergleichen und Nachrichten von anderen Ursprüngen ignorieren, damit ein anderer iFrame auf derselben Seite keine Adapterereignisse fälschen kann.

• Bei type-Werten wird die Groß-/Kleinschreibung berücksichtigt und sie sind nicht einheitlich formatiert. Die meisten sind Title_Case (New_Call, End_Chat). Einige sind kleingeschrieben (call_redaction_started, call_redaction_ended, agent_assist_added) oder in camelCase (openThirdPartyPage). Vergleichen Sie sie mit den genauen Strings in diesem Dokument.

• Ereignisse werden nur gepostet, wenn der Adapter eingebettet ist (das übergeordnete Fenster ist ein anderes Fenster). Wenn der Adapter als Seite auf oberster Ebene geöffnet wird, wird nichts gepostet.

Das folgende Beispiel zeigt einen minimalen Listener, der diese Regeln anwendet:

// Replace with the origin of your tenant.
const ADAPTER_ORIGIN = 'https://tenant.loc.ccaiplatform.com'

window.addEventListener('message', (event) => {
  if (event.origin !== ADAPTER_ORIGIN) {
    return
  }

  let message
  try {
    message = JSON.parse(event.data)
  } catch (e) {
    // Not an agent adapter event; another script on the page posted it.
    return
  }

  const { type, data = {} } = message
  switch (type) {
    case 'New_Call':
      // data.call_id, data.agent_id, data.queue_id, ...
      break
    case 'New_Chat':
      // data.chat_id, data.agent_id, data.queue_id, ...
      break
    case 'CRM_Record_Pop':
      // data.recordUrl
      break
    default:
      // Ignore event types you don't handle; new types may be added over time.
      break
  }
}, false)

Nachrichten an den Agentenadapter

Die Kommunikation erfolgt hauptsächlich in eine Richtung (vom Adapter zum Host), aber die Hostseite kann mit postMessage() eine kleine Anzahl von Befehlen an den Anrufadapter senden. Diese Nachrichten sind einfache Objekte (keine JSON-Strings) mit dem folgenden Schema:

iframe.contentWindow.postMessage({
  channel: '<channel name>',
  eventType: '<event type>'
}, ADAPTER_ORIGIN)

Die folgenden Befehle werden im api:redaction-Kanal unterstützt. Sie werden verwendet, um die Aufzeichnung für die Anrufbearbeitung auf der Hostseite zu pausieren und fortzusetzen.

eventType	Beschreibung
start_call_redaction	Pausieren Sie die Aufzeichnung des aktiven Anrufs, um die Schwärzung zu starten.
stop_call_redaction	Setzen Sie die Aufzeichnung des aktiven Anrufs fort, um die Entfernung zu beenden.

Wichtige Hinweise:

• Die Befehle werden nur ausgeführt, wenn die Anrufentfernung für den Mandanten aktiviert ist und ein aktiver Anruf vorliegt. Andernfalls protokolliert der Adapter, dass die Nachricht ignoriert wurde, und führt keine Aktion aus.

• Wenn der Adapter den Befehl ausführt, sendet er das entsprechende call_redaction_started- oder call_redaction_ended-Ereignis an den Host zurück, damit du bestätigen kannst, dass sich der Aufnahmestatus tatsächlich geändert hat.

• Übergeben Sie den Ursprung Ihres Mandanten immer als zweites Argument an postMessage() anstelle von *, damit der Befehl nicht an eine andere Seite übermittelt werden kann, wenn der iFrame navigiert wird.

• Der frühere crm:authority-Kanal mit den Ereignistypen redact_call:start und redact_call:stop wird vom benutzerdefinierten CRM-Adapter aus Gründen der Abwärtskompatibilität weiterhin akzeptiert. Für neue Integrationen sollte jedoch api:redaction verwendet werden.

Weitere Informationen finden Sie unter Anrufentfernung.

Daten für Ereignisse

• call_id: Dies ist eine Kennung für einen eingehenden Anruf mit IVR (Sprachdialogsystem).

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

• cobrowse_session_id: eine Kennung für eine Bildschirmfreigabesitzung. Eine Bildschirmfreigabe kann während eines Anrufs oder einer Chatsitzung gestartet werden.

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

• va_data_parameters: Alle in der Warteschlange konfigurierten Variablen, die an den virtuellen Agenten gesendet werden sollen. Dies ist nur für Ereignisse erforderlich, die den virtuellen Agenten betreffen. Optional.

• session_variable: Alle Variablen des virtuellen Agenten, die in der Nutzlast an die CCAI Platform gesendet werden. Optional.

• custom_sip_headers: Damit werden benutzerdefinierte SIP-Header aus eingehenden SIP-Anrufen im POST-Ereignisprotokoll angezeigt. Er ist 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten. Optional.

Agenten-IDs

• agent_id: Dies ist eine Kennung für einen Agenten.
• from_agent_id: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den ursprünglichen Agenten anzugeben.
• to_agent_id: Wird verwendet, wenn Anrufe oder Chats von einem KI-Agenten an einen anderen weitergeleitet werden, um den Ziel-KI-Agenten anzugeben.
• agent_custom_id: Dies ist eine Agenten-ID aus dem Nutzerprofil, sofern sie im Profil eingegeben wurde. Optional.
• from_agent_custom_id: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den ursprünglichen Agenten anzugeben.
• to_agent_custom_id: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den Zielagenten anzugeben.
• agent_email: die E-Mail-Adresse des Agenten.
• from_agent_email: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den ursprünglichen Agenten anzugeben.
• to_agent_email: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den Zielagenten anzugeben.

IDs für virtuelle Kundenservicemitarbeiter

• virtual_agent_id: Dies ist die ID-Nummer, die einem bestimmten virtuellen Agenten zugewiesen ist.

Warteschlangen-IDs

• queue_id: die Kennung für eine CCAI Platform-Warteschlange. Sie ist nur vorhanden, wenn der Anruf aus einer Warteschlange stammt.
• from_queue_id: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, um die ursprüngliche Warteschlange anzugeben.
• to_queue_id: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, 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 verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, um die ursprüngliche Warteschlange anzugeben.
• to_queue_path: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, um die Zielwarteschlange anzugeben.

Campaign ID

• campaign_id: Die CCAI Platform-Kampagnen-ID. Sie sind nur enthalten, wenn der Aufruftyp ein Kampagnenaufruf ist.
• campaign_name: ein CCAI Platform-Kampagnenname. Sie sind nur enthalten, wenn der Aufruftyp ein Kampagnenaufruf ist.

Meldung

• message: Ereignis, das angibt, dass eine neue Nachricht von einem Nutzer empfangen wurde, sowie der Inhalt der Nachricht.

Sitzungsarten

• session_type: ein CCAI Platform-Sitzungstyp.
• cobrowse_session_remote_control: Gibt den Status einer angeforderten Remote-Bildschirmfreigabesitzung 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: Teilnehmertyp – 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 initiiert 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 der Typ end_user ist.

Interaktions-/Sitzungstypen

Anruftypen

• Eingehende Sprachanrufe: Standard-PSTN-Anrufe.
• Eingehende Sprachanrufe (IVR über Mobilgeräte): Fallback-PSTN-Anrufe, die über das Mobile SDK getätigt werden.
• Eingehende Sprachanrufe (Mobilgeräte): Werden von Nutzern über ein installiertes Mobile SDK getätigt.
• Sprachrückruf (Web): Wird über das Web SDK initiiert.
• Eingehende Sprachanrufe (API): Über die API initiiert.
• Voice Scheduled (Mobilgeräte): Geplant mit einem installierten Mobile SDK.
• Voice Scheduled (Web): Geplant mit einem installierten Web SDK.
• Ausgehende Sprachanrufe: Von einem Agenten durch Wählen einer Nummer initiiert.
• Ausgehende Sprachanrufe (API): Über die API initiiert.
• Sprachkampagne: Wird über einen Outbound Dialer (Kampagne) initiiert.

Chattypen

• Messaging (WhatsApp): Über WhatsApp initiiert.
• Eingehende Nachrichten (SMS)
• Ausgehende Nachrichten (SMS)
• Ausgehende Nachrichten (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 initiiert.

Ereignistypen

Hier sind die Ereignistypen, die vom Agent-Adapter gepostet werden. Die Spalte type ist der genaue String, bei dem die Groß-/Kleinschreibung berücksichtigt wird und der im Feld type der Nachricht angezeigt wird.

Ereignis	type	Adapter
Agent login	Agent_Login	Beides
Neuer Anruf	New_Call	Anruf
Nutzer ist beigetreten	Consumer_Joined	Anruf
Anruf beenden	End_Call	Anruf
Anrufentfernung gestartet	call_redaction_started	Anruf
Anruf-Bearbeitung beendet	call_redaction_ended	Anruf
Neuer Chat	New_Chat	Chat
Chat beenden	End_Chat	Chat
Aktiver Chat	Active_Chat	Chat
Eingehende Chatnachricht	Chat_Inbound_Message	Chat
Ausgehende Chatnachricht	Chat_Outbound_Message	Chat
Formular gesendet	Form_Sent	Chat
Formular ausgefüllt	Form_Completed	Chat
Geschlossener Chat	Dismissed_Chat	Chat
Bildschirmfreigabe-Sitzung gestartet	Cobrowse_Session_Started	Beides
Fernsteuerung der Bildschirmfreigabesitzung geändert	Cobrowse_Session_Remote_Control_Changed	Beides
Screen Share session full device changed	Cobrowse_Session_Full_Device_Changed	Beides
Bildschirmfreigabe beendet	Cobrowse_Session_Ended	Beides
Übertragen	Transfer_Call, Transfer_Chat	Beides
Party hinzugefügt	Party_Added	Beides
Agent verbindet sich mit der Sitzung	Agent_Joined_Call, Agent_Joined_Chat	Beides
Agent logout (Agentenabmeldung)	Agent_Logout	Beides
Agent Assist hinzugefügt	agent_assist_added	Beides
Virtueller Task Assistant ist beigetreten	Task_VA_Joined	Beides
Virtueller Einrichtungsassistent hat die Sitzung verlassen	Task_VA_Left	Beides
Sitzungsvariablen für den virtuellen Aufgabenassistenten erhalten	Task_VA_Variables_Received	Beides
CRM-Datensatz-Pop-up	CRM_Record_Pop	Beides
Seite des Drittanbieters öffnen	openThirdPartyPage	Anruf

Der Listener sollte type-Werte ignorieren, die er nicht erkennt. Im Laufe der Zeit können neue Ereignistypen hinzugefügt werden. Der Adapter postet auch Nachrichten, die für andere CCAI Platform-Oberflächen bestimmt sind (z. B. wenn er im CCAI Platform-Agent-Desktop gehostet wird), die nicht Teil dieses Vertrags sind.

Anmeldung des KI-Agenten

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

Hier ein Beispiel für ein Agent_Login-Ereignis:

{
  "type": "Agent_Login",
    "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "[e-mail]",
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: die Agenten-ID

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

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

Neuer Anruf

Ein neues Anrufereignis tritt auf, wenn ein Agent einen Anruf annimmt. Dieses Ereignis enthält Informationen wie den Zeitpunkt des Anrufbeginns, den Kundenservicemitarbeiter, der den Anruf bearbeitet hat, und den Ursprung des Anrufs.

Hier ein Beispiel für ein New_Call-Ereignis:

{
  "type": "New_Call",
  "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "[e-mail]",
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "call_id": 103646,
    "session_type": "Voice Campaign (UJET)"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: die Agenten-ID

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

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

• queue_id: die Kennung der Warteschlange, von der der Aufruf stammt. Dieses Feld ist enthalten, wenn der Aufruf aus einer Warteschlange stammt. Optional.

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

• campaign_id: die Kennung der Kampagne. Dieses Feld ist in einem Kampagnenaufruf enthalten. Optional.

• campaign_name: der Name der Kampagne. Dieses Feld ist in einem Kampagnenaufruf enthalten. Optional.

• call_id: die Anrufkennung

• session_type: der Sitzungstyp

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

• va_data_parameters: Die Variablen, die in der Warteschlange konfiguriert sind, um an den virtuellen Agenten gesendet zu werden. Dieses Feld ist für Ereignisse enthalten, die den virtuellen Agenten betreffen. Optional.

• session_variable: Alle Variablen des virtuellen Agenten, die an die CCAI Platform gesendet werden. Optional.

• custom_sip_headers: Ermöglicht, dass benutzerdefinierte SIP-Header (Session Initiation Protocol) von eingehenden SIP-Anrufen im POST-Ereignisprotokoll 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten. Optional.

Nutzer ist beigetreten

Ein Ereignis vom Typ „Verbraucher beigetreten“ tritt bei einem Kampagnenanruf (Outbound-Dialer) auf, wenn der Datensatz des Verbrauchers aufgelöst wird und einen LCM-Schlüssel (List Campaign Manager) enthält. So kann die Hostseite den gewählten Kontakt in ihrem eigenen System suchen, bevor die restlichen Anrufdaten eintreffen. Dieses Ereignis wird nur für Kampagnenanrufe gepostet, deren Kontakt einen LCM-Schlüssel hat.

Hier ein Beispiel für ein Consumer_Joined-Ereignis:

{
  "type": "Consumer_Joined",
  "data": {
    "lcmKey": "acqueon:12345",
    "custom_sip_headers": {
      "X-Account-Id": "A-100"
    },
    "va_data_parameters": {
      "param1": "one"
    },
    "session_variable": {
      "key_one": "value"
    }
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• lcmKey: der List Campaign Manager-Schlüssel des angerufenen Kontakts

• custom_sip_headers: Benutzerdefinierte SIP-Header aus dem Anruf. Dieses Feld ist enthalten, wenn benutzerdefinierte SIP-Header verwendet werden. Optional.

• va_data_parameters: Die in der Warteschlange konfigurierten Variablen, die an den virtuellen Agenten gesendet werden sollen. Optional.

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

Anrufentfernung gestartet

Ein Ereignis „Anrufentfernung gestartet“ tritt auf, wenn eine Anrufentfernung gestartet wurde und nicht aufgezeichnet wird. Die Ereignisdaten bestehen aus der ID des KI-Agenten, der den Anruf bearbeitet hat, und der Anruf-ID.

Beachten Sie, dass der type dieses Ereignisses kleingeschrieben wird: call_redaction_started.

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

Hier ist ein Beispiel für ein Ereignis, das den Beginn einer Anrufentfernung kennzeichnet:

{
  "type": "call_redaction_started",
  "data": {
    "agent_id": 2896,
    "call_id": 97939
  }
}

Anrufentfernung beendet

Das Ereignis „Anrufentfernung beendet“ tritt auf, wenn eine Anrufentfernung beendet und die Aufzeichnung fortgesetzt wurde. Dieses Ereignis besteht aus der ID des Kundenservicemitarbeiters, der den Anruf bearbeitet hat, und der call ID.

Beachten Sie, dass der type dieses Ereignisses kleingeschrieben wird: call_redaction_ended.

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

Hier ist ein Beispiel für Ereignisdaten, wenn die Anrufausblendung beendet wurde:

{
  "type": "call_redaction_ended",
  "data": {
    "agent_id": 2896,
    "call_id": 97939
  }
}

Anruf beenden

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

Hier ein Beispiel für ein End_Call-Ereignis:

{
  "type": "End_Call",
  "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "[e-mail]",
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "call_id": 103646,
    "session_type": "Voice Campaign (UJET)"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: die Agenten-ID

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

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

• queue_id: die Kennung der Warteschlange, von der der Aufruf stammt. Dieses Feld ist enthalten, wenn der Aufruf aus einer Warteschlange stammt. Optional.

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

• campaign_id: die Kennung der Kampagne. Dieses Feld ist in einem Kampagnenaufruf enthalten. Optional.

• campaign_name: der Name der Kampagne. Dieses Feld ist in einem Kampagnenaufruf enthalten. Optional.

• call_id: die Anrufkennung

• session_type: der Sitzungstyp

• virtual_agent_id: die Kennung des virtuellen Agenten. Dieses Feld ist für Ereignisse enthalten, die den virtuellen Agenten betreffen. Optional.

• va_data_parameters: Die Variablen, die in der Warteschlange konfiguriert sind, um an den virtuellen Agenten gesendet zu werden. Dieses Feld ist für Ereignisse enthalten, die den virtuellen Agenten betreffen. Optional.

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

• custom_sip_headers: Ermöglicht, dass benutzerdefinierte SIP-Header (Session Initiation Protocol) von eingehenden SIP-Anrufen im POST-Ereignisprotokoll 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Neuer Chat

Ein neues Chatereignis tritt auf, wenn ein Kundenservicemitarbeiter eine Chatsitzung übernimmt. Dieses Ereignis gibt an, wann der Chat gestartet wurde, und enthält Informationen wie den Agenten, der den Chat bearbeitet hat, und den Ursprung des Chats.

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": "[e-mail]",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• chat_id: die Chat-ID

• session_type: der Sitzungstyp

• agent_id: die Agenten-ID

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

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

• queue_id: die Kennung der Warteschlange, von der der Aufruf stammt. Dieses Feld ist enthalten, wenn der Aufruf aus einer Warteschlange stammt. Optional.

• queue_path: der Pfad der Warteschlange, von der der Aufruf 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Chat beenden

Ein Ereignis „Chat beenden“ tritt auf, wenn eine Chatsitzung beendet wird. Dieses Ereignis gibt an, wann der Chat beendet wurde, und enthält Informationen wie den Kundenservicemitarbeiter, 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": "[e-mail]",
    "queue_id": null,
    "queue_path": null,
    "agent_custom_id": null
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• chat_id: die Chat-ID.

• session_type: der Sitzungstyp.

• agent_id: die Agentenkennung.

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

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

• queue_id: die Kennung der Warteschlange, von der der Aufruf stammt. Dieses Feld ist enthalten, wenn der Aufruf aus einer Warteschlange stammt. Optional.

• queue_path: der Pfad der Warteschlange, von der der Aufruf 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Aktiver Chat

Ein aktives Chatereignis tritt auf, wenn der Kundenservicemitarbeiter im Chatadapter zu einem Chattab wechselt.

Hier 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": "[e-mail]",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• chat_id: die Chat-ID

• session_type: der Sitzungstyp

• agent_id: die Agenten-ID

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

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

• queue_id: die Kennung der Warteschlange, von der der Aufruf stammt. Dieses Feld ist enthalten, wenn der Aufruf aus einer Warteschlange stammt. Optional.

• queue_path: der Pfad der Warteschlange, von der der Aufruf 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Eingehende Chatnachricht

Ein Ereignis für eine eingehende Chatnachricht gibt an, dass eine neue Kundennachricht empfangen wurde. Sie enthält den Inhalt der Nachricht.

Für ein Ereignis vom Typ „Eingehende Chatnachricht“ werden Daten für die folgenden Felder gemeldet:

• chat_id: Identifiziert die Chatsitzung.

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

• agent_id: Identifiziert den Agenten, der die Chatsitzung bearbeitet.

• agent_custom_id: Dieses Feld ist nur vorhanden, wenn das Profil des KI-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 Nachrichteninhalt

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

• custom_data_not_secured: Ermöglicht die Übertragung ungesicherter benutzerdefinierter 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": "[e-mail]",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel",
    "message" : "Can you help me with my order tracking number?"
  }
}

Ausgehende Chatnachricht

Ein Ereignis für eine ausgehende Chatnachricht tritt auf, wenn eine neue Nachricht von einem Nutzer empfangen wird. Sie enthält den Inhalt der Nachricht.

Für das Ereignis „Ausgehende Chatnachricht“ werden Daten für die folgenden Felder gemeldet:

• chat_id: Identifiziert die Chatsitzung.

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

• agent_id: Identifiziert den Agenten, 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: Ereignis, das angibt, dass eine neue Nachricht von einem Nutzer empfangen wurde, plus Nachrichteninhalt

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

• custom_data_not_secured: Ermöglicht die Übertragung ungesicherter benutzerdefinierter 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": "[e-mail]",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Ariel",
    "message" : "Please give me a moment to look up your account information"
  }
}

Formular gesendet

Ein Ereignis vom Typ „Formular gesendet“ tritt auf, wenn dem Nutzer während einer Chatsitzung ein Formular gesendet wird. Beide Ereignisse werden vom Chat-Adapter gepostet, wenn der Chat die entsprechende Systemnachricht empfängt.

Hier ein Beispiel für ein Form_Sent-Ereignis:

{
  "type": "Form_Sent",
  "data": {
    "chat_id": 73522,
    "session_type": "Messaging Inbound (Web Chat)",
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "[e-mail]",
    "end_user_id": 5512,
    "form_external_id": "payment-details",
    "form_name": "Payment details",
    "form_type": "secure",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Kim",
    "queue_language_id": "en",
    "timestamp": 1727853575000
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• chat_id: die Chat-ID

• session_type: der Sitzungstyp

• agent_id: die Agenten-ID

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

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

• end_user_id: die Kennung des Nutzers im Chat. Optional.

• form_external_id: die externe Kennung des gesendeten Formulars. Optional.

• form_name: Der Name des gesendeten Formulars. Optional.

• form_type: Der Typ des gesendeten Formulars. Optional.

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

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

• queue_language_id: die Sprache der Warteschlange. Optional.

• timestamp: der Zeitpunkt, zu dem das Ereignis gepostet wurde, in Millisekunden seit der Unix-Epoche

• va_data_parameters: Die in der Warteschlange konfigurierten Variablen, die an den virtuellen Agenten gesendet werden sollen. Optional.

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

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

• custom_data_not_secured: Enthält unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten. Optional.

Formular ausgefüllt

Ein Ereignis „Formular ausgefüllt“ tritt auf, wenn der Nutzer ein Formular einreicht, das während einer Chatsitzung gesendet wurde. Die Ereignisdaten enthalten dieselben Felder wie das Ereignis Formular gesendet.

Hier ein Beispiel für ein Form_Completed-Ereignis:

{
  "type": "Form_Completed",
  "data": {
    "chat_id": 73522,
    "session_type": "Messaging Inbound (Web Chat)",
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "[e-mail]",
    "end_user_id": 5512,
    "form_external_id": "payment-details",
    "form_name": "Payment details",
    "form_type": "secure",
    "queue_id": 7678,
    "queue_path": "HB TEAM / Kim",
    "queue_language_id": "en",
    "timestamp": 1727853601000
  }
}

Geschlossener Chat

Ein Ereignis „Chat geschlossen“ 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":"[e-mail]"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• chat_id: die Chat-ID

• session_type: der Sitzungstyp

• agent_id: die Agenten-ID

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

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

• queue_id: die Kennung der Warteschlange, von der der Aufruf stammt. Dieses Feld ist enthalten, wenn der Aufruf aus einer Warteschlange stammt. Optional.

• queue_path: der Pfad der Warteschlange, von der der Aufruf 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Bildschirmfreigabe gestartet

Ein Ereignis vom Typ Bildschirmfreigabesitzung gestartet tritt auf, wenn eine Bildschirmfreigabesitzung von einem Kundenservicemitarbeiter oder einem Endnutzer gestartet wird. Eine Bildschirmfreigabe 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 beim Start einer Bildschirmfreigabe ausgelöst wird:

{
  "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"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: Die Agentenkennung.

• call_id: Die Kennung für einen eingehenden Anruf im IVR-Kanal (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 Bildschirmfreigabesitzung per Fern steuerung an. Mögliche Werte sind on, rejected, requested und off.

• cobrowse_session_full_device: Gibt den Status einer Bildschirmfreigabesitzung 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Fernbedienung für Bildschirmfreigabe geändert

Ein Ereignis zur Änderung der Fernsteuerung einer Bildschirmfreigabesitzung tritt auf, wenn sich der Status einer Bildschirmfreigabesitzung mit Fernsteuerung ändert. Dieses Ereignis gibt den Status der Bildschirmfreigabesitzung per Fernsteuerung 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"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: die Agentenkennung.

• call_id: Die Kennung für einen eingehenden Anruf im IVR-Kanal (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 Bildschirmfreigabesitzung per Fernsteuerung 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Bildschirmfreigabe für das gesamte Gerät geändert

Ein Ereignis vom Typ „Screen Share session full device changed“ tritt auf, wenn sich der Status einer Bildschirmfreigabesitzung für das gesamte 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"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: die Agentenkennung.

• call_id: Die Kennung für einen eingehenden Anruf im IVR-Kanal (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 Bildschirmfreigabesitzung 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Bildschirmfreigabe beendet

Ein Ereignis zum Start einer Bildschirmfreigabesitzung 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"
  }
}

Hier finden Sie Beschreibungen der Ereignisdatenfelder:

• agent_id: die Agentenkennung.

• call_id: Die Kennung für einen eingehenden Anruf im IVR-Kanal (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 Bildschirmfreigabe beendet hat. Mögliche Werte sind agent, end-user und api.

• cobrowse_session_remote_control: Gibt den Status einer Bildschirmfreigabesitzung per Fernsteuerung an. Mögliche Werte sind on, rejected, requested und off.

• cobrowse_session_full_device: Gibt den Status einer Bildschirmfreigabesitzung 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 unsignierte, benutzerdefinierte Daten von Ihrer Webseite. Weitere Informationen finden Sie unter Nicht signierte benutzerdefinierte Chatdaten (optional). Optional.

Übertragen

Ein Weiterleitungsereignis tritt auf, wenn ein Anruf oder Chat weitergeleitet wird. Es kann sich entweder um eine Weiterleitung mit oder ohne Rücksprache handeln.

Die folgenden Ereignisfelder sind Teil eines Übertragungsereignisses.

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

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

• campaign_id: die ID der Kampagne. Dieses Feld ist nur vorhanden, wenn der Aufruftyp ein Kampagnenaufruf ist. Optional.

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

• from_agent_id: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den ursprünglichen Agenten anzugeben.

• from_agent_custom_id: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den ursprünglichen Agenten anzugeben. Optional.

• from_agent_email: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den ursprünglichen Agenten anzugeben.

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

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

• to_agent_email: Wird verwendet, wenn Anrufe oder Chats von einem Agenten an einen anderen weitergeleitet werden, um den Zielagenten anzugeben.

• from_queue_id: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, um die ursprüngliche Warteschlange anzugeben.

• from_queue_path: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, um die ursprüngliche Warteschlange anzugeben.

• to_queue_id: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, um die Zielwarteschlange anzugeben.

• to_queue_path: Wird verwendet, wenn Anrufe oder Chats von einer Warteschlange an eine andere weitergeleitet werden, 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, um an den virtuellen Agenten gesendet zu werden. Dies ist nur für Ereignisse erforderlich, die den virtuellen Agenten betreffen. Optional.

• (session_variable: alle Variablen des virtuellen Kundenservicemitarbeiters, die in der Nutzlast an die CCAI Platform 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 geschützten benutzerdefinierten SDK-Daten. Optional.

• custom_data_not_secured: Ermöglicht die Übertragung ungesicherter benutzerdefinierter SDK-Daten. Optional.

Hier ein Beispiel für ein Übertragungsereignis:

{
  "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": "[e-mail]",
    "to_agent_id" : 5
    "to_agent_custom_id": "100"
    "to_agent_email" : "[e-mail]"
    "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 „Partei hinzugefügt“ bezieht sich auf jede Übertragung. Es kann sich entweder um eine Anruf- oder eine Chatweiterleitung handeln.

Ein Ereignis vom Typ „party added“ 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. eingehende Nachrichten über Webchat.

• agent_custom_id: Dieses Feld ist nur vorhanden, wenn das Profil des KI-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 Aufruftyp ein Kampagnenaufruf ist. Optional.

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

• type: der Teilnehmertyp, z. B. ein Endnutzer 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 Agenten an einen anderen weitergeleitet werden, um den Zielagenten 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, um an den virtuellen Agenten gesendet zu werden. Dies ist nur für Ereignisse erforderlich, die den virtuellen Agenten betreffen. Optional.

• session_variable: Alle Variablen des virtuellen Agenten, die in der Nutzlast an die CCAI Platform gesendet werden. Optional.

• custom_sip_headers: Damit 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 geschützten benutzerdefinierten SDK-Daten. Optional.

• custom_data_not_secured: Ermöglicht die Übertragung ungesicherter benutzerdefinierter 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": "[e-mail]",
    "queue_id": 8469,
    "queue_path": "Developers / Ariel",
    "type" : "agent"
  }
}

Kundenservicemitarbeiter verbindet sich mit der Sitzung

Ein Ereignis „Agent stellt Verbindung zu Sitzung her“ tritt auf, wenn ein Agent 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 ein Agent eine Verbindung zu einer Sitzung herstellt.

• agent_id: Identifiziert den Kundenservicemitarbeiter, 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 KI-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 Aufruftyp ein Kampagnenaufruf ist. Optional.

• campaign_name: der Name der Kampagne. Dieses Feld ist nur enthalten, wenn der Aufruftyp ein Kampagnenaufruf 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 Messaging-Sitzung über den Webchat.

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

• va_data_parameters: alle in der Warteschlange konfigurierten Variablen, die an den virtuellen Agenten gesendet werden sollen. Dies ist nur für Ereignisse erforderlich, die den virtuellen Agenten betreffen. Optional.

• session_variable: Alle Variablen des virtuellen Agenten, die in der Nutzlast an die CCAI Platform gesendet werden. Optional.

• custom_sip_headers: Damit 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 geschützten benutzerdefinierten SDK-Daten. Optional.

• custom_data_not_secured: Ermöglicht die Übertragung ungesicherter benutzerdefinierter 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": "[e-mail]",
    "queue_id": 8469,
    "queue_path": "Developers / Ariel",
    "session_type": "Messaging Inbound (SMS)",
  }
}

Agent-Abmeldung

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

Die folgenden Ereignisfelder sind Teil eines Agent_Logout-Ereignisses.

• agent_id: die Kennung des angemeldeten Agenten

• agent_email: die mit dem Agent-Konto verknüpfte E-Mail-Adresse

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

Hier ein Beispiel für ein Agent_Logout-Ereignis:

{
  "type": "Agent_Logout",
  "data": {
    "agent_id": 1,
    "agent_custom_id": "007",
    "agent_email": "[e-mail]",
  }
}

Agent Assist hinzugefügt

Ein Ereignis vom Typ „Agent Assist hinzugefügt“ tritt auf, wenn ein Kundenservicemitarbeiter Agent Assist während eines Anrufs oder Chats aktiviert.

Beachten Sie bei diesem Ereignis Folgendes:

• Der type dieses Ereignisses ist kleingeschrieben: agent_assist_added.

• Das Zeitstempelfeld heißt Timestamp (großes T) und ist die Anzahl der Millisekunden seit der Unix-Epoche.

Hier ein Beispiel für ein agent_assist_added-Ereignis:

{
  "type": "agent_assist_added",
  "data": {
    "conversation_id": "12345",
    "queue_id": 65,
    "agent_id": 1,
    "session_id": "78534G4RT4284",
    "queue_language_id": "en",
    "Timestamp": 1727853575000
  }
}

Hier sind die Ereignisfelder:

• conversation_id: die Unterhaltungs-ID. Dieses Feld ist enthalten, wenn die Sitzung ein Konversationsprofil verwendet. Optional.

• queue_id: die Warteschlangenkennung. Optional.

• agent_id: die Agenten-ID

• session_id: die Sitzungskennung. Optional.

• queue_language_id: die Sprache der Warteschlange. Optional.

• Timestamp: der Zeitpunkt, zu dem das Ereignis gepostet wurde, in Millisekunden seit der Unix-Epoche

Virtueller Taskassistent ist beigetreten

Ein Ereignis „Virtueller Aufgabenassistent ist beigetreten“ tritt auf, wenn ein virtueller Aufgabenassistent (VTA) einem Anruf oder einer Chatsitzung beitritt.

Hier ein Beispiel für ein Task_VA_Joined-Ereignis:

{
  "type": "Task_VA_Joined",
  "data": {
    "chat_id": 103646,
    "campaign_id": 1432,
    "campaign_name": "Survey Movie",
    "virtual_agent_id": 1,
    "virtual_agent_name": "Order status assistant",
    "participant_id": 1,
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "queue_language_id": "en",
    "session_type": "Messaging Inbound (SMS)",
    "conversation_id": "12345",
    "session_id": "78534G4RT4284",
    "timestamp": 1727853575000,
    "data_parameters": {
      "param1": "one",
      "param2": "two"
    }
  }
}

Hier sind die Ereignisfelder:

• call_id oder chat_id: die Anruf- oder Chat-ID

• campaign_id: die Kennung der Kampagne. Dieses Feld ist in einem Kampagnenaufruf enthalten. Optional.

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

• virtual_agent_id: die Kennung des VTA

• virtual_agent_name: Der Name des VTA, wie im CCAI Platform-Portal konfiguriert.

• participant_id: die Teilnehmer-ID des VTA in der Sitzung

• queue_id: die Kennung der Warteschlange, aus der die Sitzung stammt. Optional.

• queue_path: der Pfad der Warteschlange, aus der die Sitzung stammt. Optional.

• queue_language_id: die Sprache der Warteschlange. Optional.

• session_type: der Sitzungstyp

• conversation_id: die Unterhaltungs-ID. Dieses Feld ist enthalten, wenn für die Sitzung ein Konversationsprofil verwendet wird. Optional.

• session_id: die Sitzungskennung. Optional.

• timestamp: der Zeitpunkt, zu dem das Ereignis gepostet wurde, in Millisekunden seit der Unix-Epoche

• data_parameters: Die Variablen, die im CCAI Platform-Portal konfiguriert und an den VTA gesendet werden. Optional.

Virtueller Aufgabenassistent links

Ein Ereignis vom Typ „Virtueller Aufgabenassistent hat die Sitzung verlassen“ tritt auf, wenn der virtuelle Aufgabenassistent die Sitzung verlässt. Zusätzlich zu den Feldern des Ereignisses Virtual Task Assistant beigetreten enthält es den Grund für das Beenden der VTA-Sitzung und die vom VTA erfassten Sitzungsvariablen.

Hier ein Beispiel für ein Task_VA_Left-Ereignis:

{
  "type": "Task_VA_Left",
  "data": {
    "chat_id": 103646,
    "virtual_agent_id": 1,
    "virtual_agent_name": "Order status assistant",
    "participant_id": 1,
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "queue_language_id": "en",
    "session_type": "Messaging Inbound (SMS)",
    "conversation_id": "12345",
    "session_id": "78534G4RT4284",
    "timestamp": 1727853600000,
    "finish_reason": "Task VA completed",
    "data_parameters": {
      "param1": "one"
    },
    "captured_variables": [
      {
        "intent_name": null,
        "variables": {
          "order_number": "A-100"
        },
        "captured_at": "2024-11-15 16:46:31 UTC",
        "timestamp": 1727853590000
      }
    ]
  }
}

Die zusätzlichen Ereignisfelder sind:

• finish_reason: Der Grund, warum die VTA-Sitzung beendet wurde

• captured_variables: Die vom VTA erfassten Sitzungsvariablen, jeweils mit der Absicht, die sie erfasst hat, und dem Zeitpunkt, zu dem sie erfasst wurden. Optional.

Sitzungsvariablen für den virtuellen Aufgabenassistenten empfangen

Ein Ereignis „Sitzungsvariablen des virtuellen Aufgabenassistenten empfangen“ tritt jedes Mal auf, wenn der virtuelle Aufgabenassistent während der Sitzung eine benutzerdefinierte Nutzlast für Sitzungsvariablen sendet. Das Ereignis hat dieselben Felder wie das Ereignis Virtual Task Assistant left, mit Ausnahme von finish_reason. captured_variables enthält die bisher empfangenen Variablen.

Hier ein Beispiel für ein Task_VA_Variables_Received-Ereignis:

{
  "type": "Task_VA_Variables_Received",
  "data": {
    "chat_id": 103646,
    "virtual_agent_id": 1,
    "virtual_agent_name": "Order status assistant",
    "participant_id": 1,
    "queue_id": 8469,
    "queue_path": "Developers / Kim",
    "queue_language_id": "en",
    "session_type": "Messaging Inbound (SMS)",
    "conversation_id": "12345",
    "session_id": "78534G4RT4284",
    "timestamp": 1727853590000,
    "data_parameters": {
      "param1": "one"
    },
    "captured_variables": [
      {
        "intent_name": null,
        "variables": {
          "order_number": "A-100"
        },
        "captured_at": "2024-11-15 16:46:31 UTC",
        "timestamp": 1727853590000
      }
    ]
  }
}

Es werden nur Variablen berücksichtigt, deren capture_type den Wert event in der benutzerdefinierten Sitzungsvariablen-Nutzlast des virtuellen Agenten enthält. Schlüssel, die in invisible_to_adapter_events aufgeführt sind, werden ausgeschlossen.

Pop-up-Fenster im Hintergrund

Mit der Screen-Pop-Funktion können Kundendienstmitarbeiter im Hintergrund ein CRM-Screen-Pop ausführen. Das bedeutet, dass Kundendaten auf dem Bildschirm des Kundendienstmitarbeiters angezeigt werden, ohne dass dieser etwas tun muss. Das sorgt für einen reibungsloseren Ablauf für Kunden und reduziert die Bearbeitungszeit für Kundenservicemitarbeiter.

CRM-Datensatz-Pop-up

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

Hier ein Beispiel für ein CRM_Record_Pop-Ereignis:

{
  "type": "CRM_Record_Pop",
  "data": {
    "recordUrl": "https://crm.example.com/tickets/4711"
  }
}

Das Ereignis hat ein einzelnes Feld:

• recordUrl: die URL des anzuzeigenden CRM-Eintrags

Im folgenden Beispiel wird gezeigt, wie Sie einen Event-Listener hinzufügen, der auf Nachrichten von einem anderen Frame oder Fenster wartet. Dieses Code-Snippet soll die Kommunikation zwischen verschiedenen Frames oder Fenstern ermöglichen und dynamische Aktualisierungen der im iFrame angezeigten Inhalte basierend auf empfangenen Nachrichten ermöglichen.

// Replace with the origin of your tenant.
const ADAPTER_ORIGIN = 'https://tenant.loc.ccaiplatform.com'

// name is the html property of the iframe that shows the CRM record
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) => {
  // Only accept events posted by the agent adapter.
  if (e.origin !== ADAPTER_ORIGIN) {
    return
  }

  let message
  try {
    message = JSON.parse(e.data)
  } catch (err) {
    // Not an agent adapter event.
    return
  }

  const { type, data = {} } = message
  console.log('EventListener: ', type)

  switch (type) {
    case 'CRM_Record_Pop': {
      const recordUrl = data.recordUrl
      if (!recordUrl) {
        return
      }
      console.log(`Opening recordUrl in iframe ${iframeTarget.getAttribute('name')}`)

      // changing an iframe target to the record URL pop
      iframeTarget.src = recordUrl
      break
    }
    case 'New_Chat':
      console.log('Chat started...')
      // handling here for New_Chat events
      break
    case 'End_Chat':
      console.log('Chat ended...')
      // handling here for End_Chat events
      break
    default:
      // code handling for other types
      break
  }
}, false)

Seite des Drittanbieters öffnen

Das Ereignis openThirdPartyPage wird vom Anrufadapter gepostet, wenn ein Anruf einen Drittanbieterschlüssel enthält (z. B. einen List Campaign Manager-Schlüssel bei einem Kampagnenanruf) und der Adapter die entsprechende Drittanbieterseite öffnen möchte. Wenn Sie eingebettete Adapter verwenden, können Sie dieses Ereignis abonnieren, um die Seite stattdessen in Ihrer eigenen Benutzeroberfläche zu öffnen.

Hier ein Beispiel für ein openThirdPartyPage-Ereignis:

{
  "type": "openThirdPartyPage",
  "data": {
    "thirdPartyKey": "acqueon:12345",
    "callId": 103646
  }
}

Hier sind die Ereignisfelder:

• thirdPartyKey: der mit dem Aufruf verknüpfte Drittanbieterschlüssel

• callId: die Anrufkennung