Une tâche terminée par l’IA peut laisser un client sans réponse

Une session IA réussie peut malgré tout créer une défaillance de service

Un agent IA de gestion de patrimoine peut traiter une demande tout en laissant un investisseur avec un besoin urgent d’assistance humaine. Qualifier l’interaction de « réussie » peut donc masquer une préoccupation non résolue ainsi que le travail de service nécessaire pour y répondre. Pour les dirigeants responsables du produit, de l’expérience client (CX) et du développement commercial, la question est de savoir comment intégrer ce travail en aval dans le résultat du produit.

La réponse exige une responsabilité partagée sur l’ensemble du parcours client. Les équipes produit restent responsables de la demande de service générée par leurs applications, tandis que la CX pilote l’expérience sur l’ensemble des canaux. Une interaction numérique achevée doit donc être évaluée en tenant compte de ce que le client doit faire ensuite. Lorsque la confusion conduit à un appel au support, cet élément doit orienter les releases et les priorités d’ingénierie.

L’application enregistre l’achèvement ; le support hérite de la question non résolue

Le problème de responsabilité apparaît clairement dans un scénario représentatif au sein d’un établissement financier Tier-1 non nommé. Sa division Customer Service & CX gère un centre de contact omnicanal, qui traite les interactions sur l’ensemble des canaux, un service Diamond Support pour les clients fortunés, ainsi qu’un service Advanced Technical Support. La division comprend également l’optimisation des processus, le contrôle qualité (QC), l’analytique opérationnelle et la gouvernance stratégique de la CX. Ces fonctions la rendent responsable de la qualité de service, mais elles ne lui donnent pas automatiquement de visibilité sur l’application.

Le contrôle de l’application relève de la Business Development Unit, qui possède l’application patrimoniale propriétaire et les capacités numériques destinées à soutenir la croissance. Son périmètre comprend des agents IA autonomes orientés client, l’onboarding numérique et des outils algorithmiques de rééquilibrage de portefeuille. Ces capacités façonnent la manière dont les investisseurs rejoignent l’établissement et comprennent ensuite les activités liées à leurs actifs. Pourtant, l’unité et l’organisation de service utilisent des télémétries distinctes, c’est-à-dire les enregistrements de l’activité système, et travaillent avec des incitations et des interprétations de la responsabilité différentes.

Ces frontières déterminent quels éléments chaque division considère comme pertinents. Le directeur du développement commercial considère le comportement de l’application, l’adoption des fonctionnalités et la performance de l’IA comme des responsabilités produit, tout en attendant de la CX qu’elle se concentre sur les transactions de service et les enquêtes du centre de contact. Chaque équipe dispose d’un périmètre défini à gérer, mais cette séparation maintient hors supervision du parcours client complet les interactions numériques qui génèrent du travail de service.

La mesure produit renforce cette frontière avant même qu’un investisseur n’ait besoin d’aide. Les équipes évaluent les agents et les fonctionnalités de self-service à travers le taux d’achèvement des prompts, la durée des sessions, les taux de clics et les utilisateurs actifs quotidiens (DAU). Ces mesures montrent l’exécution et l’usage au sein de l’application. Utilisées seules, elles incitent les équipes à considérer l’adoption et les sessions terminées comme la preuve que les clients ont atteint leurs objectifs.

L’écart apparaît lorsqu’un agent autonome fournit à un investisseur fortuné une explication peu claire concernant un changement d’allocation d’actifs. Inquiet pour son capital, l’investisseur quitte l’application pour chercher une réponse compréhensible auprès d’une personne en qui il a confiance. Un signalement de défaut dans l’application apporte peu de réassurance immédiate ; il appelle donc en urgence Diamond Support ou Advanced Technical Support.

L’application enregistre néanmoins un achèvement : le prompt a été exécuté, le système n’a pas planté et la session s’est terminée. Un collaborateur de première ligne doit alors établir ce qui s’est passé, expliquer la logique de l’allocation et réduire l’anxiété de l’investisseur. L’achèvement technique et la préoccupation non résolue entrent dans des enregistrements départementaux distincts, ce qui permet au produit de considérer que la fonctionnalité fonctionne normalement tandis que le centre de contact absorbe la demande.

Les enregistrements produisent des interprétations différentes d’une même interaction. La comparaison ci-dessous présente les points de vue produit et CX/service à l’échelle de l’entreprise ; les diagnostics entre guillemets sont des libellés illustratifs dans le cadre du scénario. Cross-Journey FCR désigne la résolution au premier contact évaluée sur l’ensemble du parcours client, tandis que le Customer Effort Score cumulatif (CES) évalue l’effort requis sur l’ensemble de ce parcours.

