Construire une procédure Fin qui gère bien un sujet techniquement complexe demande des itérations. Cet article explique comment une procédure réelle, la Data Connectors Setup and Troubleshooting procedure, a été conçue de A à Z, affinée au fil des itérations successives, et façonnée par six principes qui l'ont constamment améliorée. Utilisez-la pour appliquer la même réflexion à vos propres procédures.

Cet article s'adresse aux coéquipiers qui construisent et itèrent sur des procédures Fin. Il suppose que vous travaillez dans l'éditeur de procédure et que vous avez publié au moins une procédure.

La procédure gère toute la gamme des questions sur les Data Connector : configuration initiale, échecs d'authentification, erreurs d'appel API, délais d'attente, problèmes de mappage de réponse et régressions. Elle couvre beaucoup d'aspects techniques, et utilise un Data Connector propre, construit spécifiquement pour rechercher des données de diagnostic en direct sur le connecteur d'un client avant que Fin ne pose une seule question. Cette décision de conception a changé le fonctionnement de toute la procédure.

En surface, « aide avec les Data Connectors » semble être un seul sujet. En pratique, cela couvre plusieurs situations distinctes : une configuration initiale, un échec d'authentification, un appel API cassé, un délai d'attente, un problème de mappage de données, une régression (quelque chose qui fonctionnait et ne fonctionne plus), un protocole non supporté, et un client qui n'est pas encore sûr de ce dont il a besoin. Gérer tout cela correctement dans une seule procédure n'est possible que si Fin sait, tôt dans la conversation, dans quelle situation elle se trouve.

La décision de conception la plus importante dans la procédure est un Data Connector dédié, construit spécifiquement pour extraire des données de santé en direct sur le connecteur propre d'un client.

Quand un client partage l'URL de son connecteur, Fin utilise l'ID du connecteur pour faire une requête GET. Il reçoit :

Fin utilise ces données pour orienter sa première réponse significative avec quelque chose de spécifique, pas quelque chose de générique. C'est la différence entre une procédure qui ressemble à un formulaire de support et une qui ressemble à parler à quelqu'un qui a déjà examiné votre problème avant de décrocher le téléphone.

La procédure route en deux étapes. La première est automatique — Fin lit les données de diagnostic et route avant de poser une question au client. La seconde est basée sur l'intention — si la première étape ne détermine pas le chemin, Fin lit ce que le client décrit et route vers la sous-procédure correspondante.

Le tableau ci-dessous montre les 13 situations distinctes que la procédure Data Connectors Setup and Troubleshooting gère, comment Fin détecte chacune, et vers quelle sous-procédure elle route.

Les six principes ci-dessous expliquent comment la procédure en est arrivée là et comment appliquer la même réflexion à la vôtre.

Chaque principe inclut :

Avant que Fin ne dise un seul mot au client, il doit déterminer ce que le client demande réellement.

Différentes intentions méritent des chemins différents, et une procédure qui pose les mêmes questions d'ouverture à chaque client fait perdre du temps à la plupart d'entre eux.

Fin n'exécute pas non plus les procédures comme un script fixe de haut en bas. Il utilise une approche de planification non linéaire : il peut revenir sur des étapes précédentes, sauter des étapes ou changer de cap au fur et à mesure que la conversation évolue. Dans certains cas, il peut même passer à une autre procédure en cours de conversation si une autre convient mieux.

Cela signifie que l'ordre des étapes ne contrôle pas toujours l'ordre de la conversation. Concevez les procédures autour de l'intention que Fin doit gérer, pas autour d'un chemin strict étape par étape.

Une procédure qui traite des questions sur les Data Connectors illustre bien cela.

"Question sur les Data Connectors" couvre en réalité au moins cinq conversations différentes :

L'étape d'instruction d'ouverture demande à Fin de lire le premier message du client et de déterminer quelle situation s'applique.

Les étapes de condition plus bas envoient ensuite la conversation sur le chemin correspondant.

La direction se fait au déclencheur, c'est donc ce que vous devez tester — et le bon outil est le test en direct, pas les simulations. Les simulations contournent complètement la correspondance d'intention ; elles exécutent une procédure directement sans passer par le déclencheur, donc elles ne peuvent pas vous dire si Fin sélectionne la bonne procédure dès le départ.

