Gestion des données

Les centres d’appels traitent d’énormes quantités de données, qu’il s’agisse de données de rapports ou de listes d’appels. Il se peut que vous deviez transférer des données vers et depuis CXone et que vous deviez travailler avec des données au sein de CXone. La façon dont vous travaillez avec les données dans les scripts Studio ou les API a un impact sur les performances de votre système et la qualité de vos interactions. Cette page vous aide à gérer efficacement les données.

Le bon outil pour le bon travail

L’objectif principal de Studio est de contrôler le routage des contacts. Tout ce que vous faites dans un script Studio doit être axé sur le contact. Tout traitement de données dont vous avez besoin et qui n’est pas lié à un contact doit être effectué en dehors de Studio. Studio n’est pas conçu pour traiter de grandes quantités de données, et sa limite est donc de 32 ko. Cela suffit pour travailler avec des contacts et permet aux serveurs de fonctionner efficacement.

Vous trouverez ci-dessous une tâche qui nécessite une gestion des données, ainsi que deux exemples de réalisation de cette tâche.

Exemple de tâche : Analyser quotidiennement les données relatives aux agents afin d’identifier les problèmes potentiels tels que les pauses trop longues ou les pauses non programmées.

Solution inappropriée : Créer un script Studio programmé qui est exécuté tous les jours. Le script effectue d’abord des appels API pour obtenir la liste des agents pour la journée, puis l’historique de l’état des agents pour 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. Il recherche également les pauses manifestement longues, comme une pause de quatre heures pour aller aux toilettes. Le script détermine également quels agents ont passé le plus de temps dans un état d’indisponibilité et quels agents ont passé le plus de temps sur 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 inappropriée :

  • Cette tâche n’est pas axée sur un seul contact; Studio n’est pas l’outil adéquat pour ce travail.

  • Studio n’est pas destiné à traiter de grandes quantités de données et 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 pour votre environnement CXone peut subir des problèmes de performance, car une grande quantité de données en mémoire entraîne une mauvaise performance du serveur.

  • Studio a une limite de données de 32 ko. Cette méthode vous oblige à diviser les données en petites quantités pour rester en deçà de cette limite. Par conséquent, le script peut être exécuté pendant une longue période, ce qui nécessite beaucoup de ressources.

  • Cette tâche est mieux résolue par des ingénieurs qui peuvent utiliser les API CXone, plutôt qu’un script Studio.

  • Studio fonctionne mieux en identifiant des informations telles que l’agent qui a passé le plus de temps dans un certain état ou qui a traité le moins d’appels. Le traitement des données sur un serveur externe vous permet de produire des métriques plus utiles.


Solution appropriée : Il ne s’agit que d’une méthode potentielle pour résoudre la tâche. Les solutions pour vos scénarios peuvent nécessiter une approche différente.

L’une des méthodes pour résoudre cette tâche consiste à utiliser Python sur un serveur AWS, qui offre une plus grande puissance de traitement. Depuis le serveur, effectuez les mêmes appels API pour obtenir la liste des agents et l’historique de leurs états pour la journée. Placez les données dans un tableau ou une grille. 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 être exprimées en mégaoctets, ce qui n’est pas un problème pour une base de données, mais dépasse la limite de données dans Studio. Vous pourriez avoir en mémoire l’historique complet des états de chaque agent; vous pourriez travailler sur l’ensemble des données en un seul endroit au lieu de petits morceaux de données dans un script Studio.

Vous pouvez maintenant commencer à travailler avec les données pour produire les métriques souhaitées, comme une liste ordonnée d’agents basée sur le temps passé dans certains états. Une base de données vous permet de présenter ces données comme vous l’entendez, plutôt que de vous soumettre aux contraintes d’un script Studio.

Les instructions suivantes sont un exemple des étapes et des appels API que vous pouvez effectuer pour créer une nouvelle liste d’appels avec des mappages de colonnes définis.

  1. Authentifier :
    1. Effectuez la découverte de l’authentification pour acquérir un lien de jeton. Le jeton obtenu peut être mis en cache.
    2. Demandez un jeton au terminal de jeton découvert à l’étape précédente :
      1. Créez une requête 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 vos client_secret et client_id.
  2. Effectuez la découverte des terminaux API :
    1. Extrayez le tenantId du jeton obtenu à l’étape 1 ci-dessus.
    2. Envoyez une requête GET à 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 en utilisant POST /lists/call-lists .

    Cette API crée une liste d’appels identifiée par un {listId}. Chaque appel met à jour le mappage des données des noms de colonnes source vers les champs CXone. En général, vous ne devez le faire que lorsque les en-têtes de colonne des données changent. 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. Ceux-ci sont utilisés pour mapper les données téléversées à l’étape 4 ci-dessous.

    Vous trouverez les noms de champs définis par CXone ici dans l’aide en ligne. Les valeurs de champ sont les noms des colonnes des données source à mapper avec le champ CXone.

    Un exemple POST serait : https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue} avec un corps JSON. Le retour attendu est un code 200 avec un corps de réponse :

    {
	"listId": 0
}

  4. Téléversez les données de la liste d’appels en utilisant POST /lists/call-lists/{listId}/upload  avec le listId créé à l’étape 3. Le listId est spécifié dans le chemin d’accès de l’appel API et les données réelles de la liste d’appels sont fournies dans le corps de la demande.

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

    Vous pouvez également choisir de lancer la compétence de compositoin à la fin du téléversement en définissant l’indicateur "startSkill" sur "true" dans le corps de la demande.

    Un exemple POST serait : https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload.

