Datenverwaltung

In einem Contact Center müssen große Datenmengen bewältigt werden, wie Berichtsdaten und Anruflisten. Möglicherweise müssen Sie Daten von und an CXone übertragen und innerhalb von CXone mit Daten arbeiten. Die Art und Weise, wie Sie mit Daten in Studio-Skripten oder -APIs arbeiten, wirkt sich auf die Leistung Ihres Systems und die Qualität Ihrer Interaktionen aus. Diese Seite hilft Ihnen, Daten effizient zu verwalten.

Das richtige Werkzeug für die jeweilige Aufgabe

Der Hauptzweck von Studio ist die Steuerung der Kontaktweiterleitung. Sämtliche Aufgaben, die Sie mit einem Studio-Skript durchführen, sollten sich auf die Kontaktverarbeitung beziehen. Datenverarbeitungsaufgaben, die nicht im Zusammenhang mit Kontakten stehen, sollten außerhalb von Studio erledigt werden. Studio ist nicht für die Verarbeitung von großen Datenmengen vorgesehen. Es besteht ein Datenlimit von 32 KB. Dieses Limit ist für die Arbeit mit Kontakten ausreichend und sorgt für einen effizienten Betrieb der Server.

Die folgende Aufgabe erfordert eine Datenverwaltung und kann mit den beiden genannten Beispielen durchgeführt werden.

Beispielaufgabe: Agentendaten sollen täglich analysiert werden, um potenzielle Probleme wie sehr lange oder nicht geplante Pausen zu identifizieren.

Ungeeignete Lösung: Erstellen eines Studio-Skripts, das gemäß einem Zeitplan täglich ausgeführt wird. Das Skript tätigt zuerst API-Aufrufe, um die Agentenliste für den jeweiligen Tag und dann den Agentenstatusverlauf des Tages abzurufen. Anschließend überprüft das Skript, ob bestimmte Agenten eine nicht geplante Pause von mehr als 30 Minuten eingelegt haben. Außerdem überprüft es, ob sehr lange Pausen stattgefunden haben, wie vierstündige Kaffeepausen. Das Skript ermittelt auch, welche Agenten die längste Zeit in einem Status "nicht verfügbar" waren und welche Agenten die längste Zeit in einem bestimmten SkillGeschlossen Wird verwendet, um die Bereitstellung von Interaktionen basierend auf den Kompetenzen, Fertigkeiten und Kenntnissen der Agenten zu automatisieren verbracht haben.

Diese Methode ist aus den folgenden Gründen nicht geeignet:

  • Diese Aufgabe bezieht sich nicht auf einen einzelnen Kontakt. Studio ist nicht das richtige Werkzeug für die Aufgabe.

  • Studio ist nicht für die Verarbeitung großer Datenmengen vorgesehen, sondern für die Kontaktverwaltung. In Ihrem MandantenGeschlossen Eine übergeordnete organisatorische Gruppierung, die Sie für die technische Unterstützung und Abrechnung und außerdem zur Bearbeitung von globalen Einstellungen in Ihrer CXone Umgebung einsetzen können. können Leistungsprobleme auftreten, da große Datenmengen im Arbeitsspeicher die Serverleistung stark beeinträchtigen.

  • Studio hat ein Datenlimit von 32 KB. Bei dieser Methode können Sie das Limit nur einhalten, indem Sie die Daten in kleine Segmente aufteilen. Dadurch würde die Ausführung des Skripts möglicherweise sehr lange dauern und viele Ressourcen belegen.

  • Diese Aufgabe lässt sich besser mit CXone-APIs anstelle eines Studio-Skripts bewältigen.

  • Studio eignet sich am besten dazu, bestimmte Informationen zu ermitteln, beispielsweise welcher Agent die längste Zeit in einem bestimmten Status verbracht hat oder die geringste Anzahl von Anrufen bearbeitet hat. Durch die Verarbeitung der Daten auf einem externen Server können Sie aussagekräftigere Metriken generieren.


Gut geeignete Lösung: Dies ist nur eine der möglichen Methoden zum Lösen dieser Aufgabe. Für Ihre spezifischen Szenarien sind möglicherweise andere Vorgehensweisen erforderlich.

