Gestion des données

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 CXone, et de travailler avec les données qui se trouvent dans CXone. La manière dont vous utilisez les données dans les scripts Studio ou les API a une incidence sur votre système et 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. Les opérations de traitement des données qui ne sont pas liées aux contacts doivent être effectuées en dehors de Studio. Studio n’est pas conçu pour traiter de grandes quantités de données, il est donc soumis à une limite 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 agents au quotidien afin d’identifier d’éventuels problèmes tels que des pauses excessivement longues ou non programmées.

Solution inadaptée : Créer un script Studio programmé pour s’exécuter chaque jour. 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 des agents ont pris une pause de plus de 30 minutes qui n’était pas programmée. Il recherche également les pauses d’une durée excessive, par exemple 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étenceFermé Utilisé pour automatiser la livraison des interactions en fonction des compétences, des capacités et des connaissances des agents 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 locataireFermé Regroupement organisationnel de haut niveau utilisé pour gérer le support technique, la facturation et les paramètres globaux de votre CXone environnement 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 peut s’exécuter sur une longue période, ce qui sollicite beaucoup les ressources.

  • Il vaut mieux confier cette tâche aux ingénieurs, qui pourront utiliser les API 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. En traitant les données sur un serveur externe, vous pouvez obtenir des métriques plus utiles.


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.

L’une des méthodes pour résoudre cette tâche consiste à utiliser Python sur un serveur AWS, qui offre davantage de puissance de traitement. À 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. Placez les données dans une table ou, éventuellement, une matrice. Une table de base de données est préférable si vous souhaitez comparer et analyser plus facilement les données par la suite. 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.

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.

  1. Authentifier :
    1. Effectuez la découverte d’authentification afin d’obtenir un lien jeton. Le jeton résultant peut être mis en cache.
    2. Demandez un jeton à partir du point de terminaison de jeton découvert à l’étape précédente :
      1. Créez une demande POST vers https://cxone.niceincontact.com/auth/token avec un corps x-www-form-urlencoded.
      2. Récupérez les cinq paires clé-valeur, comme votre client_secret et votre client_id.
  2. Effectuer la découverte de point de terminaison de l’API :
    1. Commencez par extraire le tenantId du jeton renvoyé à l’étape 1 ci-dessus.
    2. Effectuez une demande GET vers https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={VOTRE ID DE 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. Extract the "area" and "domain" fields from the reply.
    4. Construct a base URI in the form of: https://api-{area}.{domain}.

  3. Créez un mappage de liste d’appels à l’aide de POST /lists/call-lists .

    Cette API crée une liste d’appels identifiée par un {listId}. Chaque appel met à jour le mappage de données entre les noms de colonne source et les champs 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 les valeurs sous forme de paramètres de requête, puis fournir un corps JASON avec une matrice 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 trouverez les noms de champs définis par CXone dans cette aide en ligne. Les valeurs des champs correspondent aux noms des colonnes dans les données source à mapper au champ CXone.

    Voici un exemple de demande POST : https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue} avec un corps JSON. La valeur renvoyée devrait être un code 200 avec un corps de réponse :

    {
	"listId": 0
}

  4. Chargez les données de liste d’appels à l’aide de POST /lists/call-lists/{listId}/upload  avec le listId créé à l’étape 3. Le listId est indiqué dans le chemin de l’appel d’API et les données de liste d’appels sont fournies dans le corps de la requête.

    Le format du fichier est un détail important. Le paramètre listFile correspond aux données de liste d’appels sous forme de fichier codé en base64.

    Vous pouvez aussi choisir de lancer la compétence numéroteur à l’issue du chargement en définissant l’indicateur "startSkill" sur "true" dans le corps de la requête.

    Voici un exemple de demande POST : 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 des données client de son CRM pour les afficher dans son application d'agent. Dans Studio, ils commencent par capturer une information de base permettant d’identifier le contact, comme un numéro de compte. Ensuite, le script effectue une demande GET au CRM, pour vérifier si l’information renvoie à un dossier client. S’il existe un dossier, toutes les données client sont renvoyées. The Jungle ne souhaite pas afficher toutes les données client, mais l’API ne permet pas de spécifier les données à renvoyer.

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. Ainsi, The Jungle peut respecter la limite de 32 Ko de données.

Mode Push ou interrogation

