Le ticket swarming par IA : ce que c'est, et où l'IA a vraiment sa place

Qu'est-ce que le ticket swarming ?

Le ticket swarming (vous le verrez aussi appelé case swarming, support swarming, ou modèle de support collaboratif) est une approche où, au lieu d'escalader un ticket à travers des paliers, un groupe de personnes collabore ensemble sur celui-ci. Une personne en prend la responsabilité et fait venir les experts dont elle a besoin, plutôt que de transmettre le ticket et de passer à autre chose.

La version formelle vient du Consortium for Service Innovation, le même organisme à l'origine du Knowledge-Centered Service (KCS). Il a inventé le terme « Intelligent Swarming » et le définit comme "une manière plus intelligente d'aligner les ressources sur le travail… en supprimant les paliers de support et, lorsque c'est pertinent, en faisant appel à l'expertise collective d'un « essaim » d'analystes." Zendesk présente la même idée pour le support client comme "une approche utilisée par les équipes de service client qui privilégie la collaboration plutôt que l'escalade pour résoudre un problème client complexe."

Comme Jon Stevens-Hall, de BMC, l'expose dans les principes fondamentaux, le swarming est une inversion directe de l'orthodoxie des paliers :

• Il n'y a pas de groupes de support par paliers.
• Il n'y a pas d'escalade d'un groupe à un autre.
• Le cas va directement à la personne la plus susceptible de le résoudre.
• Celui qui prend le cas le suit jusqu'à sa résolution (il en garde la responsabilité même en faisant appel à d'autres).

L'idée n'est pas nouvelle. Cisco a été l'un des grands pionniers, avec son "Digital Swarming" exposé dans un livre blanc de 2008 ; le Consortium l'a ensuite développée en Intelligent Swarming, et HDI cite Cisco, BMC, Red Hat et Allscripts parmi les premiers adoptants ayant constaté une amélioration spectaculaire. Ce qui est nouveau, c'est le « IA » placé devant, et cela change les calculs d'une manière que je vais détailler.

Swarming vs support par paliers

Les paliers ne sont pas une mauvaise chose. Ils constituent un filtre, et un bon filtre, quand le travail s'y prête. Le Consortium lui-même explique que le support par paliers fonctionne quand la plupart des problèmes sont simples et connus (95 % ou plus), résolus au premier contact, chaque niveau résolvant 70 à 80 % de ce qu'il reçoit. Les ennuis commencent quand cet équilibre change.

Voici comment les deux modèles diffèrent réellement :

(Comparaison établie à partir du « How Does It Work » du Consortium et du guide de case swarming de Zendesk.)

Le Consortium a une belle métaphore pour illustrer la différence : les paliers signifient "plusieurs équipes qui se renvoient les problèmes à travers le routage des incidents, le rerouting, l'escalade et le rejet (jouer au ping-pong)," tandis que le swarming ramène tout cela à "une seule équipe de personnes qui collaborent… (jouer à la balle)." La formule concrète de Zendesk : "Le support par paliers est excellent pour les problèmes récurrents… Le case swarming est idéal pour les problèmes plus complexes nécessitant des compétences différentes." La décision de savoir où envoyer chaque ticket est, fondamentalement, un problème de tri des tickets.

Pourquoi tout le monde parle soudain de « ticket swarming par IA »

C'est ce qui relie le tout. L'argument d'origine en faveur du swarming était démographique : à mesure que les clients résolvent eux-mêmes davantage de leurs problèmes connus via le self-service, les tickets qui atteignent un humain deviennent plus difficiles. C'est la même logique qui sous-tend tous les helpdesks IA modernes. Le Consortium souligne que "les clients d'un certain nombre d'entreprises résolvent désormais 80 % de leurs problèmes via le self-service," ce qui signifie que le résidu qui arrive dans la file est de manière disproportionnée nouveau, complexe et propice à l'escalade, exactement là où les paliers s'effondrent.

L'IA accélère fortement ce basculement. Une fois qu'un agent IA et un bon self-service absorbent le volume répétitif, ce qui reste pour les humains penche encore plus vers les cas vraiment difficiles. Le « ticket swarming par IA », ce n'est donc pas vraiment une IA qui rejoint un huddle Slack. Ce sont deux tâches distinctes :

1. L'IA traite les 95 % : les tickets connus et répétitifs, via l'automatisation des tickets et la classification, pour qu'ils n'aient jamais besoin d'un essaim.
2. L'IA assiste les 5 % : quand un véritable essaim se déclenche, elle rassemble le contexte, fait remonter la base de connaissances pertinente et rédige des brouillons de réponse, pour que les humains passent leur temps à réfléchir, pas à chercher.

