Data Management

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. Vous devrez peut-être transférer des données vers et depuis NiCE CXone, et vous devrez peut-être travailler avec des données à l’intérieur de NiCE CXone. La façon dont vous travaillez avec les données dans les Scripts Studio ou les API a une incidence sur la performance de votre système et sur la qualité de vos interactions. Cette page vous aide à gérer les données efficacement.

Le bon outil pour le bon travail

L’objectif primaire de Studio est de contrôler l’acheminement 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 qui n’est pas lié au 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 est suffisant lorsque vous travaillez 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éez un script Studio programmé qui s’exécute tous les jours. Le script effectue d’abord des Appels API pour extraire la liste des agents du jour, puis extrait l’historique de l’état de l’agent 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 indisponible, et quels agents ont passé le plus de temps sur une compétenceClosed 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 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é au traitement de grandes quantités de données ; il est conçu pour la gestion des contacts. Votre locataireClosed 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. peut subir des problèmes de performance, car une grande quantité de données en mémoire entraîne une mauvaise performance des serveurs.

  • 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 pourrait s’exécuter pendant une longue période, ce qui exige beaucoup de ressources.

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

  • Studio fonctionne mieux en identifiant des informations comme un 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.


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

Une méthode pour résoudre cette tâche consiste à utiliser Python s’exécutant sur un serveur AWS, ce qui offre une plus grande puissance de traitement. À partir du serveur, effectuez les mêmes Appels API pour extraire la liste des agents et l’historique de l’état de l’agent pour la journée. Placez les données dans une table ou peut-être 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 représenter des mégaoctets, ce qui ne pose aucun problème pour une base de données, mais dépasse la limite de données dans Studio. Vous pourriez avoir l’historique complet des états de chaque agent en mémoire ; vous auriez l’ensemble de données complet en un seul endroit pour travailler, au lieu de petites parcelles de données dans un script Studio.

Vous pourriez maintenant commencer à travailler avec les données pour produire les métriques souhaitées, comme une liste ordonnée d’agents en fonction du temps passé dans certains états. Une base de données vous aide à présenter ces données comme bon vous semble, plutôt que dans les limites 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. Authenticate:
    1. Effectuez la découverte de l’authentification pour obtenir un lien de jeton. Le jeton obtenu peut être mis en cache.
    2. Request a token from the token endpoint discovered in the previous step:
      1. Créez une demande POST à 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. Perform API endpoint discovery:
    1. Extrayez tenantId du jeton retourné à l’étape 1 ci-dessus.
    2. Make a GET request to https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID}. Example reply: 
      {

	"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. Extrayez les champs « area » et « domain » de la réponse.
    4. Construisez une uri de base sous la forme suivante : https://API-{area}.{domain}.

  3. 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 des données des noms de colonnes sources vers les champs NiCE CXone. En général, vous ne devriez le faire que lorsque les en-têtes de colonnes des données changent. Pour cette API, vous devez définir les valeurs en tant que paramètres de requête, puis fournir un corps JSON contenant un tableau de paires destinationMappings, chacune étant composée d’un fieldName et d’une fieldValue. Celles-ci sont utilisées pour mapper les données téléversées à l’étape 4 ci-dessous.

    Vous pouvez trouver les noms de champs définis par NiCE CXone ici dans l’aide en ligne. Les valeurs de champ sont les noms de colonnes des données sources à mapper au champ NiCE CXone.

    Voici un exemple de POST : 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

}

  4. 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 correspond aux données de la liste d’appel sous forme de fichier encodé en base64.

    De plus, vous pouvez choisir de démarrer la compétence de composeur à la fin du téléversement en définissant l’indicateur « startSkill » à « true » dans le corps de la demande.

    Voici un exemple de 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 les données clients de son CRM et les afficher dans son application Agent. Dans Studio, ils capturent d’abord des informations d’identification de base sur le contact, comme un numéro de compte. Ensuite, le script effectue une demande GET à leur CRM, en vérifiant si l’information correspond à un dossier client. Si un dossier existe, il retourne toutes les données clients. The Jungle ne souhaite pas afficher toutes les données clients, et l’API ne lui permet pas de préciser ce qui doit être retourné.

Leur solution consiste à créer un intergiciel qui existe entre Studio et le CRM. L’API retourne le JSON à l’intergiciel, qui analyse les détails clients souhaités. Ensuite, il transmet les détails à Studio. Cela permet également à The Jungle de rester dans la limite de données de 32 Ko.

Technologie du pousser ou d’interrogation

En général, vous devriez utiliser une architecture basée sur la technologie du pousser. Attendre qu’un événement se produise par interrogation entraîne intrinsèquement une consommation de ressources, alors que le pousser des données se fait à la demande; il ne consomme pas de ressources lorsque cela n’est pas nécessaire. Le pousser des données permet généralement de traiter des blocs de données plus petits. Le pousser des données est souvent utilisé pour des besoins en temps réel, comme un contact actif unique. L’interrogation est souvent utilisée pour les intégrations et ne peut pas être aussi facilement décomposée ou Segment.

Par exemple, vous pourriez vouloir mettre à jour l’interface utilisateur de l’agent lors de la mise en attente d’un appel téléphonique. Si vous utilisiez l’API /get-next-event dans un script pour écouter (ou interroger) l’événement de mise en attente provenant du client agent, cela bloquerait constamment un thread. Vous voulez plutôt pousser les données en une seule instance afin d’éviter une utilisation constante des Ressources du 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 pousse les données et libère le thread. Ensuite, l’API Signal envoie les données de retour au script. Vous pourriez également effectuer un Appel API pour vérifier si cette demande est terminée et, si c’est le cas, envoyer les données.