Pendant les appels actifs, le centre d’appels de The Jungle souhaite extraire des données sur les clients de son CRM et les afficher dans leur application d’agent. Dans Studio, ils saisissent d’abord les informations d’identification de base du contact, comme un numéro de compte. Ensuite, le script envoie une demande GET à leur CRM pour vérifier si les informations correspondent à un enregistrement de client. Si un enregistrement existe, toutes les données relatives au client sont renvoyées. The Jungle ne souhaite pas afficher toutes les données du client, et l’API ne lui permet pas de spécifier ce qu’il faut renvoyer.

La solution consiste à créer un intergiciel entre Studio et le système CRM. L’API renvoie le JSON à l’intergiciel, qui analyse les informations client souhaitées. Elle transmet ensuite les détails à Studio. Cela permet également à The Jungle de rester dans la limite des 32 ko de données.

Technologie du pousser ou d’interrogation

En général, il est préférable d’utiliser une architecture basée sur la technologie du pousser. Attendre que quelque chose se produise en effectuant une interrogation coûte naturellement des ressources, alors que les données peuvent être poussées à la demande; cela ne consomme pas de ressources lorsque ce n’est pas nécessaire. La poussée de données vous permet généralement de traiter de plus petits morceaux de données. La poussée de données est souvent effectuée pour des besoins de temps réel, par exemple pour un contact actif unique. L’interrogation est souvent utilisée pour les intégrations et ne peut pas être autant décomposée ou segmentée.

Par exemple, vous souhaitez peut-être mettre à jour l’interface utilisateur de l’agent lorsqu’il met un appel téléphonique en attente. Si vous utilisez l’API /get-next-event dans un script pour écouter (ou interroger) l’événement de mise en attente du client de l’agent, cette option bloquerait constamment un fil. Il est préférable de transmettre les données dans une seule instance afin d’éviter l’utilisation constante des ressources du serveur. Dans des cas similaires, par exemple avec les intégrations CRM, au lieu d’attendre le retour d’une demande, faites un appel API qui transmet les données et libère le fil. Ensuite, utilisez l’API Signal pour renvoyer les données au script. Vous pouvez également lancer un appel API pour vérifier si la demande est terminée et, dans l’affirmative, envoyer les données.

Traiter de grandes quantités de données

Si vous souhaitez traiter de grands ensembles de données, comme les données historiques de l’ensemble de votre centre d’appels, utilisez les API CXone ou Partage de données CXone. À grande échelle, vous pouvez utiliser Snowflake pour extraire toutes les données de votre unité commerciale; Partage de données CXone vous offre un pipeline direct pour les données de votre centre d’appels, de sorte que vous n’êtes pas limité à faire des appels API pour extraire des données. À plus petite échelle, l’exemple de tâche expliqué ci-dessus peut être optimal. Les petites entreprises qui ne disposent pas d’une grande quantité de données ou celles qui souhaitent trouver des métriques spécifiques peuvent créer de petites applications pour des tâches similaires. Par exemple, vous pouvez créer une application qui envoie des courriels aux gestionnaires dont les employés ont passé trop de temps dans un certain état.

Exemples pour éviter les grands ensembles de données dans les scripts

Les exemples suivants illustrent des scénarios courants dans lesquels vous pouvez éviter d’utiliser de grands ensembles de données dans vos scripts Studio. Vous pouvez également vous reporter à l’exemple ci-dessus, qui permet d’éviter de transférer trop de données client d’un CRM vers Studio.

  • Filtrer les réponses API par champ :

    Certaines API permettent de filtrer les informations renvoyées. Par exemple, si vous demandez à un système CRM de vous renvoyer des informations sur un cas, certaines API CRM vous permettent de spécifier exactement les champs d’information que vous souhaitez recevoir. Si l’API que vous utilisez offre cette fonctionnalité, vous pouvez éviter les grands ensembles de données en ne travaillant qu’avec les informations dont vous avez besoin. Si l’API d’un fournisseur ne dispose pas de cette fonctionnalité, vous pouvez travailler avec le fournisseur pour ajouter l’option, ou vous pouvez créer un intericiel. L’intergiciel peut recevoir les données avant Studio; vous pouvez filtrer ce qui n’est pas nécessaire, puis renvoyer les données à Studio.

  • Filtrer les réponses API par durée :

    Si une API vous permet de filtrer en fonction d’une durée, utilisez cette fonctionnalité pour minimiser la quantité de données. Si vous n’avez besoin que des données d’un jour ou d’une semaine, veillez à filtrer la réponse pour n’inclure que les données comprises dans cette plage de temps.

  • Filtrer les données pour les contacts individuels :

    Studio n’est pas un outil de gestion des données, mais un outil de gestion des contacts. Les capacités des actions Studio et Studio vous permettent de travailler avec des données principalement axées sur un contact individuel. Vous pouvez garder vos données spécifiques à des contacts individuels grâce à des techniques telles que la collecte d’informations par le biais d’un SRVI ou l’extraction de données CRM pour un seul enregistrement ou cas à la fois.