Le chiffre de 5 % n'est pas le mien. La formulation la plus incisive que j'ai vue vient d'un praticien Salesforce sur Reddit, qui répondait à quelqu'un qui ne voyait pas l'intérêt du swarming :

« Le principal problème du swarming est le suivant : 5 % des cas prennent jusqu'à 30 %… de l'effort global de résolution, en raison de la complexité, du nombre d'équipes impliquées, etc.… Le swarming n'est pas un jeu de volume - il cible un très petit pourcentage de cas qui prennent beaucoup de temps à résoudre correctement. »

u/nebben123, r/salesforce

C'est tout l'enjeu. Si vous dirigez l'IA vers la mauvaise tranche (en essayant de la faire « essaimer » sur tout, ou en essayant de faire gérer du volume par un essaim humain), vous obtenez le pire des deux mondes. Si vous faites la bonne répartition, le modèle fonctionne enfin comme il a été pensé.

Où l'IA a vraiment sa place dans un essaim

Alors, que fait concrètement l'IA dans tout ça ? Dans les équipes avec lesquelles je travaille, le schéma qui fonctionne ressemble à ceci : l'IA se place en tête de file comme premier répondant, et un contrôle de confiance décide de ce qui se passe ensuite.

Quand l'IA est confiante, elle résout le ticket ou rédige une réponse qu'un agent enverra. Quand elle ne l'est pas, elle ne devine pas : elle laisse discrètement le ticket à un humain, mais pas les mains vides. Elle tague et route le ticket, récupère les tickets et documents passés pertinents, et laisse une réponse suggérée sous forme de note interne. L'humain qui reprend le ticket arrive avec du contexte, pas à froid.

Ce filtre de confiance est la décision de conception la plus importante, et c'est celle qui compte le plus pour les acheteurs. J'ai un jour eu un appel avec une responsable CX d'une marque traitant 7 000 tickets par mois, et elle a formulé l'exigence mieux que n'importe quel brief produit. Ses mots, à peu près : « L'IA ne pourra jamais répondre à 100 % des questions… J'ai besoin d'une IA qui ne traite que les tickets pour lesquels elle est confiante, et qui laisse tous les autres tranquilles. »

C'est le principe sur lequel eesel est construit. Vous définissez un seuil de confiance, excluez les types de tickets que vous n'êtes pas prêt à automatiser, et l'IA transfère silencieusement tout ce dont elle n'est pas sûre. Et parce que nous avons vu des bots au ton assuré donner de mauvaises réponses, chaque déploiement est d'abord simulé sur vos tickets historiques, afin que vous puissiez voir la couverture et le taux d'erreur par type de ticket avant que quoi que ce soit passe en production, plutôt que de le découvrir une fois en production. Lors d'un essai réel sur du trafic en direct, cette approche de simulation préalable a révélé une précision de tri de 93 % et une détection du spam de 100 % avant que l'équipe n'active la réponse automatique sur quoi que ce soit, exactement le type d'analyse des tickets de support que l'on souhaite avoir avant de faire confiance à une automatisation.

Il existe aussi une version plus prospective de tout cela, que certains praticiens imaginent déjà. Comme l'a écrit sur LinkedIn un responsable IT :

« Imaginez un « essaim intelligent » propulsé par l'IA et le machine learning, anticipant les problèmes, suggérant des solutions, et automatisant même certaines tâches de remédiation. »

Ajit Dsouza, LinkedIn

Ce que le swarming ne résout pas, même avec l'IA

Passons maintenant à la partie honnête, celle où la plupart des articles de vendeurs se taisent. Le swarming a des modes d'échec réels et documentés, et l'IA en corrige certains tout en en laissant d'autres complètement intacts. Si vous vous lancez, faites-le les yeux ouverts.

Le transfert « téléphone arabe ». Le swarming peut dégénérer en jeu du téléphone quand le responsable ne comprend pas vraiment le problème qu'il relaie. Un administrateur système sur Reddit a raconté avoir vécu cela en tant qu'utilisateur final :

« Une fois que le premier technicien a terminé son script et a commencé à faire appel à des équipes plus techniques, c'est devenu un vrai jeu du téléphone arabe avec un délai de 24 heures… En essayant de leur expliquer, nous devons passer par le technicien L1 et notre explication est filtrée par sa propre compréhension. »

u/beritknight, r/sysadmin

L'IA aide vraiment ici, en capturant tout le contexte du ticket au même endroit, pour que le spécialiste lise le détail original plutôt qu'une paraphrase de paraphrase.

