Actions de Données UCCE : Rôle et Comparaison avec les Recherches Externes

1. Le besoin de données externes : un rappel du contexte

Dans tout centre de contact, la capacité à accéder à des données en temps réel est fondamentale. On peut vouloir :

• Identifier un client à partir de son numéro de téléphone pour le saluer par son nom.
• Consulter son statut (par ex., VIP, client régulier) pour adapter le routage.
• Vérifier des informations comme le statut d'une commande ou le solde d'un compte.
• Présenter un contexte complet à l'agent (historique des interactions, informations du CRM) pour qu'il puisse traiter la demande plus efficacement.

Ces opérations nécessitent que le système de téléphonie "sorte" de sa logique interne pour interroger une source de données externe.

2. La méthode Cisco UCCE : une base de comparaison

Avec votre expérience sur Cisco UCCE, vous savez que ces intégrations existent mais sont souvent mises en place via différentes briques techniques. Un appel arrivant sur la plateforme pouvait déclencher une recherche de données de plusieurs manières :

• Scripts ICM (Intelligent Contact Management) : Le script pouvait interroger une base de données externe via un nœud spécifique.
• Serveur CVP (Customer Voice Portal) : Le VXML (VoiceXML) exécuté sur le CVP pouvait faire des requêtes HTTP vers des services web ou des applications pour récupérer des données et les jouer à l'appelant.
• Application Gateway : Un composant permettant aux scripts ICM de communiquer avec des applications externes.

L'image ci-dessous, qui vous est sans doute familière, illustre un flux d'appel UCCE. Le point clé est l'interaction avec une "External Application" (étapes 4 et 5) pour enrichir la décision de routage.

Dans cet écosystème, l'intégration dépendait souvent de développements spécifiques, de la configuration de plusieurs serveurs (CVP, Application Gateway) et de technologies parfois hétérogènes (SOAP, accès direct à la base de données, etc.).

3. L'approche Genesys Cloud : les Data Actions

Genesys Cloud modernise et standardise cette approche avec un concept unifié : les Data Actions.

Une Data Action est un pont configurable, construit au sein de l'interface Genesys Cloud, qui permet d'appeler des services web externes basés sur la technologie API REST.

Pour commencer, regardez cette courte vidéo qui introduit ce qu'est une Data Action et son rôle.

Comme vous l'avez vu, une Data Action est une manière standardisée d'interroger :

• Les propres API de Genesys Cloud (pour des informations internes non disponibles directement dans Architect).
• Des CRM comme Salesforce ou Microsoft Dynamics.
• Des services cloud comme AWS (Amazon Web Services).
• Tout service web personnalisé (par exemple, le système d'information de votre entreprise).

Le schéma ci-dessous illustre où les Data Actions se situent dans l'écosystème Genesys Cloud.

4. Le rôle des Data Actions dans Architect et les Scripts d'agent

Concrètement, à quoi servent les Data Actions ? Leur utilité se manifeste principalement dans les deux domaines qui vous intéressent : les flux de routage et les scripts d'agent.

Pour avoir une vue d'ensemble des cas d'usage, lisez les exemples fournis dans la documentation de Genesys Cloud.

Comme vous l'avez lu, les cas d'usages sont très clairs :

• Dans un flux Architect :
  • Prise de décision de routage : Un appel entre, une Data Action récupère le statut du client depuis le CRM. Si le client est "VIP", le flux transfère l'appel vers la file d'attente prioritaire.
  • Personnalisation du SVI (IVR) : Le SVI demande un numéro de commande. Une Data Action vérifie le statut de cette commande et le SVI annonce à l'appelant "Votre commande a été expédiée hier".
• Dans un Script d'agent :
  • Affichage d'informations (Screen Pop) : L'appel est transféré à un agent. Le script d'agent exécute automatiquement une Data Action pour récupérer les détails du contact depuis le CRM et les affiche à l'agent avant même qu'il ne décroche.
  • Mise à jour de données : L'agent peut utiliser un bouton dans son script (par exemple, "Créer un ticket") qui déclenche une Data Action pour créer une nouvelle entrée dans un système de ticketing externe.

5. Comparaison directe : UCCE vs. Genesys Cloud

Pour résumer les différences, voici un tableau comparatif :

La grande différence est philosophique : Genesys Cloud propose une abstraction unifiée et native (les Data Actions) là où UCCE proposait une boîte à outils de composants à assembler. L'approche de Genesys Cloud est conçue pour être plus accessible aux administrateurs non-développeurs, tout en restant extrêmement puissante.

6. La flexibilité des Data Actions

Un dernier point important est la flexibilité des Data Actions. Genesys Cloud les propose en plusieurs "saveurs" pour s'adapter à différents scénarios d'intégration.

Regardez cette dernière partie de la vidéo pour découvrir les différentes options.

En résumé, vous disposez de :

• Intégrations natives (Salesforce, Zendesk, etc.) : Elles viennent avec des "Static Actions" prêtes à l'emploi (ex: Get Contact By Phone Number).
• Genesys Cloud Data Actions : Pour appeler les propres API de la plateforme.
• Web Services Data Actions : Le type le plus courant, pour appeler n'importe quelle API REST externe.
• AWS Lambda Data Actions : Pour une flexibilité ultime, permettant d'exécuter du code personnalisé sur AWS pour gérer des logiques complexes ou des formats non-standards (comme le XML/SOAP mentionné dans la vidéo).

Une limitation importante à noter : les Data Actions sont conçues pour manipuler des données. Elles ne peuvent pas être utilisées pour effectuer des actions sur une conversation en cours, comme transférer ou déconnecter un appel. Ces actions de contrôle se font via les briques natives d'Architect.

Conclusion

Aujourd'hui, nous avons posé les fondations conceptuelles de l'intégration de données dans Genesys Cloud.

Points clés à retenir :

• Les Data Actions sont le mécanisme standardisé et intégré de Genesys Cloud pour interroger des systèmes externes.
• Elles remplacent les mécanismes hétérogènes de recherche de données externes (data dips) que l'on trouve dans des environnements comme Cisco UCCE.
• Leur rôle principal est de récupérer ou de mettre à jour des données pour enrichir les flux Architect (routage, SVI) et les scripts d'agent (screen pop, actions).
• Elles sont basées sur les technologies web modernes (API REST, JSON), mais leur configuration est simplifiée via l'interface de Genesys Cloud.

Vous comprenez maintenant le "pourquoi" et le "quoi" des Data Actions. Vous êtes prêt à passer à l'étape suivante.

Prochaine leçon :

Pour pouvoir configurer une Data Action, il est indispensable de comprendre le langage qu'elle parle. La prochaine leçon sera une introduction aux concepts fondamentaux des API REST et du format de données JSON. Nous démystifierons ces termes pour que vous soyez parfaitement à l'aise avant de mettre les mains dans la configuration.