Pour tester la direction, mettez la procédure en direct avec un public limité à vous-même — par exemple, une règle où l'email contient votre domain d'entreprise. Envoyez dix messages d'ouverture réalistes et vérifiez deux choses : que cette procédure démarre quand elle doit, et qu'elle ne démarre pas quand elle ne doit pas. Incluez des messages ambigus ; ce sont les cas les plus susceptibles d'être mal dirigés. Lorsqu'un message est mal dirigé, affinez la description du déclencheur pour être plus précis sur quand Fin doit ou ne doit pas utiliser la procédure.

Listez les types distincts de conversations que votre procédure recevra. Ensuite, demandez-vous : s'agit-il du même travail avec de légères variations, ou de travaux vraiment différents ? S'ils sont vraiment différents, vous avez deux options : les diviser en procédures séparées avec des déclencheurs distincts, ou les gérer comme des branches à l'intérieur d'une procédure. Utilisez des procédures séparées lorsque les travaux sont suffisamment distincts pour que vous souhaitiez voir leurs performances rapportées séparément. Utilisez des branches lorsque les travaux sont étroitement liés et que vous souhaitez que la logique soit maintenue en un seul endroit.

Rédigez votre déclencheur de manière claire sur les deux aspects : quand Fin doit utiliser cette procédure, et quand il ne doit pas. Les déclencheurs vagues sont la source la plus courante de mauvaise direction. Dans la procédure, ne demandez jamais aux clients de catégoriser leur propre problème — Fin lit leur message et dirige à partir de là. Le travail du client est de décrire son problème, pas de le labelliser.

Utilisez l'étape Condition pour les chemins majeurs et mutuellement exclusifs — des situations où ce que Fin fait ensuite est complètement différent selon la réponse. Pour les différences mineures, gardez la logique dans une étape d'Instruction en langage naturel. Cela rend les procédures plus simples et plus faciles à suivre pour Fin.

Les facteurs suivants vous aident à choisir entre diviser les travaux en procédures séparées ou les gérer comme des branches à l'intérieur d'une procédure :

Si votre procédure a accès à un Data Connector qui peut répondre à une partie de la question du client, appelez-le avant de commencer à interroger le client.

Les clients perçoivent cela comme de la compétence. Les procédures qui interrogent d'abord ressemblent à des formulaires.

Quand la question d'un client concerne un connecteur spécifique, la procédure Data Connectors Setup and Troubleshooting demande une fois le nom du connecteur. Elle appelle ensuite un Data Connector de diagnostic dédié et récupère les champs suivants :

La première réponse significative de Fin utilise ces données. Voici la différence en pratique (valeurs ci-dessous à titre indicatif) :

Après l'exécution du Data Connector, lisez à voix haute le premier message de Fin. S'il pose des questions auxquelles vous auriez pu répondre avec les données déjà récupérées, vous n'utilisez pas assez agressivement les données.

Poussez plus de décisions dans les étapes Condition qui lisent les données au lieu de les reporter sur le client.

Inventoriez les Data Connectors disponibles pour votre procédure. Pour chacun, demandez-vous : "Puis-je appeler ceci avant la première question du client plutôt qu'après ?" Si la réponse est oui, restructurez pour que la récupération des données se fasse en premier. Le client doit avoir l'impression que Fin a déjà fait le travail préparatoire.

Une fois que vous avez récupéré les données de diagnostic, branchez-vous directement sur ces données. Ne faites pas décrire au client un état que vous pouvez déjà détecter.

Après l'exécution du Data Connector, sa réponse devient disponible comme contexte temporaire. Lisez les champs individuels avec l'action read attribute, puis utilisez des étapes Condition qui branchent directement sur ces valeurs.

Le tableau ci-dessous montre comment les valeurs spécifiques des champs Data Connector correspondent aux branches des étapes Condition et à l'action correspondante que Fin doit prendre :

Chaque branche produit un message d'ouverture différent écrit spécifiquement pour cet état.

Pour chaque branche, demandez-vous : "La réponse de Fin dans cette branche aurait-elle du sens si un vrai client dans cet état exact la lisait ?"

La branche du connecteur sain est souvent la plus difficile à gérer car l'instinct est de continuer à diagnostiquer. Résistez à cela. Si le connecteur semble sain, dites-le et faites avancer la conversation.

Examinez chaque donnée que vous récupérez et demandez-vous si elle doit déclencher une étape Condition.