Traiter 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 contacts, utilisez les API NiCE CXone ou NiCE CXone Data Share. À 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 contacts, de sorte que vous n'êtes pas limité à effectuer des Appels API pour extraire des données.

À plus petite échelle, la tâche exemple expliquée ci-dessus peut être optimale. Les Petites entreprises qui ne disposent pas d'une grande quantité de données ou celles qui souhaitent trouver des mesures spécifiques pourraient créer de petites applications pour des tâches similaires. Par exemple, vous pourriez créer une application qui envoie des courriels aux gestionnaires si leurs employés ont passé trop de temps dans un certain état.

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

Voici des exemples de scénarios courants où vous pouvez éviter d'utiliser de grands ensembles de données dans vos scripts Studio. Vous pouvez également consulter l'exemple ci-dessus, qui évite de transférer trop de données clients d'un CRM vers Studio.

  • Filtrer les réponses 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. Si l'API que vous utilisez offre cette fonctionnalité, vous pouvez éviter les grands ensembles de données en ne travaillant qu'avec exactement les informations dont vous avez besoin. Si l'API d'un vendeur n'offre pas cette fonctionnalité, vous pourriez vouloir collaborer avec le vendeur pour ajouter cette option, ou vous pouvez créer un intergiciel. L'intergiciel peut recevoir les données avant Studio, vous pouvez filtrer ce qui est inutile, puis renvoyer les données à Studio.

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

    Si une API vous permet de filtrer par une durée, utilisez cette fonctionnalité pour minimiser la quantité de données. Si vous avez seulement besoin des données d'une journée ou d'une semaine, assurez-vous de filtrer la réponse pour n'inclure que les données de cette plage horaire.

  • Filtrer les données pour les contacts individuels :

    Studio n'est pas un outil de gestion des données, c'est un outil de gestion des contacts. Les capacités de Studio et les actions Studio vous permettent de travailler avec des données principalement axées sur un contact individuel. Vous pouvez conserver vos données spécifiques aux contacts individuels à l'aide de techniques telles que la collecte d'informations par le biais d'un IVR ou l'extraction de données CRM pour un enregistrement ou un cas à la fois.

Stockage des données

Vous disposez de nombreuses options pour stocker les données. Si vous avez un compte Snowflake, vous pouvez déplacer les données de votre centre de contacts de NiCE CXone vers Snowflake à l'aide de Studio. NiCE stocke vos données pendant 24 mois, que vous pouvez récupérer à partir de Snowflake. Vous pouvez également utiliser Cloud Storage Services pour stocker des fichiers comme les enregistrements d'appels ou les 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 inattendus

En général, vous n'engagerez pas de coûts supplémentaires en effectuant trop d'Appels API ou quelque chose de similaire. Cependant, la façon dont vous stockez certaines données pourrait générer 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 sur le chemin de sélection IVR dans des fichiers pour une utilisation ultérieure. Vous souhaitez peut-être utiliser ces informations à des fins de rapports à l’avenir.

  • Stocker les résultats API dans un fichier qui s'agrandit continuellement à mesure que de nouveaux résultats sont ajoutés. Avec le temps, à mesure que le fichier grossit, cela génère des coûts de stockage.

  • Stocker des fichiers sur NiCE CXone Cloud Storage. Si vous utilisez Cloud Storage, assurez-vous de connaître tous les paramètres relatifs au stockage. Vous pouvez consulter le contenu d'aide pour Cloud Storage ou contacter un représentant du soutien.

Appels API depuis Studio

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

  • SNIPPET : Vous permet d'ajouter du 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, faites attention à la vitesse de réponse. Cette action utilise un thread pendant toute la durée de son activité. Si la réponse est lente, c'est-à-dire que le thread est bloqué pendant toute cette durée, cela peut nuire aux performances du serveur. Par exemple, un appelant peut entendre du silence si tous les threads sont utilisés en même temps.

  • REST API : Vous permet d'effectuer des appels REST API et utilise moins de ressources serveur. Vous devriez utiliser cette action pour effectuer des Appels API chaque fois que possible; toutefois, elle accepte spécifiquement le format JSON. Si une API ne renvoie pas de JSON, vous devrez peut-être utiliser l'action SNIPPET à la place. Selon votre tâche, vous devrez peut-être utiliser cette action en combinaison avec SNIPPET, puisque SNIPPET peut effectuer des tâches comme la préparation de charges utiles.

  • CONNECTAUTH : Authentifie un connecteur créé dans Integration Hub. Integration Hub est une source centralisée pour créer, gérer et exécuter des intégrations de NiCE CXone vers des plateformes tierces. Cette action ne bloque pas les threads.

  • CONNECTREQUEST : Déclenche une demande Integration Hub une fois qu'elle a été authentifiée. Cette action ne bloque pas les threads.

Autres actions Studio liées aux données

Studio dispose de 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 qui ne peut être consulté qu'à l'aide de cet ensemble d'actions Studio. 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 base de données pendant une période 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 dans vos scripts. La bonne pratique consiste à supprimer les valeurs lorsqu'elles ne seront plus utilisées et à laisser le TTL à sa valeur par défaut de 24 heures.

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 nettoyées une fois qu'elles sont libérées.
  • Ces actions ont une limite de 1000. éléments dans la « liste ». Un seul élément, ou une seule donnée, a également une limite de 5 Ko.