Data Management

Les centres de contact traitent des volumes de données colossaux, des données de reporting aux listes d’appels. Il peut vous être nécessaire de transférer des données à partir de et vers NiCE CXone, et de travailler avec les données qui se trouvent dans NiCE CXone. Votre manière de travailler avec les données dans les Studio Scripts ou les API a une incidence sur les performances de votre système et sur la qualité de vos interactions. Cette page vous aide à gérer les données de manière efficace.

Un outil adapté à la tâche

Studio a pour principale finalité de contrôler l’acheminement des contacts. Tout ce que vous faites dans un script Studio devrait être axé sur les contacts. Tout traitement de données dont vous avez besoin et qui n'est pas lié aux contacts doit être effectué en dehors de Studio. Studio n'est pas conçu pour traiter de grandes quantités de données ; il a donc une limite de données de 32 Ko. Cette limite est suffisante pour travailler avec les contacts et préserver le bon fonctionnement des serveurs.

Voici une tâche nécessitant de gérer des données, avec deux exemples de réalisation.

Exemple de tâche : Analyser les données des Agent au quotidien afin d'identifier des problèmes potentiels tels que des pauses excessivement longues ou des pauses non programmées.

Solution inappropriée : Créer un script Studio programmé qui s'exécute tous les jours. Dans un premier temps, le script effectue des appels d’API pour extraire la liste d’agents du jour, puis l’historique des états d’agent sur la journée. Le script vérifie ensuite si un Agent a pris une pause de plus de 30 minutes qui n'était pas programmée. Elle recherche également toute pause manifestement longue, comme une pause toilettes de quatre heures. Le script identifie aussi les agents qui ont passé le plus de temps dans un état indisponible, et ceux qui ont passé le plus de temps dans une compétence Utilisé pour automatiser la livraison des interactions en fonction des compétences, des aptitudes et des connaissances de l’agent. particulière.

Pourquoi cette méthode est mauvaise :

La tâche n’est pas axée sur un contact précis ; Studio n’est pas l’outil qui convient.
Studio n’est pas destiné à traiter de grands volumes de données, il est conçu pour la gestion des contacts. Votre locataire Regroupement organisationnel de haut niveau utilisé pour gérer le soutien technique, la facturation et les paramètres globaux de votre système NiCE CXone. risque de rencontrer des problèmes de performance, car une quantité importante de données en mémoire pèse sur le bon fonctionnement des serveurs.
Studio est soumis à une limite de 32 Ko. Cette méthode vous oblige à fragmenter les données afin de respecter la limite. Par conséquent, le script pourrait s'exécuter pendant une longue période, ce qui demande beaucoup de ressources.
Cette tâche est mieux résolue par l'ingénierie, qui peut utiliser les API NiCE CXone, plutôt qu'un script Studio.
Studio fonctionne de manière optimale en identifiant des informations précises, par exemple un agent qui a passé le plus de temps dans un état particulier ou qui a traité le plus petit nombre d’appels. Le traitement des données sur un serveur externe vous permet de produire des métriques plus précieuses.

Solution adaptée : il s’agit d’une méthode parmi d’autres pour résoudre la tâche. Dans votre situation, il peut être nécessaire de choisir une autre approche.

Une méthode permettant de résoudre cette tâche consiste à utiliser Python s'exécutant sur un serveur AWS, qui offre une puissance de traitement supérieure. À partir du serveur, effectuez les mêmes appels d’API pour extraire la liste d’agents et l’historique des états d’agents pour la journée. Insérez les données dans un tableau ou éventuellement dans un tableau. Une table de base de données serait préférable pour vous permettre de comparer et d'analyser plus facilement les données à l'avenir. Les données renvoyées pourraient atteindre plusieurs mégaoctets, ce qui ne pose aucun problème avec une base de données, mais dépasse la limite de données de Studio. Vous auriez en mémoire l’historique complet des états de tous les agents ; vous pourriez utiliser l’intégralité des données au même endroit, plutôt que d’avoir des fragments de données dans un script Studio.

Vous pourriez alors commencer à travailler avec les données afin de produire les métriques voulues, par exemple une liste des agents classés en fonction du temps passé dans certains états. Une base de données aide à présenter les données comme bon vous semble, plutôt que de composer avec les contraintes d’un script Studio.

Découvrez une méthode adaptée pour créer et mapper une liste d’appels dans NiCE CXone :