Gardez la logique serrée et rédigez chaque branche comme si c’était la seule réponse que le client verra jamais.

Le mode d’échec le plus courant dans une procédure basée sur les données n’est pas une erreur du Data Connector. C’est un appel réussi qui ne retourne aucun résultat.

Cela arrive généralement parce que l’entrée du client ne correspond à rien.

Les URLs du Data Connector doivent être exactes. Lorsque les clients fournissent des URLs qui ne correspondent pas au connecteur qu’ils souhaitent, que ce soit à cause de fautes de frappe, de barres obliques finales ou d’autres variations, le Data Connector retourne souvent des champs vides plutôt qu’une erreur.

Sans gestion explicite, Fin peut continuer et générer des réponses basées sur des données qu’il n’a en réalité jamais trouvées.

La solution est une étape Condition qui vérifie si les champs clés sont vides ou nuls. Si c’est le cas, Fin demande au client de vérifier l’URL du data connector dans leurs paramètres Data Connectors et de la fournir exactement telle qu’elle apparaît. Le Data Connector s’exécute alors à nouveau en utilisant l’URL corrigée.

Essayez des entrées qui correspondent presque mais pas tout à fait :

Si la procédure ne détecte pas et ne récupère pas ces cas, le chemin de secours n’est pas assez solide.

Chaque fois que vous appelez un Data Connector, ajoutez immédiatement après une étape Condition pour « pas de résultats ».

Dans cette branche :

Une procédure devient fiable grâce aux tests. Intercom vous offre trois outils qui détectent des problèmes différents de façon progressive — utilisez-les dans l’ordre, car chacun trouve des problèmes que le précédent ne peut pas.

Cliquez sur Review dans l’éditeur de procédure (en haut à droite, à côté de Test).

Review lance une analyse statique de la configuration de votre procédure et retourne une liste de problèmes signalés avec des corrections spécifiques. Elle détecte des problèmes de construction tels que :

Review ne lance pas une conversation ni ne montre comment Fin se comporterait réellement à l’exécution — elle inspecte uniquement la configuration. Lancez-la d’abord pour corriger les problèmes structurels avant de passer du temps sur les simulations.

Les simulations exécutent la procédure de bout en bout à partir d’un message d’ouverture, sans sortie visible pour le client. La transcription montre plus que la réponse finale : la réflexion de Fin à chaque étape, la branche choisie, les mises à jour d’attributs et les appels au Data Connector. Vous pouvez attacher des critères de réussite pour vérifier la réponse, les valeurs d’attribut, les appels au connecteur et le résultat, transformant un scénario en un test répétable de réussite/échec.

Les simulations contournent complètement la correspondance d’intention — elles exécutent la procédure directement et ne testent pas si votre déclencheur fonctionne correctement. Pour tester le routage d’intention, utilisez les tests en direct limités à vous-même (voir ci-dessous).

Une fois que Review est propre et que vos simulations passent, testez l’expérience complète de bout en bout. Mettez la procédure en direct avec un public limité à vous-même — par exemple, une règle où l’email contient votre company domain. Cela vous permet de tester l’expérience complète dans une vraie conversation sans l’exposer aux clients. Une fois satisfait, mettez à jour la règle du public pour inclure tous les clients. Enregistrer ce changement de règle crée un nouveau brouillon, alors cliquez à nouveau sur Set live pour que la modification prenne effet.

Les tests en direct détectent des choses que les simulations ne peuvent pas — le déclenchement correct, le déroulement réel de la conversation, et la sensation de chaque réponse lorsqu'elle arrive dans le contexte.

Suivez le pourcentage de conversations test où la première réponse de Fin aurait semblé juste pour le client. Ne vous contentez pas de demander « Est-ce que ça a bien routé ? » — demandez « Un humain réfléchi trouverait-il cette première réponse utile ? »

Au fil du temps, reliez cela aux signaux objectifs déjà disponibles dans Intercom : taux de résolution, CSAT, et temps de gestion des conversations. Si une amélioration de procédure fonctionne, vous devriez voir ces indicateurs évoluer.

Travaillez les couches dans l'ordre :

Chaque fois que vous mettez une procédure en live, Intercom vous demande d’écrire une note « Qu’est-ce qui a changé ? ». Considérez ce champ comme un vrai changelog, pas une formalité. Cela semble une corvée sur le moment, mais c’est le registre qui vous permet de relier un changement de métrique à une modification spécifique des semaines plus tard au lieu de deviner.