Stockage des données

Vous disposez de nombreuses options pour stocker les données. Si vous disposez d’un compte Snowflake, vous pouvez transférer les données de votre centre d’appels de CXone vers Snowflake en utilisant Studio. NICE stocke vos données pendant 24 mois, et vous pouvez les récupérer à partir de Snowflake. Vous pouvez également utiliser Services de stockage en nuage pour stocker des fichiers tels que des enregistrements d’appels ou des transcriptions de conversations, ou les déplacer vers vos propres serveurs. Contactez votre représentant du soutien CXone pour plus d’informations.

Coûts inattendus

En général, vous ne subirez pas de coûts supplémentaires en raison d’un trop grand nombre d’appels API ou d’une situation similaire. Cependant, la manière dont vous stockez certaines données peut engendrer des coûts. Voici quelques exemples de cas où un stockage inadéquat des données a entraîné des frais inattendus :

  • Créer de nombreuses variables de script et les stocker dans un fichier texte pour chaque contact sans inclure un processus de purge de ces fichiers.

  • Stocker les informations du chemin de pression IVR dans des fichiers en vue d’une utilisation ultérieure. Vous souhaitez peut-être utiliser ces informations à des fins de rapports à l’avenir.

  • Stockage des résultats de l’API dans un fichier qui s’enrichit continuellement au fur et à mesure que de nouveaux résultats sont ajoutés. Au fil du temps et de l’augmentation de la taille du fichier, cela génère des coûts de stockage.

  • Stockage de fichiers dans CXone Stockage en ligne. Si vous utilisez Stockage en ligne, assurez-vous de connaître les paramètres relatifs au stockage. Vous pouvez consulter le contenu de l’aide relatif à Stockage en ligne ou contacter un représentant du soutien.

Appels API à partir de Studio

Les API vous permettent de travailler efficacement avec les données. Vous pouvez effectuer des appels API à partir de Studio à l’aide des actions énumérées ci-dessous. La liste suivante explique les différences techniques entre les différentes actions :

  • SNIPPET : Vous permet d’ajouter un code personnalisé à un script. Vous pouvez utiliser cette action pour effectuer des appels API, préparer des charges utiles, analyser des objets de données dynamiques, etc. Lorsque vous effectuez des appels API avec cette action, méfiez-vous de la vitesse de réponse. Cette action utilise un fil pendant toute la durée de son activité. Si la réponse est lente, c’est-à-dire que le fil est bloqué pendant toute la durée de la réponse, cela peut avoir un impact négatif sur les performances du serveur. Par exemple, un appelant peut entendre un silence radio si tous les fils sont utilisés en même temps.

  • REST API : Vous permet d’effectuer des appels API REST et utilise moins de ressources serveur. Vous devriez utiliser cette action pour effectuer des appels API dans la mesure du possible, mais elle accepte spécifiquement JSON. Si une API ne renvoie pas de JSON, vous devrez peut-être utiliser l’action SNIPPET à la place. En fonction de votre tâche, vous devrez peut-être utiliser cette action en combinaison avec SNIPPET, car SNIPPET peut faire des choses telles que préparer les 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 d’intégrations de CXone vers des plateformes tierces. Cette action ne bloque pas les fils.

  • ConnectRequest : Déclenche une demande Integration Hub après avoir été authentifié. Cette action ne bloque pas les fils.

Autres actions Studio liées aux données

Studio comporte plusieurs actions qui stockent et récupèrent temporairement de petites quantités de données d’une table de base de données afin de les rendre accessibles à d’autres scripts. Ces actions se comportent comme 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 accessibles d’aucune autre manière. 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 la base de données pour une durée limitée, comme configuré dans la propriété TTL hrs (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 REMVALUEpour supprimer des 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 lorsqu’elles ne sont plus utilisées et à laisser le paramètre TTL à la valeur par défaut de 24 heures.

Remarques :

  • Si plusieurs variables doivent être accessibles à 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 sont limitées à 1 000 éléments dans la « liste ». Un élément unique, ou morceau de données, a également une limite de 5 ko.