Eine Methode zum Lösen dieser Aufgabe besteht darin, Python auf einem AWS-Server auszuführen, wodurch mehr Verarbeitungsleistung zur Verfügung steht. Tätigen Sie auf dem Server dieselben API-Aufrufe zum Abrufen der Agentenliste und des Agentenstatusverlaufs für den jeweiligen Tag. Platzieren Sie die Daten in einer Tabelle oder in einem Array. Eine Datenbanktabelle ist am besten geeignet, da Sie damit die Daten in Zukunft einfach vergleichen und analysieren können. Die zurückgegebenen Daten können ein Volumen von mehreren MB haben. Eine Datenbank kann diese Menge problemlos bewältigen, aber in Studio würde das Datenlimit überschritten. Bei dieser Vorgehensweise kann sich gesamte Statusverlauf für alle Agenten im Arbeitsspeicher befinden und der vollständige Datensatz befindet sich an einem zentralen Ort. Sie müssen also nicht wie bei einem Studio-Skript mit kleinen Datensegmenten arbeiten.

Jetzt können Sie auf Basis Ihrer Daten die gewünschten Metriken generieren, wie beispielsweise eine Liste, in der die Agenten in der Reihenfolge der Dauer aufgeführt werden, die sie in einem bestimmten Status verbracht haben. Eine Datenbank bietet Ihnen die Möglichkeit, diese Daten nach Bedarf darzustellen, ganz ohne die Einschränkungen eines Studio-Skripts.

Das Jungle Contact Center möchte bei aktiven Anrufen Kundendaten aus dem CRM-System abrufen und in der Agent-Anwendung anzeigen. In Studio werden zunächst grundlegende Informationen zur Identifikation vom Kontakt erfasst, wie eine Kontonummer. Dann sendet ein Skript eine GET-Anforderung an das CRM-System, um zu überprüfen, ob die Informationen mit einem Kundendatensatz übereinstimmen. Wenn ein Datensatz vorhanden ist, werden alle Kundendaten zurückgegeben. Es sollen nicht alle Kundendaten angezeigt werden, aber in der API kann nicht festgelegt werden, welche Daten zurückgegeben werden sollen.

Die Lösung besteht darin, eine Middleware zwischen Studio und dem CRM-System einzurichten. Die API gibt den JSON-Inhalt an die Middleware zurück, die die gewünschten Kundendetails herausfiltert. Dann werden die Details an Studio übergeben. So kann auch das Datenlimit von 32 KB eingehalten werden.

Push und Poll (übertragen und abfragen)

Im Allgemeinen empfiehlt sich eine Push-Architektur. Bei der Poll-Methode muss darauf gewartet werden, bis etwas passiert, was zwangsläufig Ressourcen belegt. Im Gegensatz dazu erfolgt ein Push von Daten nur bei Bedarf, sodass andernfalls keine Ressourcen beansprucht werden. Beim Pushen von Daten können Sie normalerweise mit kleineren Datensegmenten arbeiten. Das Pushen von Daten wird häufig für Echtzeitanforderungen verwendet, wie für einen einzelnen aktiven Kontakt. Das Pollen kommt meist bei Integrationen zum Einsatz. Die Daten können dabei nicht so gut aufgeschlüsselt oder segmentiert werden.

Angenommen, die Benutzeroberfläche des Agenten soll aktualisiert werden, wenn der Agent einen Telefonanruf in die Warteschleife stellt. Wenn Sie die /get-next-event -API in einem Skript verwenden, um auf das Warteschleifen-Ereignis vom Agenten-Client zu lauschen (oder dieses abzufragen), wird dauerhaft ein Thread blockiert. Stattdessen sollten Sie die Daten in einer einzelnen Instanz per Push übertragen, damit die Serverressourcen nicht kontinuierlich belegt werden. In ähnlichen Szenarien, beispielsweise bei CRM-Integrationen, können Sie einen API-Aufruf tätigen, um Daten per Push zu übertragen und den Thread freizugeben. Auf diese Weise müssen Sie nicht darauf warten, dass die Anforderung zurückgegeben wird. Verwenden Sie dann die Signal-API , um die Daten an das Skript zurückzusenden. Sie können auch mit einem API-Aufruf überprüfen, ob diese Anforderung abgeschlossen ist, und die Daten senden, wenn dies der Fall ist.

Verarbeitung von großen Datenmengen

Wenn Sie große Datensätze verwalten möchten, wie historische Daten für das gesamte Contact Center, verwenden Sie CXone-APIs . In Szenarien mit sehr großen Datenmengen können Sie Snowflake verwenden, um alle Daten für Ihre Geschäftseinheit abzurufen. Bei kleineren Datenmengen ist die oben beschriebene Beispielaufgabe möglicherweise die beste Lösung. Kleinunternehmen, in denen keine großen Datenmengen anfallen, oder Unternehmen, die bestimmte Metriken benötigen, können kleine Apps für ähnliche Aufgaben entwickeln. Beispielsweise können Sie eine App erstellen, die E-Mails an Manager sendet, wenn Mitarbeiter zu viel Zeit in einem bestimmten Status verbringen.