Le changement de canal apporte des éléments que la vision produit exclut. Comme la confusion devient visible après que l’investisseur a quitté l’application, une mesure limitée à l’application manque une partie du résultat. Le CES cumulatif inclut l’effort nécessaire pour obtenir de l’assistance, ce qui déplace l’évaluation d’une session terminée vers le travail requis pour parvenir à une résolution compréhensible.

Cette évaluation plus large met aussi en lumière le travail imposé aux collaborateurs de première ligne. Ils doivent expliquer et investiguer une interaction sans avoir contribué à sa gouvernance ni disposer d’un accès immédiat à son historique. Reconstituer les événements pendant un appel en direct allonge le temps de traitement et crée une demande de service non budgétée. Cela demande aussi à un investisseur déjà inquiet de fournir davantage d’efforts pour obtenir une réponse.

Des reportings séparés masquent le lien entre cette demande et la décision produit qui l’a précédée. Les responsables produit voient l’usage et une exécution normale, tandis que les responsables service voient l’escalade et la pression sur la capacité. Relier l’appel à l’interaction IA rend visible le travail supplémentaire et attribue une responsabilité partagée : le service doit aider l’investisseur, tandis que le produit reste responsable de l’interaction qui a rendu cette aide nécessaire.

Des mesures séparées masquent les coûts de service, l’effort client et le risque pour la confiance

La première conséquence de cette séparation est que les angles morts du produit deviennent des coûts de service. L’expression « The Hallucination to Cost Pipeline » décrit la manière dont des conversations IA échappant à une revue transverse peuvent laisser les collaborateurs de première ligne déboguer des problèmes pendant les interactions client. L’exemple de l’allocation d’actifs relève de l’ambiguïté ; l’hallucination concerne des informations générées présentées comme des faits. Les deux peuvent créer du travail de traitement et de remédiation lorsqu’une sortie nécessite une explication ou une correction en direct.

Ce transfert de travail reflète ce que le théoricien des organisations Russell Ackoff appelait une « erreur de sous-optimisation » : améliorer indépendamment des composants individuels peut nuire à l’ensemble du système. L’application et le centre de contact peuvent chacun atteindre leurs objectifs alors même que l’investisseur vit un parcours dégradé. Fred Reichheld, créateur du Net Promoter Score (NPS), traite ce problème d’incitation dans The Ultimate Question 2.0, en soutenant qu’une véritable orientation client exige de supprimer les divisions qui privilégient des mesures fonctionnelles de court terme au détriment de la valeur client.

Des incitations séparées fragmentent aussi la Voice of Customer (VoC), c’est-à-dire les méthodes d’écoute et les données utilisées pour comprendre l’expérience client. Les analytics produit montrent ce que font les utilisateurs, tandis que les raisons de la confusion peuvent apparaître dans les évaluations d’appels QC ou d’autres activités d’écoute. Relier ces enregistrements permet aux dirigeants d’interpréter le comportement dans l’application à la lumière de ce que les investisseurs en disent ensuite. Sans ce lien, l’établissement peut comptabiliser une action tout en en comprenant mal le résultat.

Le coût de cette mauvaise compréhension devient plus clair lorsque les clients changent de canal. Matthew Dixon, Nick Toman et Rick DeLisi, coauteurs de The Effortless Experience et associés à CEB/Gartner, identifient le changement de canal après l’échec d’un self-service comme une cause majeure de désaffection client et de hausse des coûts d’exploitation. CEB/Gartner a un intérêt commercial à ce que les organisations achètent des études et des conseils sur ce type de problèmes. Leur argument porte sur l’effort à l’échelle de la séquence : un appel final satisfaisant peut coexister avec un parcours difficile pour y parvenir.

Pour les investisseurs de haut niveau, cette difficulté peut aussi affaiblir la confiance fiduciaire, c’est-à-dire la conviction qu’un établissement agira avec compétence dans la gestion de leurs intérêts financiers. Un comportement numérique en décalage avec les standards du conseil humain crée une friction cognitive, c’est-à-dire une difficulté à concilier ou à comprendre les informations présentées, et peut accélérer l’attrition des actifs lorsque les investisseurs déplacent leurs avoirs ailleurs. James L. Heskett et W. Earl Sasser Jr., associés à l’étude de la Harvard Business Review sur la Service Profit Chain, établissent un lien entre l’alignement opérationnel interne, la fidélisation client et la rentabilité.