Le refus d'invitation. Celui-ci, l'IA ne le résout pas à elle seule. Comme l'a formulé un opérateur sur LinkedIn, « La théorie derrière l'Intelligent Swarming est irréprochable… [mais] en pratique, je vois un point de friction important : le problème du « refus d'invitation ». Quand vous invitez un expert dans un essaim Slack, vous lui demandez de rompre sa propre concentration pour résoudre le casse-tête de quelqu'un d'autre. » Si vos experts sont évalués uniquement sur la clôture de leurs propres tickets, aucune IA ne leur donnera envie de rejoindre votre essaim. C'est un problème de métriques et d'incitations.

Le coût de coordination. Le Consortium l'affirme sans détour : "la collaboration prend du temps car davantage d'interactions… sont nécessaires entre les collaborateurs," ce qui explique précisément pourquoi tous les tickets ne doivent pas passer par un essaim. L'IA réduit le nombre de tickets qui nécessitent un essaim, mais un essaim qui se déclenche coûte tout de même du temps humain réel.

La responsabilité qui tourne au contournement. Quand « l'équipe le résout » devient « le technicien qui l'a pris en charge le résout », les gens s'adaptent. Un administrateur système a averti que les utilisateurs commencent à contourner le système, en essayant de passer à côté de votre outil de ticketing et de demander des techniciens précis, ce qui sabote discrètement votre routage et vos métriques. C'est un problème de conception de processus que l'IA peut soutenir (avec un routage et un tagging cohérents), mais qu'elle ne peut pas résoudre seule.

Le résumé honnête : l'IA est une réponse fantastique aux problèmes de volume et de contexte, et aucune réponse aux problèmes de culture et d'incitations. Quiconque vous vend le « ticket swarming par IA » comme solution à cette seconde catégorie fait de la survente.

Comment faire fonctionner le ticket swarming par IA en pratique

Si vous voulez mettre cela en pratique sans le chaos, voici la séquence que je suivrais :

1. Délimitez l'essaim de manière étroite. Décidez quels types de tickets sont vraiment assez complexes pour justifier une collaboration, et protégez-les. Tout le reste devrait aller vers l'automatisation ou le self-service, pas vers un huddle.
2. Laissez d'abord l'IA traiter le volume connu. Connectez un agent IA de helpdesk à votre système de ticketing existant et laissez-le gérer les tickets répétitifs. Moins il y a de tickets faciles dans la file, plus l'attention de vos humains est libre pour les cas difficiles.
3. Verrouillez tout sur la confiance. Réglez le seuil pour que l'IA ne réponde automatiquement que lorsqu'elle est sûre, et route silencieusement le reste. C'est la différence entre une IA qui aide et une IA qui crée discrètement de nouveaux problèmes.
4. Faites de l'IA la prise de notes de l'essaim. Avant qu'un humain soit sollicité, l'IA devrait déjà avoir rassemblé le contexte, fait remonter les documents pertinents, et rédigé un point de départ sous forme de note interne.
5. Simulez avant de déployer. Faites d'abord tourner l'ensemble sur vos derniers milliers de tickets, pour connaître la couverture et la précision par type de ticket. Deviner, c'est ainsi que l'on finit avec le bot sûr de lui mais dans l'erreur que tout le monde redoute.
6. Corrigez vous-même les incitations. Assurez-vous que vos experts sont reconnus pour leur aide sur les essaims, pas seulement pour la clôture de leur propre file. Aucun outil ne fera cela pour vous.

Tout cela consiste surtout à bien faire la répartition, à décider dans quel sens chaque ticket doit s'orienter, puis à faire porter à l'IA autant de charge qu'elle peut le faire sans risque, de part et d'autre de cette ligne.

Essayez eesel pour le ticket swarming par IA

Si le modèle décrit ci-dessus vous convient, eesel AI est conçu pour être le premier membre, toujours actif, de votre essaim. Il se connecte à votre helpdesk existant (Zendesk, Freshdesk, Gorgias, HubSpot, Front, et plus encore), apprend dès le premier jour de vos tickets passés et de vos documents d'aide, et résout ou rédige les tickets connus pour que l'attention de votre équipe reste disponible pour les cas complexes qui nécessitent vraiment un humain.

Le vrai différenciateur pour le swarming, c'est le déploiement avec simulation préalable : vous faites tourner l'IA sur des milliers de vos tickets historiques, vous voyez exactement quels types elle peut traiter en toute sécurité et où elle doit transférer, et vous réglez le seuil de confiance en conséquence avant qu'elle ne touche le moindre client réel. Une équipe, Gridwise, a vu eesel résoudre 73 % des demandes de niveau 1 dès le premier mois, des résultats obtenus pendant un essai de 7 jours. La tarification est basée sur l'usage, sans frais par siège, donc vous ne payez pas pour des effectifs que vous essayez justement de libérer.

L'essai est gratuit, sans carte bancaire, et la simulation s'exécute sur vos propres données, pour que vous puissiez voir la répartition par vous-même avant de vous engager.