D’une manière générale, il est judicieux d’utiliser une architecture de type 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. L’opération s’effectue souvent en temps réel, selon les besoins ; par exemple pour un contact actif particulier. 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. Si vous avez utilisé l’API /get-next-event dans un script pour écouter (ou interroger) le client de l’agent et détecter un événement de mise en attente, vous bloquez un thread en permanence. Il est plus judicieux de pousser les données dans une seule instance pour éviter d’utiliser constamment des ressources serveur. Dans de tels cas, par exemple pour des intégrations CRM, au lieu d’attendre une demande pour renvoyer des données, effectuez un appel d’API qui pousse les données et libère le thread. Ensuite, utilisez l’API Signal  pour renvoyer les données au script. Vous pouvez aussi effectuer un appel d’API pour voir si cette demande a abouti et, si c’est le cas, envoyer les données.

Traitement de grandes quantités de données

Si vous voulez gérer de grands ensembles de données, comme les données historiques de la totalité de votre centre de contact, utilisez les API CXone . À grande échelle, il est possible d’utiliser Snowflake pour extraire toutes les données de votre unité commerciale. 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 n’ont pas de très grandes quantités de données, ou les organisations qui souhaitent trouver des métriques précises, peuvent concevoir de petites applications pour des tâches comparables. Il est possible, par exemple, de concevoir une application qui envoie des e-mails aux gestionnaires si leurs collaborateurs passent trop de temps dans un état donné.

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 aussi vous reporter à l’exemple présenté plus haut, qui évite de transférer une quantité excessive de données client d’un CRM dans Studio.

  • Filtrage des réponses d’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 sur un dossier, certaines API de CRM permettent de spécifier avec exactitude les champs d’information voulus. 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. Ce logiciel intermédiaire peut recevoir les données avant Studio, ce qui vous permet de filtrer le superflu et de transmettre les données voulues à Studio.

  • Filtrage des réponses d’API par période :

    Si une API permet de filtrer les données par période, utilisez cette fonctionnalité pour réduire la quantité de données. Pour obtenir les données d’une journée ou d’une semaine particulière, veillez à filtrer la réponse de manière à inclure uniquement les données de la période voulue.

  • Filtrage des données pour des contacts particuliers :

    Studio n’est pas un outil de gestion des données, mais 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 avez un compte Snowflake, vous pouvez transférer les données de votre centre de contact de CXone à Snowflake à l’aide de Studio. NICE stocke vos données pendant 24 mois, et vous pouvez les récupérer sur Snowflake. Vous pouvez aussi utiliser Services de stockage dans le cloud pour stocker des fichiers tels que des enregistrements d’appels ou transcriptions de chat, ou les transférer sur vos propres serveurs. Pour plus d’informations, contactez votre représentant de l’assistance CXone.

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.

  • Stockage des informations de série d’appuis dans l’IVR dans des fichiers en vue d’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.

  • Stockage de fichiers sur CXone Stockage en ligne. Si vous utilisez Stockage en ligne, veillez à prendre connaissance de tous les paramètres relatifs au stockage. Vous pouvez vous reporter à l’aide de Stockage en ligne ou contacter un représentant de l’assistance.

Appels d’API à partir de Studio

Les API vous permettent de travailler avec les données de manière efficace. 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 : permet d’ajouter du code personnalisé à vos scripts. 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 prend du temps, le thread est bloqué pendant toute cette durée et cela peut amoindrir la performance 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 d’API REST en utilisant moins de ressources. 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 fichier JSON, il peut être nécessaire d’utiliser l’action SNIPPET à la place. Selon la tâche que vous effectuez, vous devrez peut-être combiner cette action avec SNIPPET, car SNIPPET peut effectuer certaines opérations, comme la préparation des charges utiles.

  • ConnectAuth : authentifie un connecteur créé dans Integration Hub. Integration Hub : est une source centralisée pour la construction, la gestion et l’exécution des intégrations de CXone avec des plateformes tierces. Cette action ne bloque pas de threads.

  • ConnectRequest : déclenche une demande Integration Hub après avoir été authentifié. Cette action ne bloque pas de threads.

Autres actions Studio 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. Voici la liste complète de ces actions : 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 un temps limité, déterminé par la configuration de la propriété TTL hrs (Time-to-Live, durée de vie) de l’action PUTVALUE. La valeur par défaut est 24 heures, mais elle peut être comprise entre 1 h et 168 h (sept jours). Vous pouvez utiliser l'action REMVALUE pour supprimer les données avant l'heure TTL. Cela vous donne un contrôle total sur les données 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 consultées 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 tout au long de la vie du script qui définit ces variables. Les variables sont automatiquement supprimées une fois qu'elles sont libérées.
  • Ces actions sont limitées à 1 000 éléments dans la « liste ». Chaque élément, ou donnée, est limité à 5 Ko.