Chaque argument éclaire un maillon différent du problème. Ackoff explique comment une optimisation locale peut nuire à la performance globale ; Reichheld traite des incitations ; Dixon, Toman et DeLisi examinent l’effort client ; Heskett et Sasser relient les opérations internes aux résultats commerciaux. Pour agir sur ces liens, le management doit attribuer la responsabilité du travail situé entre l’achèvement dans l’application et la résolution côté client.

Un indicateur de support a besoin d’un responsable capable d’exiger une action

Relier les données d’escalade aux dashboards produit constitue une première étape utile, car cela rend ce travail visible. Les équipes produit et d’ingénierie apportent déjà une expertise en conception fonctionnelle, en optimisation de la conversion et en débit technique, et une meilleure information peut améliorer leurs décisions. Un dashboard reliant une interaction IA à un appel ultérieur rendrait les effets en aval plus clairs. Il laisserait toutefois entière la question de savoir qui doit enquêter et imposer un changement.

L’investigation exige des méthodes qu’un indicateur de support ne peut pas fournir à lui seul. Les équipes ont besoin de tests de compréhension, de méthodes d’écoute client statistiquement solides et d’une manière cohérente de mesurer l’effort sur l’ensemble des canaux. Elles ont aussi besoin d’audits transverses des conversations et de l’autorité nécessaire pour prioriser la remédiation avant les fonctionnalités planifiées. Chaque responsabilité doit avoir un propriétaire explicite pour que l’information influence effectivement la delivery.

La CX apporte à ce travail une pensée systémique et des analytics comportementaux. Elle évalue la friction cognitive, identifie les écarts entre la communication voulue et la compréhension client, et conçoit des méthodes VoC fiables. Les chefs de produit et les data scientists utilisent ensuite ces constats dans le développement, tandis que la CX maintient les standards d’interaction, les mesures de parcours et les limites de qualité. L’ingénierie reste responsable de la delivery dans le cadre partagé.

Cette répartition des responsabilités fait entrer la CX dans les décisions avant que les clients n’aient besoin d’assistance. Les modèles d’orchestration de parcours de Gartner et Forrester soutiennent la coordination de l’expérience client au-delà des frontières organisationnelles ; les deux cabinets vendent des études et des services de conseil et tirent un bénéfice commercial de la demande pour cette approche. Appliquée ici, cette coordination relie l’innovation numérique à l’efficacité du service, à la confiance fiduciaire et à une croissance durable. Sa valeur pratique dépend de la définition précise de qui peut exiger un changement et de quels éléments déclenchent cette décision.

Faire en sorte que les résultats en aval modifient les contrôles de release et les priorités d’ingénierie

Le premier mécanisme proposé est un Cross-Journey Spillover Rate détenu conjointement, établi comme un Key Risk Indicator (KRI), c’est-à-dire une mesure signalant un risque opérationnel nécessitant une attention. Dans ce modèle proposé, il suit les interactions dans l’application associées à des escalades de service entrantes dans les 24 heures. Le produit et la CX évalueraient ainsi la même conséquence en aval, en reliant le comportement numérique à la demande de service qu’il crée. La propriété conjointe fait de cette relation une responsabilité des deux équipes.

Le taux aurait ensuite une conséquence définie pour le développement. Si le spillover d’une fonctionnalité ou d’un agent IA dépasse une limite fixée, le workflow concerné reçoit automatiquement une priorité de remédiation plus élevée dans le backlog de sprint produit, c’est-à-dire la liste ordonnée des travaux utilisée pour planifier le développement. Le seuil proposé à titre d’exemple est >3 %, un paramètre de conception illustratif. Cette règle donne au risque de service en aval une voie directe vers les priorités d’ingénierie.

L’application cohérente de cette règle exige un accord sur les interactions et les escalades qui comptent, ainsi que sur la manière de les relier. L’établissement a besoin d’un dénominateur défini et d’une méthode d’attribution, afin que les deux divisions calculent et interprètent le taux de la même manière. Ces choix relèvent du design opérationnel, car le résultat détermine quels travaux reçoivent la priorité. La règle de remédiation convenue transforme la mesure en engagement d’agir.

Le deuxième mécanisme déplace le QC existant du centre de contact vers une Cognitive Quality Assurance pré-déploiement, ou Cognitive QA, qui vérifie si les clients peuvent comprendre une interaction et y répondre sans confusion évitable. Avant qu’une modification d’agent autonome n’arrive en production, les analystes QA soumettraient ses prompts à des stress tests fondés sur des benchmarks de compréhension client, des indices de friction émotionnelle mesurant l’inquiétude ou la frustration, et des standards de conformité réglementaire. Cette revue fait de la compréhension client un critère de release au même titre que l’exécution technique.