Beispiele zum Vermeiden von großen Datensätzen in Skripten

Mithilfe der folgenden gängigen Lösungen können Sie große Datensätze in Ihren Studio-Skripten vermeiden. Im oben genannten Beispiel wird ebenfalls erläutert, wie Sie vermeiden können, dass zu viele Kundendaten von einem CRM-System an Studio übertragen werden.

  • Filtern von API-Antworten nach einem Feld:

    In einigen APIs können Sie mithilfe von Filtern festlegen, welche Daten zurückgegeben werden sollen. Wenn beispielsweise Informationen zu einem bestimmten Fall aus einem CRM-System angefordert werden, können Sie in einigen CRM-APIs genau angeben, welche Felder zurückgegeben werden sollen. Wenn Ihre API diese Funktionalität unterstützt, können Sie große Datensätze vermeiden, indem Sie genau die Informationen anfordern, die Sie benötigen. Wenn diese Funktionalität in der API Ihres Anbieters nicht enthalten ist, können Sie beim Anbieter nachfragen, ob die Funktion integriert werden kann. Andernfalls können Sie eine Middleware einrichten. Bevor die Daten an Studio gesendet werden, können sie die Middleware durchlaufen. Hier können die nicht benötigten Daten herausgefiltert werden, bevor die gewünschten Daten an Studio zurückgegeben werden.

  • Filtern von API-Antworten nach der Zeit:

    In manchen APIs können Sie die Daten nach der Zeit filtern und so die Datenmenge reduzieren. Wenn Sie nur Daten für einen bestimmten Tag oder eine Woche benötigen, filtern Sie die Antwort so, dass nur Daten für den jeweiligen Zeitraum enthalten sind.

  • Filtern von Daten für einzelne Kontakte:

    Studio ist kein Datenverwaltungstool, sondern ein Kontaktverwaltungstool. Die Funktionen von Studio und Studio-Aktionen sind hauptsächlich für die Arbeit mit Daten für einzelne Kontakte vorgesehen. Sie können verschiedene Techniken verwenden, um Daten für individuelle Kontakte zu erhalten. Beispielsweise können Sie Informationen über ein IVR-System erfassen oder CRM-Daten für jeweils einen Datensatz oder einen Fall abrufen.

Datenspeicher

Möglicherweise verfügen Sie über zahlreiche Optionen zum Speichern von Daten. Wenn Sie ein Snowflake-Konto haben, können Sie Ihre Contact Center-Daten mithilfe von Studio von CXone an Snowflake verschieben. NICE speichert Ihre Daten 24 Monate lang. In diesem Zeitraum können Sie sie aus Snowflake abrufen. Sie können auch die Cloud-Speicherdienste verwenden, um Dateien wie Anrufaufzeichnungen oder Chat-Transkripte zu speichern oder sie auf Ihre eigenen Server zu verschieben. Weitere Informationen erhalten Sie von Ihrem CXone-Supportberater.

Unerwartete Kosten

Im Allgemeinen fallen für Sie keine zusätzlichen Kosten für eine hohe Anzahl an API-Aufrufen oder ähnliche Tätigkeiten an. Kosten können jedoch dadurch entstehen, wie Sie bestimmte Daten speichern. Die folgenden Szenarien sind Beispiele dafür, wie eine unangemessene Datenspeicherung zu unerwarteten Gebühren führen kann:

  • Sie erstellen zahlreiche Skriptvariablen und speichern sie für jeden Kontakt in einer Textdatei, ohne dass ein Prozess zur Bereinigung dieser Dateien verwendet wird.

  • Sie speichern IVR-Press-Pfad-Informationen zur späteren Verwendung in Dateien. Vielleicht möchten Sie diese Informationen in Zukunft für die Berichterstellung verwenden.

  • Sie speichern API-Ergebnisse in einer Datei, die ständig größer wird, während neue Ergebnisse hinzugefügt werden. Während die Datei im Laufe der Zeit immer größer wird, fallen Speicherkosten an.

  • Sie speichern Dateien in CXone Cloud-Speicher. Wenn Sie Cloud-Speicher verwenden, ist es wichtig, alle Parameter in Bezug auf das Speichern zu berücksichtigen. Einzelheiten erhalten Sie in der Hilfe für Cloud-Speicher oder von einem Supportberater.

