Vos données CX sont en silos par canal, et c'est pour ça qu'elles ne servent à rien.

Voix, mail, chat, réseaux sociaux : chaque canal produit sa propre version des faits. Tant que ces versions restent isolées, la donnée CX ne décrit pas un client. Elle décrit des fragments d’activité. On compte des appels, des tickets, des mentions. On ne voit ni la continuité, ni les reprises, ni les ruptures de parcours.

Un canal n’est pas un client

Le premier piège consiste à confondre l’activité d’un canal avec le comportement d’un client. Un même client peut appeler, puis écrire, puis relancer sur un réseau social. Si chaque outil garde son identifiant local, vous obtenez trois objets distincts. Le parcours se casse. La lecture devient mécanique, pas relationnelle.

Cette confusion fausse tout le pilotage. Un volume élevé dans un canal peut masquer une insatisfaction née ailleurs. Un ticket social peut être la suite d’un appel non résolu. Sans identité partagée, vous mesurez des points de contact, pas une trajectoire. Le client change de support, mais pas de problème. La donnée, elle, change de colonne.

Demandez à chaque éditeur : "Comment l’identité client est-elle reconnue d’un canal à l’autre, sans ressaisie ?" Demandez aussi : "L’identifiant est-il natif, synchronisé en temps réel, ou reconstruit après coup ?" Si la réponse passe par un rapprochement manuel, la continuité est déjà perdue. Si l’outil ne conserve qu’un identifiant par canal, le symptôme est simple : doublons, historiques incomplets, et impossibilité de reconstituer une séquence fiable.

Critère vérifiable : un même client doit être retrouvé avec le même identifiant logique dans tous les canaux, avec horodatage cohérent et historique consultable.

Sans point de consolidation, il n’y a pas de pilotage

La donnée utile ne vit pas dans les outils de front. Elle se consolide ailleurs. Entrepôt de données, lakehouse, plateforme client, peu importe le nom. Le point décisif, c’est l’endroit où les événements de tous les canaux se rejoignent et restent interrogeables ensemble.

Sans ce socle, chaque équipe travaille sur sa copie. La voix voit ses appels. Le digital voit ses tickets. Le social voit ses mentions. Chacun optimise sa métrique locale. Personne ne relie les signaux. Les ruptures de parcours restent invisibles, surtout quand elles traversent plusieurs outils et plusieurs équipes.

Demandez : "Où se fait la fusion des événements, et sous quel format sont conservés les champs clés ?" Demandez aussi : "Quelle est la fréquence de mise à jour, et quelle granularité garde-t-on par interaction ?" Si la consolidation repose sur des exports Excel, des rapprochements ponctuels ou des rapports manuels, vous n’avez pas un socle de décision. Vous avez une compilation tardive. Le piège est classique : des tableaux beaux à voir, mais incapables de rejouer un parcours ou d’expliquer une rupture.

Critère vérifiable : chaque interaction doit pouvoir être exportée avec son identifiant, son canal, son horodatage, son motif et son statut, sans perte de détail.

La gouvernance décide de la valeur de la donnée

La technique ne suffit pas. Sans propriétaire clair, la donnée CX unifiée dérive vite. Chaque canal défend ses règles. Les définitions changent. Les doublons s’installent. Les arbitrages se perdent entre directions. La qualité baisse d’abord en silence, puis elle contamine les analyses.

Il faut un responsable de la donnée CX unifiée. Pas un comité décoratif. Une fonction capable d’arbitrer les définitions, les règles d’identification, les droits d’accès et les contrôles de qualité. Sinon, chaque équipe optimise son indicateur local. Le client, lui, reste morcelé entre référentiels concurrents et versions contradictoires.

Demandez : "Qui valide la définition d’un client unique, d’un doublon et d’une interaction de référence ?" Demandez aussi : "Quel est le circuit de correction quand deux canaux décrivent le même événement différemment ?" Sans dictionnaire commun, les équipes parlent des mêmes objets avec des mots différents. Le symptôme est visible dans les réunions : chacun présente un chiffre juste dans son outil, faux dans le système global. Exigez aussi la règle de résolution des doublons et le délai de propagation des corrections.

Critère vérifiable : un dictionnaire de données partagé, une règle d’arbitrage documentée, et un responsable nommé pour trancher les conflits de définition.

Sans identifiant partagé, sans point de consolidation, sans propriétaire, la donnée CX n’est pas un actif. C’est un stock d’archives.

Le test du parcours complet tranche vite

Le bon test ne porte pas sur la beauté des dashboards. Il porte sur la reconstitution d’une séquence. Pour un client donné, pouvez-vous retrouver l’ordre exact de ses interactions, tous canaux confondus ? Si la réponse est non, le système ne voit pas le parcours. Il voit des événements isolés, rangés proprement mais incapables de raconter une histoire.

Ce test doit être mené sur un cas simple, puis sur un cas plus complexe. Un client commence en chat, poursuit par mail, puis appelle. Un autre alterne réseaux sociaux et voix. Si la reconstitution casse à un endroit, l’architecture n’est pas transverse. Elle tolère l’addition des canaux, pas leur liaison. Le symptôme est net : un trou dans la chronologie, un changement d’état introuvable, ou une interaction qui disparaît entre deux systèmes.

Demandez une démonstration sur données réelles, avec un identifiant client précis. Demandez aussi la traçabilité des changements d’état entre canaux, depuis l’ouverture jusqu’à la clôture. "Pouvez-vous me rejouer la séquence complète sans manipulation manuelle ?" est une question simple, mais redoutable. Si l’éditeur doit préparer des exports ou nettoyer les données avant la démo, le problème est déjà là. Exigez également un contrôle de cohérence entre horodatage, canal source et canal de reprise.

Critère vérifiable : la séquence doit être rejouable de bout en bout, avec ordre, statut et canal d’origine conservés.

Le bon cadre de décision part du client, pas du canal

Le cadre de décision doit partir du parcours client, puis descendre vers les canaux. C’est l’inverse qui fabrique les silos. Quand les équipes raisonnent d’abord en outils, elles comparent des performances locales. Quand elles raisonnent en client, elles cherchent les ruptures, les reprises et les enchaînements qui expliquent l’effort réel.

La bonne question n’est pas : "Quel canal performe ?" La bonne question est : "Où le parcours se casse-t-il ?" Pour y répondre, il faut des événements horodatés, un identifiant stable, et une consolidation exploitable par les métiers. Il faut aussi pouvoir filtrer par client, rejouer par séquence, puis agréger par motif. Sans cette chaîne, les décisions restent déclaratives. Elles commentent le passé au lieu de corriger le flux.

Demandez : "Peut-on analyser un client, puis remonter sa séquence, puis regrouper les cas par motif sans changer d’outil ?" Demandez aussi : "Qui valide la définition d’un parcours, et qui arbitre quand deux équipes utilisent des découpages différents ?" Le piège le plus fréquent est un reporting qui classe bien les volumes, mais ne sait pas expliquer les transitions. Le symptôme apparaît vite : des KPI stables, mais des irritants récurrents qui reviennent d’un canal à l’autre.

Critère vérifiable : analyses par client, par séquence et par motif doivent coexister dans le même cadre de données.