Déplacer cette revue en amont permet au savoir du service d’éviter des investigations de première ligne évitables. Les analystes qui comprennent les questions récurrentes des clients peuvent tester les interactions avant qu’elles ne génèrent des appels. L’ingénierie reste responsable de l’implémentation et de la mise en production des changements, tandis que la revue conjointe détermine si la communication répond aux exigences de qualité de l’établissement. La compréhension client occupe ainsi une place explicite dans les décisions de déploiement.

Le troisième mécanisme donne à ces revues une base de preuve partagée grâce à une télémétrie unifiée du parcours : des enregistrements connectés entre l’application et les canaux de service. Les replays de sessions produit, les logs de prompts et les événements d’abandon alimenteraient le pipeline VoC de la CX, où les équipes les examineraient aux côtés des évaluations d’appels QC et des données d’écoute client. L’enregistrement combiné montrerait ce qu’un investisseur a fait avant de signaler une confusion ou une frustration.

Cette même connexion aiderait aussi les collaborateurs de première ligne à répondre pendant une escalade. Lorsqu’un investisseur contacte Diamond Support, l’interface de customer relationship management (CRM) devrait immédiatement afficher l’historique des prompts pertinents et la sortie de l’IA. Le collaborateur pourrait commencer par l’interaction qui doit être expliquée, réduisant ainsi la nécessité de la reconstituer au moyen de questions. Les préoccupations récurrentes pourraient ensuite être rattachées au workflow qui les a produites.

Le quatrième mécanisme confie ces décisions partagées à un Enterprise CX-AI Steering Council. Le responsable CX et le directeur du développement commercial coprésideraient cette instance, avec la participation des responsables juridique et ingénierie. Son périmètre couvrirait les frictions récurrentes dans les parcours, les audits des garde-fous des agents, c’est-à-dire les règles et contrôles qui contraignent le comportement des agents, ainsi que l’alignement entre les objectifs commerciaux et les niveaux de référence d’effort client. Cette composition réunit dans les mêmes décisions les responsabilités de croissance, de delivery, de qualité de service et de droit.

Pour que ces décisions aient lieu de manière prévisible, la charte doit définir le calendrier de revue et l’autorité du conseil. La cadence proposée est bi-weekly ; comme ce terme peut signifier deux fois par semaine ou toutes les deux semaines, la charte doit préciser la fréquence visée. Elle doit aussi relier les constats récurrents aux contrôles de release et aux décisions de remédiation. Le conseil doit avoir l’autorité nécessaire pour trancher la question de la responsabilité et orienter l’action suivante lorsqu’une revue identifie un problème.

Cette autorité doit s’étendre jusqu’à la delivery. La charte doit préciser qui peut exiger une revue de compréhension, faire remonter un workflow problématique et tenir le produit responsable des effets de service en aval. L’accès à la télémétrie fournit les éléments de preuve ; les droits de décision les rendent actionnables. Une préoccupation non résolue d’un investisseur peut alors modifier l’approbation d’une release ou l’ordre des travaux dans le backlog d’ingénierie.

Points clés à retenir pour les décideurs

• Faire de la demande en aval une mesure partagée : Le produit et la CX doivent suivre conjointement les interactions IA liées à des escalades de service dans les 24 heures. Convenez de règles d’attribution et d’un seuil qui augmente automatiquement la priorité de remédiation du workflow concerné.
• Tester la compréhension client avant la release : Les analystes QA du centre de contact doivent évaluer les interactions IA sous l’angle de la compréhension, de la friction émotionnelle et de la conformité réglementaire avant le déploiement. Donnez à ces constats un rôle explicite dans l’approbation de release.
• Relier les enregistrements de l’application et du support : Le produit et la CX doivent relier les logs de prompts, l’activité de session et les évaluations d’appels afin de rattacher les confusions récurrentes à leur source. Faites remonter les échanges IA pertinents dans le CRM du support afin que les collaborateurs de première ligne puissent résoudre les préoccupations plus rapidement.
• Donner des droits de décision à la gouvernance conjointe : Le responsable CX et le directeur du développement commercial doivent coprésider un conseil de gouvernance de l’IA avec le Juridique et l’Ingénierie. Sa charte doit préciser qui peut exiger des revues de compréhension, prioriser la remédiation et tenir le produit responsable des effets de service en aval.