Aller au contenu
Screen pop natif dans l'Agent Desktop SSCV2 : ce que le PDF ne vous dit pas
Implementation · ·4 min de lecture

Screen pop natif dans l'Agent Desktop SSCV2 : ce que le PDF ne vous dit pas

Spadoom

Spadoom

SAP CX Partner & Consultancy

Partager

Ce mois-ci, nous avons fait passer notre widget de téléphonie d’un panneau latéral personnalisé au screen pop natif de l’Agent Desktop de SAP Sales and Service Cloud V2. Un appel arrive, l’agent voit l’appelant, le bon espace de travail s’ouvre, et quand l’appel se termine, la session se termine. Simple sur le papier. La partie intéressante, c’était tout ce que la documentation officielle ne dit pas.

Trois leçons nous sont restées.

Le silence est le pire des messages d’erreur

Le shell de l’Agent Desktop et le widget CTI communiquent par des événements postMessage du navigateur, et la charge utile doit être du XML. Pas du JSON, du XML, en 2026. Envoyez le même contenu en JSON et la réaction du shell est : rien du tout. Pas d’erreur, pas de ligne de log. Votre adaptateur se croit intégré ; le shell croit que personne n’a appelé. Ce silence nous a coûté un après-midi qu’une simple réponse d’erreur aurait transformé en dix minutes.

La leçon est générale : quand vous intégrez contre une boîte noire, prévoyez de l’observation, pas seulement de la lecture. Le contrat contre lequel vous livrez réellement est celui que vous mesurez, impressions prima vista comprises.

Un seul ID, partout, ou rien ne se corrèle

Toute la session repose sur un identifiant de référence externe qui doit être identique dans chaque message et dans l’activité d’appel du CRM. Laissez deux composants inventer chacun leur propre ID et vous obtenez le mode de défaillance le plus laid qui soit : la partie visible fonctionne, le nettoyage non, et à midi l’agent a un bureau plein de sessions zombies.

La discipline des ID est ennuyeuse, et c’est exactement pour cela qu’elle dérape. Générer une fois, transmettre, ne jamais régénérer.

Vous héritez du timing de l’autre système

Terminer une session ne fonctionne que lorsque le shell peut trouver l’activité d’appel, et l’index de recherche derrière cette requête accuse quelques secondes de retard sur la réalité. Envoyez l’au revoir trop tôt et il tombe dans le vide ; personne ne dit au revoir deux fois, donc la session vit pour toujours.

Notre correctif : laisser retomber, attendre que l’activité soit réellement trouvable, puis terminer, et terminer à nouveau si nécessaire. Élégant ? Non. Correct face au système tel qu’il se comporte réellement ? Oui. Quand vous intégrez contre un index, son timing devient le vôtre, que le PDF le mentionne ou non.

Et livrez derrière un flag

Nous avons déployé le mode natif tenant par tenant, derrière un flag. La téléphonie est l’intégration où chaque agent remarque chaque régression en quelques minutes. Un déploiement contrôlé n’est pas de la prudence pour la forme ; c’est ce qui nous a permis d’apprendre ces leçons sans faire chauffer le téléphone du support.

Si vous construisez vous-même contre l’Agent Desktop et observez un comportement qui contredit cet article, dites-le-nous. Ce contrat a été assemblé a posteriori, une surprise à la fois.

SAP Service Cloud V2Agent DesktopCTITéléphonieScreen PopIntégration
Etape suivante

SAP Service Cloud V2 partenaire d'implémentation

Spadoom est le partenaire d'implémentation SAP Service Cloud V2 en Suisse, Allemagne, Autriche et Italie. Médiane de go-live de 14 semaines. Clients en production dans tout le DACH.

Articles associes

Demandez a un expert