Ces instructions proposent un exemple des étapes à suivre et des appels d’API à utiliser pour créer une liste d’appels avec un mappage de colonnes défini.

Authenticate:
1. Effectuez la découverte de l'authentification pour obtenir un lien de jeton. Le jeton résultant peut être mis en cache.
2. Request a token from the token endpoint discovered in the previous step:
  1. Créez une demande POST vers https://cxone.niceincontact.com/auth/token avec un corps x-www-form-urlencoded.
  2. Récupérer les cinq paires clé-valeur, comme votre client_secret et client_id.
Perform API endpoint discovery:
1. Extrayez l'ID locataire du jeton renvoyé à l'étape 1 ci-dessus.
2. Effectuez une demande GET à https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={Id du locataire}. Exemple de réponse :
```
{
	"private": false,
	"area": "na1",
	"cluster": "B32",
	"domain": "niceincontact.com",
	"acdDomain": "nice-incontact.com",
	"uhDomain": "nice-incontact.com",
	"ui_endpoint": "https://na1.nice-incontact.com",
	"auth_endpoint": "https://na1.nice-incontact.com",
	"api_endpoint": "https://api-na1.niceincontact.com",
	"tenantId": "11eb0358-724b-3970-97e5-0242ac110003"
}
```
3. Extraire les champs "zone" et "domaine" de la réponse.
4. Construisez une uri DE base selon le format suivant : https://API-{surface}.{domain}.
Créez un mappage de liste d’appel à l’aide de POST /lists/call-lists .

Cette API crée une liste d’appel identifiée par un {listId}. Chaque appel met à jour le mappage de données entre les noms de colonne source et les champs NiCE CXone. En général, vous ne le faites que lorsque les en-têtes de colonne changent dans les données. Pour cette API, vous devez définir des valeurs en tant que paramètres de requête, puis fournir un corps JSON avec un tableau de paires destinationMappings, chacune étant composée d'un fieldName et d'un fieldValue. Ces éléments servent à mapper les données chargées à l’étape 4 ci-après.

Vous pouvez trouver ici, dans l'aide en ligne, les noms de champ définis par NiCE CXone. Les valeurs de champ sont les noms de colonne des données source à mapper au champ NiCE CXone.

Un exemple de POST serait : https://API-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue} avec un corps JSON. Le retour attendu serait un code 200 avec un corps de réponse :
```
{
	"listId": 0
}
```
Upload the calling list data using POST /lists/call-lists/{listId}/upload with the listId created in step 3. The listId is specified in the path of the API call and the actual calling list data is provided in the request body.
Un détail important est le format du fichier. Le paramètre listFile est les données de la liste d’appel sous la forme d’un fichier encodé en base64.
Par ailleurs, vous pouvez choisir de démarrer la compétence du composeur à la fin du téléchargement en définissant l'indicateur "startSkill" sur "true" dans le corps de la demande.
Un exemple de POST serait : https://API-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload.

Pendant les appels actifs, le centre de contact The Jungle souhaite extraire les données clients de leur CRM et les afficher dans leur application Agent. Dans Studio, ils capturent d'abord des informations d'identification de base à partir du contact, comme un numéro de compte. Ensuite, le script envoie une demande GET à leur CRM, afin de vérifier si les informations correspondent à un enregistrement client. Si un enregistrement existe, il renvoie toutes les données clients. The Jungle ne souhaite pas afficher toutes les données clients, et l'API ne leur permet pas de préciser ce qui doit être renvoyé.

Leur solution consiste à concevoir un logiciel intermédiaire entre Studio et le CRM. L’API renvoie le JSON au logiciel intermédiaire, qui analyse et extrait les données client voulues. Ensuite, les informations sont transmises à Studio. Cela permet également à The Jungle de rester dans la limite de données de 32 Ko.

Mode Push ou interrogation

En général, vous souhaitez utiliser une architecture basée sur le push. L’interrogation à répétition est coûteuse en ressources, alors qu’en mode Push, les données sont transmises à la demande. Aucune ressource n’est consommée si elle n’est pas nécessaire. En poussant les données, vous pouvez traiter des blocs de données plus petits. La transmission de données est souvent effectuée pour des besoins en temps réel, comme un seul contact actif. L’interrogation est souvent utilisée pour les intégrations et elle ne permet pas le même niveau de décomposition ou de segmentation.