API-Aufrufe von Studio

Mithilfe von APIs können Sie auf effiziente und effektive Weise mit Daten arbeiten. Mithilfe der folgenden Aktionen können Sie API-Aufrufe in Studio ausführen. In der folgenden Liste werden die technischen Unterschiede bei Verwendung der verschiedenen Aktionen beschrieben:

  • SNIPPET: Hiermit können Sie einem Skript benutzerdefinierten Code hinzufügen. Mit dieser Aktion können Sie API-Aufrufe tätigen, Payloads vorbereiten, dynamische Datenobjekte parsen und vieles mehr. Bei API-Aufrufen mit dieser Aktion müssen Sie auf die Antwortgeschwindigkeit achten. Solange diese Aktion aktiv ist, nutzt sie einen Thread. Bei einer langsamen Antwort wird der Thread während des gesamten Zeitraums blockiert. Dies kann sich negativ auf die Serverleistung auswirken. Dies kann beispielsweise dazu führen, dass Anrufer nur Stille hören, wenn alle Threads gleichzeitig genutzt werden.

  • REST API: Hiermit können Sie REST-API-Aufrufe tätigen, wobei weniger Serverressourcen beansprucht werden. Sie sollten diese Aktion nach Möglichkeit immer für API-Aufrufe verwenden. Insbesondere ist sie jedoch für JSON vorgesehen. Wenn eine API keinen JSON-Code zurückgibt, müssen Sie stattdessen möglicherweise die SNIPPET-Aktion verwenden. Je nach Ihrer Aufgabe müssen Sie diese Aktion eventuell in Kombination mit SNIPPET verwenden, da SNIPPET bestimmte Funktionalität unterstützt und beispielsweise Payloads vorbereiten kann.

  • ConnectAuth: Authentifiziert einen Konnektor, der in Integration Hub erstellt wurde. Integration Hub ist eine zentralisierte Quelle zum Erstellen, Verwalten und Ausführen von Integrationen aus CXone in Plattformen von Drittanbietern. Mit dieser Aktion werden keine Threads blockiert.

  • ConnectRequest: Hiermit wird nach der Authentifizierung eine Integration Hub-Anforderung ausgelöst. Mit dieser Aktion werden keine Threads blockiert.

Andere Studio-Aktionen im Zusammenhang mit Daten

Studio enthält mehrere Aktionen, die vorübergehend kleine Datenmengen aus einer Datenbanktabelle abrufen und speichern, damit diese Daten in anderen Skripten zur Verfügung stehen. Diese Aktionen verhalten sich wie eine Liste mit Feldern oder Werten. Verwenden Sie sie zum Speichern mehrerer Werte oder von Werten, die in anderen Skripten weiter benötigt werden. Die vollständige Liste besteht aus diesen Aktionen: PUTVALUE, GETVALUE, REMVALUE, GETLIST und CLEARLIST.

Diese Aktionen verwenden einen eindeutigen Datentyp, auf den nur über diesen Satz von Studio Aktionen zugegriffen werden kann. Die Daten sind auf keine andere Weise zugänglich. Benutzer können nicht auf diese Datenbank zugreifen und sie verwenden, unabhängig von ihren Berechtigungen.

Die Werte werden für eine begrenzte Zeit in einer Datenbanktabelle aufgelistet, wie in der Eigenschaft TTL hrs (time to life, Lebensdauer) der PUTVALUE-Aktion konfiguriert. Der Standardwert ist 24 Stunden, er kann jedoch von einer Stunde bis 168 Stunden (sieben Tage) reichen. Sie können die REMVALUE-Aktion verwenden, um Daten vor der TTL-Zeit zu löschen. So haben Sie die vollständige Kontrolle über die Daten in Ihren Skripten. Es empfiehlt sich, die Werte zu löschen, wenn sie nicht mehr benötigt werden, und für TTL den Standardwert von 24 Stunden beizubehalten.

Hinweise:

  • Wenn mehrere Variablen von anderen Skripten oder Kontakten abgerufen werden müssen, ist eine Datenbank meist die beste Lösung.
  • Nicht dauerhafte öffentliche Variablen können während der Lebenszeit des Skripts, das diese Variablen setzt, auch von anderen Skripten oder Kontakten verwendet werden. Diese Variablen werden automatisch bereinigt, wenn sie freigegeben werden.
  • Für diese Aktionen gilt ein Höchstwert von 1.000 Elementen in der "Liste". Ein einzelnes Element oder Datensegment kann eine Größe von maximal 5 KB haben.