Une procédure n’est jamais terminée — vous continuerez à la peaufiner, et chaque changement est un petit pari que la procédure s’améliore. L’historique des versions est le registre de ces paris. Si le taux de résolution, le CSAT ou le temps de gestion évoluent après un changement, une note claire vous indique ce qui a changé et quand, pour que vous puissiez tracer l’évolution à une modification spécifique plutôt que de deviner.

Écrivez ce que fait le changement et pourquoi, pas seulement où il se trouve :

La deuxième version est une note sur laquelle vous pouvez agir six semaines plus tard. La première ne l’est pas.

Si un changement dégrade la performance, revenez en arrière depuis l’historique des versions :

Vous pouvez aussi modifier une note existante (l’icône crayon dans Historique des versions) pour clarifier ce qu’un changement passé a réellement fait.

Quand une métrique baisse, ouvrez d’abord l’Historique des versions. Alignez la date de la baisse avec vos notes de changement. La cause est généralement le changement publié juste avant.

La première version de la procédure Data Connectors Setup and Troubleshooting interrogeait les clients avant de chercher quoi que ce soit. Fin posait trois ou quatre questions avant de dire quelque chose d’utile. C’était fonctionnel techniquement mais ressemblait à un formulaire.

Le Data Connector diagnostique est arrivé à l’itération suivante. Cette seule addition a changé le caractère de toute la procédure. Au lieu de commencer par des questions, Fin pouvait commencer par des observations spécifiques — « Votre connector a un taux de réussite de 64 % sur les 7 derniers jours et la dernière erreur était un 401 » — puis passer directement à la résolution du problème.

Ensuite, le routage des intentions a été séparé du flux de diagnostic. Les clients demandant ce que les Data Connectors peuvent faire avaient un chemin différent de ceux avec un connector cassé. Cela a éliminé beaucoup de questions de diagnostic non pertinentes pour les personnes qui avaient juste besoin d’une réponse rapide sur les capacités.

Chaque itération était guidée par un modèle d’échec spécifique repéré dans de vraies conversations : un client qui atterrissait sur la mauvaise branche, un cas que le routage n’avait pas anticipé, une réponse techniquement correcte mais inutile dans le contexte. Aucune itération ne venait du hasard. Toutes venaient de preuves.

Le signal le plus clair qu’une procédure fonctionne est la qualité de la première réponse de Fin. Avant cette procédure, un client demandant un connector défaillant répondait à plusieurs questions avant de recevoir des conseils. Avec la procédure, la première réponse significative de Fin commence par ce qu’elle a réellement trouvé : l’état du connector, son taux de réussite sur la semaine passée, et son dernier code d’erreur. Le diagnostic commence par les données, pas par un entretien.

La profondeur du routage compte aussi. 13 chemins distincts signifient que chaque situation reçoit des conseils adaptés. Un client demandant une intégration SOAP obtient une réponse directe et honnête sur ce qui est supporté — pas un flux de dépannage qui ne mène nulle part. Un client dont le connector est sain mais dont les données ne se mappent pas correctement n’est pas envoyé d’abord vers un dépannage d’authentification.

Et quand une conversation nécessite un agent humain, la note de transfert contient déjà le nom du connector, l’URL du connector, et la catégorie du problème. Le coéquipier a le contexte avant de lire un seul message client. C’est un petit détail du point de vue du design — une étape de note à la fin de la procédure — mais cela transforme le transfert d’un redémarrage en une continuation.

Quand ces six principes sont combinés, une procédure comme l’exemple Data Connectors tend à suivre une structure prévisible :

Principe 6 — tenir un changelog honnête — n'est pas une étape dans la structure, mais c'est ce qui rend l'ensemble améliorable avec le temps. Sans un enregistrement clair de ce qui a changé et quand, chaque itération est une supposition.

Les meilleures Fin Procedures ne deviennent pas efficaces grâce à un premier brouillon astucieux. Elles deviennent efficaces parce que chaque itération est guidée par des preuves issues de conversations réelles.

Commencez par votre procédure à plus fort volume. Appliquez d'abord le Principe 1 : cartographiez chaque intention qu'elle pourrait recevoir et vérifiez que le routage fonctionne. Puis construisez à partir de là.

La première version est le point de départ. La bonne version est celle que vous avez affinée à plusieurs reprises.