Vous pouvez, par exemple, vouloir actualiser l’interface de l’agent lorsqu’il met un appel téléphonique en attente. If vous avez utilisé le /get-next-event API dans un script pour écouter (ou interroger) l'événement de mise en attente provenant du client agent, cela bloquerait constamment un thread. Il est plus judicieux de pousser les données dans une seule instance pour éviter d’utiliser constamment des ressources serveur. Dans des cas similaires, peut-être avec des intégrations CRM, au lieu d'attendre le retour d'une demande, effectuez un Appel API qui transmet les données et libère le thread. Ensuite, utilisez le signal API renvoie les données au script. Vous pourriez également effectuer un Appel API pour vérifier si cette demande est terminée et, si oui, envoyer les données.

Traitement de grandes quantités de données

Si vous souhaitez gérer de grands ensembles DE données, comme les données historiques de l'ensemble de votre centre de contact, utilisez les NiCE CXone API ou NiCE CXone Data Share. Sur une grande échelle, vous pouvez utiliser Snowflake pour extraire toutes les données de votre unité commerciale; Data Share vous offre un pipeline direct pour les données de votre centre de contact, de sorte que vous n'êtes pas limité à effectuer des Appels API pour extraire des données.

Sur une échelle plus réduite, l’exemple de tâche présenté ci-dessus peut se révéler optimal. Les petites entreprises qui ne disposent pas d'un volume important de données, ou les entreprises qui souhaitent trouver des Metrics spécifiques, peuvent créer de Petites applications pour des tâches similaires. Par exemple, vous pouvez créer une application qui envoie des e-mails aux responsables s'ils ont des employés ayant passé trop de temps dans un certain état.

Exemple – Éviter les grands Ensembles DE données dans les scripts

Les exemples qui suivent présentent des cas de figure où il est possible d’éviter d’utiliser des grands ensembles DE données dans les scripts Studio. Vous pouvez également vous reporter à l'exemple ci-dessus, qui évite de transférer trop de données clients d'un CRM vers Studio.

Filtres des réponses de l'API par champ :

Certaines API offrent la possibilité de filtrer les informations renvoyées. Par exemple, si vous demandez à un CRM de renvoyer des informations pour un cas, certaines API CRM vous permettent de préciser exactement quels champs d'informations vous souhaitez obtenir en retour. Si l’API que vous utilisez offre cette fonctionnalité, vous pouvez éviter d’utiliser des grands ensembles DE données simplement en travaillant avec les données dont vous avez vraiment besoin. Si une API ne propose pas cette fonctionnalité, il est judicieux de demander à l’éditeur de l’API d’ajouter cette option. Sinon, vous pouvez concevoir un logiciel intermédiaire. Le middleware peut recevoir les données avant Studio, vous pouvez filtrer ce qui est inutile, puis renvoyer les données à Studio.
Filtres des réponses API par période :

Si une API vous permet de filtrer par une durée, utilisez cette fonctionnalité pour minimiser la quantité de données. Si vous n'avez besoin que des données d'une journée ou d'une semaine, veillez à filtrer la réponse pour inclure uniquement les données comprises dans cette plage horaire.
Filtre des données pour des contacts individuels :

Studio n'est pas un outil de gestion des données, c'est un outil de gestion des contacts. Grâce aux capacités de Studio et des actions Studio, vous pouvez travailler avec des données qui concernent principalement un contact particulier. Pour cibler les données des différents contacts, vous pouvez notamment recueillir des informations par le biais d’un IVR ou en extrayant les données CRM d’un seul dossier.

Stockage de données

Vous disposez de plusieurs options pour stocker les données. Si vous disposez d'un compte Snowflake, vous pouvez déplacer les données de votre centre de contact de NiCE CXone vers Snowflake à l'aide de Studio. NiCE stocke vos données pendant 24 mois, que vous pouvez récupérer depuis Snowflake. Vous pouvez également utiliser le Cloud Storage Services pour stocker des fichiers tels que des enregistrements de l’appel ou des transcriptions du clavardage, ou les déplacer vers vos propres serveurs. Contactez votre représentant de compte NiCE CXone pour plus d'informations.

Coûts imprévus

En général, vous ne subirez pas de surcoût si vous effectuez un trop grand nombre d’appels d’API ou autre opération similaire. En revanche, les modalités de stockage de certaines données peuvent entraîner des frais. Voici quelques exemples où le stockage inadapté des données a abouti à la facturation de frais imprévus :

Création de nombreuses variables de script qui sont ensuite stockées dans un fichier texte pour chaque contact sans prévoir de processus pour purger ces fichiers.
Enregistrement chemin de frappe IVR informations dans des fichiers pour une utilisation ultérieure. par exemple pour compiler des rapports.
Stockage des résultats d’API dans un fichier qui s’accroît à mesure que les résultats sont ajoutés. Au fil du temps, comme le fichier devient plus volumineux, cela génère des coûts de stockage.
Storing files on NiCE CXone Cloud Storage. If you use Cloud Storage, be sure you're aware of any parameters around storage. You can reference the help content for Cloud Storage or contact a support representative.

Appels API depuis Studio

Les API vous permettent de travailler avec les données de manière efficace et performante. Vous pouvez effectuer des appels d’API à partir de Studio grâce aux actions répertoriées ci-dessous. La liste suivante explique ce qui différencie l’utilisation de ces actions d’un point de vue technique :

SNIPPET : Vous permet d'ajouter du code personnalisé à un script. Vous pouvez utiliser cette action pour effectuer des appels d’API, préparer des charges utiles, analyser des objets de données dynamiques, etc. Lorsque vous effectuez des appels d’API avec cette action, méfiez-vous de la vitesse de réponse. Cette action utilise un thread pendant toute la période où elle est active. Si la réponse est lente, ce qui signifie que le thread est bloqué pendant toute la durée, cela peut avoir un impact négatif sur les performances du serveur. Par exemple, un appelant pourra entendre des silences si tous les threads sont utilisés en même temps.
REST API : permet d'effectuer des appels REST API et utilise moins de ressources serveur. Il est recommandé d’utiliser cette action pour effectuer des appels d’API dès que possible ; cependant, elle accepte uniquement des fichiers JSON. Si une API ne renvoie pas de JSON, il peut être nécessaire d'utiliser l'action SNIPPET à la place. Selon votre tâche, il peut être nécessaire d'utiliser cette action en combinaison avec SNIPPET, car SNIPPET peut effectuer des opérations telles que la préparation de charges utiles.
CONNECTAUTH : authentifie un connecteur créé dans Integration Hub. Integration Hub est une source centralisée permettant de créer, gérer et exécuter des intégrations depuis NiCE CXone vers des plateformes tierces. Cette action ne bloque pas de threads.
CONNECTREQUEST : déclenche une demande Integration Hub après son authentification. Cette action ne bloque pas de threads.

Autres Studio Actions liées aux données

Studio propose plusieurs actions qui stockent temporairement et récupèrent de petites quantités de données dans une table de base de données pour qu’elles soient accessibles à d’autres scripts. Ces actions ont un comportement semblables à une liste de champs ou de valeurs. Utilisez-les pour stocker plusieurs valeurs ou des valeurs nécessaires plus loin dans d'autres scripts. La liste complète des actions est la suivante : PUTVALUE, GETVALUE, REMVALUE, GETLIST, et CLEARLIST.

Ces actions utilisent un type de données unique accessible uniquement à l'aide de cet ensemble deStudio Actions. Les données ne sont pas accessibles autrement. Les utilisateurs ne peuvent pas accéder à cette base de données et l'utiliser, quelles que soient leurs autorisations.

Les valeurs sont répertoriées dans une table de base de données pendant une durée limitée, telle que configurée dans la propriété TTL en heures (durée de vie) de l'action PUTVALUE.La valeur par défaut est de 24 heures, mais elle peut varier d'une heure à 168 heures (sept jours). Vous pouvez utiliser l'action REMVALUE pour supprimer des données avant l'expiration du TTL.Cela vous donne un contrôle complet sur les données au sein de vos Scripts. La meilleure pratique consiste à supprimer les valeurs qui ne vont plus servir et à conserver la durée de vie TTL par défaut (24 h).

Remarques :

Si plusieurs variables doivent être accessibles par d'autres Scripts ou contacts, une base de données est généralement la meilleure solution.
Les variables publiques non persistantes peuvent être partagées par d'autres scripts ou contacts pendant toute la durée de vie du script qui définit ces variables. Les variables sont automatiquement supprimées une fois qu'elles sont libérées.
Ces actions ont une limite de 1 000 éléments dans la « liste ».