Obtenir que Fin réponde aux questions est une première étape importante. Les Procedures vont plus loin en aidant Fin à résoudre des problèmes répétitifs et à plusieurs étapes — pas seulement pour expliquer un processus, mais pour le réaliser réellement.
Pour cela, Fin a généralement besoin d'accéder à des informations ou actions dans vos systèmes internes, ce qui signifie que vous pourriez avoir besoin d'aide de l'ingénierie ou de l'équipe propriétaire de ces systèmes en interne.
Ce guide s'adresse aux responsables support et opérations qui défendent les Procedures en interne. Il vous aidera à définir la demande, à parler avec assurance aux parties prenantes techniques, et à garder le premier projet assez petit pour être approuvé.
Pourquoi c'est important
Fin gère déjà bien les questions d'information. Les Procedures débloquent une autre valeur : résoudre des problèmes qui dépendent de données en temps réel ou d'actions système, comme vérifier le statut d'une commande, consulter un abonnement ou traiter un retour.
C'est là que commence le travail de plaidoyer interne. Si un problème client dépend de données en direct ou d'une action système, votre équipe aura besoin de Data Connectors et d'accès API pour rendre cette expérience possible.
L'opportunité ne se limite pas à la déviation. C'est une résolution plus rapide, moins de travail manuel répétitif, et une expérience client plus fluide pour vos tâches à fort volume.
Sans Procedures vs. avec Procedures
Sans Procedures | Avec Procedures |
Fin explique à un client comment soumettre une réclamation pour une commande endommagée. | Fin traite la réclamation, vérifie le statut de la commande dans votre base de données, et confirme le remplacement — tout cela en une seule conversation. |
Fin dit à un client de se connecter pour vérifier la date de renouvellement de son abonnement. | Fin consulte en temps réel la date de renouvellement et le statut de l'abonnement et donne une réponse immédiate au client — sans connexion requise. |
Selon le Rapport de transformation du service client 2026 d'Intercom, les équipes qui intègrent l'IA dans de vrais workflows, plutôt que de s'arrêter aux FAQ superficielles, rapportent un ROI nettement plus fort et des métriques améliorées. La plupart investissent dans l'IA, mais seule une minorité a atteint un déploiement mature.
Commencez avant l'ingénierie : ce que vous pouvez faire maintenant
Toutes les Procedures ne nécessitent pas de travail d'ingénierie. Avant d'impliquer les parties prenantes techniques, explorez ce que vous pouvez construire avec ce que vous avez déjà.
Procedures qui ne nécessitent pas de Data Connectors :
Flux de dépannage guidé utilisant le contenu de la knowledge base
Guides étape par étape qui collectent des informations et orientent vers la bonne équipe
Procedures de triage qui posent des questions de qualification avant d'escalader
Flux d'application de politique (par exemple, vérifications d'éligibilité à la garantie basées sur la date d'achat)
Procedures utilisant l'étape Loop in teammate / agent :
Si une Procedure a besoin d'informations d'un autre système mais que l'ingénierie n'est pas encore disponible, vous pouvez utiliser l'étape Loop in teammate / agent comme substitut. Un coéquipier complète manuellement cette étape pendant que le Data Connector est construit, vous permettant de tester le flux complet de la procedure et de recueillir des données sur son impact.
Commencer ici vous donne deux avantages : vous apprenez à construire des Procedures et vous générez des résultats mesurables qui justifient un investissement en ingénierie quand vous en avez besoin.
Astuce : Les équipes peuvent désormais construire et gérer des Procedures en langage naturel, appliquer les contrôles et données nécessaires pour la précision, et tester chaque scénario avant qu'il n'atteigne un client. Beaucoup d'éléments comme descriptions, déclencheurs, conditions, conseils, ne nécessitent aucune compétence technique.
Nouveau dans les APIs et Data Connectors ?
Si ces termes sont nouveaux pour vous, cette section couvre ce que vous devez savoir pour définir la demande et l'expliquer en interne.
Une API (Application Programming Interface) est un moyen structuré pour les systèmes logiciels d'échanger des informations. Lorsqu'un système a besoin d'une donnée d'un autre, il envoie une requête via une API et reçoit une réponse.
Un Data Connector utilise un appel API pour que Fin puisse récupérer ou envoyer en toute sécurité une information spécifique, comme le statut d'une commande ou la date de renouvellement d'un abonnement. Chaque connector est généralement conçu pour une tâche spécifique. En savoir plus sur les Data Connectors.
Une Procedure utilise ces connectors dans un processus à plusieurs étapes, pour que Fin puisse faire plus que répondre à une question, il peut aider à résoudre le problème. En savoir plus sur les Procedures.
Pour votre premier projet, commencez petit, un processus répétable, un système, et seulement les quelques champs de données dont Fin a réellement besoin. Plus la demande est ciblée, plus elle avance vite.
Exemple : comment les éléments se connectent
Objectif client : « Vérifier la date de renouvellement de mon abonnement »
Procedure : Fin confirme l'identité, appelle le système de facturation, et retourne la date de renouvellement, tout cela en une seule conversation
Data Connector : Un appel API en lecture seule vers la plateforme de facturation, retournant trois champs : date de renouvellement, nom du plan, statut de l'abonnement
Résultat : Fin répond en quelques secondes. Aucun coéquipier nécessaire
Fin n'a pas besoin d'accéder à tout votre système. Il a généralement besoin d'un moyen sécurisé pour récupérer ou envoyer un petit ensemble de données approuvées. L'ingénierie ou le propriétaire du système définit exactement quels champs Fin peut accéder, rien de plus.
Pour la configuration technique complète, référez-vous à l'article concevoir et utiliser vos APIs avec Data Connectors.
Comment choisir votre première Procedure
Le meilleur cas interne commence par un processus concret, pas une présentation de fonctionnalité. Avant d'impliquer l'ingénierie, écrivez le processus exact que vous voulez automatiser et les données minimales dont Fin a besoin pour bien faire.
Une bonne première Procedure est généralement étroite, répétitive, et déjà bien comprise par votre équipe support.
Astuce de pro : Choisissez le processus le plus précieux que vous pouvez automatiser avec le moins de points de terminaison et le plus petit ensemble de champs. Une Procedure qui lit quelques champs d'un seul système est bien plus facile à faire approuver, construire et lancer qu'une qui touche plusieurs systèmes. Commencez étroit — la complexité peut venir plus tard une fois la première victoire assurée.
Critères de sélection
Utilisez les critères ci-dessous pour identifier votre meilleur candidat :
Critères | Ce qu'il faut rechercher |
Volume | Un problème à haute fréquence que votre équipe traite de manière répétée |
Répétabilité | Un processus avec des étapes cohérentes qui ne nécessite pas de jugement humain à chaque fois |
Disponibilité de l'API | Une API bien documentée existe déjà (par ex. Stripe, Shopify) ou peut être définie rapidement |
Propriété du système | Vous savez quelle équipe interne ou quel outil possède les données ou l'action (par ex. « c'est dans Salesforce » ou « notre équipe de facturation gère cela ») |
Clarté de la demande d'ingénierie | Vous pouvez décrire ce que Fin nécessite en une phrase sans utiliser de termes techniques. Fin a seulement besoin d'un petit nombre de champs d'un seul système |
Mesurabilité | Vous pouvez définir un indicateur de succès clair avant de construire (par ex. taux de résolution) |
Exemple : une bonne première Procédure
Cas d'utilisation : Vérifier la date de renouvellement de l'abonnement
Système : Plateforme de facturation
Ce que Fin nécessite : Date de renouvellement, nom du plan, statut de l'abonnement — trois champs d'un seul point de terminaison
Première demande : « Nous avons besoin d'un point de terminaison en lecture seule qui renvoie ces trois champs pour un client authentifié. »
Pourquoi ça fonctionne : Volume élevé, répétitif, faible risque, et facile à mesurer. Ne nécessite pas d'accès en écriture et un effort minimal de la part de l'ingénierie ou du propriétaire du système.
Pensez en phases, pas tout d'un coup
Les équipes les plus performantes adoptent les Procédures par étapes :
1. Aucune intégration nécessaire : Automatisez les flux de type FAQ, les guides de dépannage et la logique de routage en utilisant uniquement le contenu de la knowledge base.
2. Accès en lecture seule : Connectez Fin à un système pour rechercher des informations (par ex., statut de commande, détails du compte, dates d'abonnement). C'est là qu'intervient le premier Data Connector.
3. Actions en écriture : Permettez à Fin d'agir dans un autre système (par ex., traiter un remboursement, annuler un abonnement, mettre à jour un enregistrement). Cela nécessite une implication plus profonde de l'ingénierie et intervient généralement après l'établissement de la confiance.
Commencer par la Phase 1 ou 2 signifie que vous pouvez montrer des résultats rapidement, et utiliser ces résultats pour construire le cas pour la Phase 3.
Astuce : Le tableau de bord Recommendations Fin AI Agent > Analyze > Recommendations est le moyen le plus rapide de trouver vos meilleurs candidats Procédures.
Filtrer par lacunes de données client : où Fin avait besoin d'informations d'un système externe comme le statut de commande ou les détails du compte
Filtrer par lacunes d'action : où Fin devait effectuer une action dans un autre système comme annuler une commande ou mettre à jour un enregistrement.
Chaque recommandation inclut un guide décrivant l'API et les données nécessaires, ce qui en fait un brief prêt à l'emploi pour votre conversation avec l'ingénierie. Extrayez un échantillon de conversations depuis le tableau de bord Recommendations, identifiez des intentions clients spécifiques pouvant devenir des Procédures, et estimez l'amélioration du taux de résolution en fonction de la fréquence de ces demandes. Cela transforme une idée générale en un plan concret et défini. Pour accéder aux Recommendations et autres insights pilotés par l'IA, vous aurez besoin de l'add-on Pro.
Cartographiez le processus avant la réunion
Avant d'approcher l'ingénierie ou l'équipe qui possède le système concerné, cartographiez exactement ce que vous voulez automatiser. C'est l'étape la plus importante — un processus bien cartographié accélère la conversation technique et rend la demande difficile à refuser.
Comment le cartographier
1. Écrivez le processus étape par étape en langage simple. Qu'est-ce qui le déclenche ? Que se passe-t-il à chaque étape ? Que reçoit le client à la fin ?
2. Soulignez exactement où Fin a besoin de données d'un autre système ou doit effectuer une action. Ce sont vos points de contact Data Connector.
3. Pour chaque point de contact, listez les champs de données spécifiques dont Fin a besoin. Pas toute la base de données — juste les champs minimum pour ce processus.
4. Identifiez quelle équipe possède chaque système. Ce n'est pas toujours l'ingénierie. Cela peut être l'équipe qui administre Salesforce, Jira, votre plateforme de facturation ou un autre outil interne.
Ce qu'il faut apporter à la réunion
Le processus cartographié avec des points de contact Data Connector clairs
Les champs spécifiques dont Fin a besoin à chaque étape (par ex., « statut de commande, numéro de suivi, date de livraison estimée »)
Un indicateur de succès que vous pouvez mesurer avant et après (par ex., « taux de résolution des requêtes sur le statut de commande »)
Données de volume montrant la fréquence de ce problème (extraites du tableau de bord Recommendations ou de vos rapports)
Astuce pro : Envisagez de cartographier visuellement le processus dans un outil comme Miro ou un simple organigramme. Cela aide tout le monde, y compris les parties prenantes non techniques, à voir l'ensemble et à identifier où se trouve réellement le travail d'ingénierie.
Qui est impliqué et ce qu'ils font
La création d'une Procédure nécessite deux types d'alignement : la clarté sur qui possède quoi au quotidien, et savoir quels intervenants doivent être engagés pour obtenir l'approbation.
Propriété au quotidien
Équipe CX / Support | Équipe d'ingénierie |
Rédiger et mettre à jour la Procédure en langage naturel en utilisant les étapes, outils et guides dans Intercom | Exposer l'accès au système via Data Connectors (appels API authentifiés) |
Définir la logique de la Procédure, les scénarios de test et les indicateurs de succès | Définir le point de terminaison, le type de requête (par ex. GET, POST) et les champs spécifiques que Fin est autorisé à utiliser |
Assurer l'itération après le lancement | Définissez les en-têtes d'authentification ou les jetons et confirmez les contraintes de sécurité
|
Qui doit être dans la salle
Rôle | Qui ils sont généralement | Ce qu'ils apportent |
Champion | Responsable du support ou des opérations pilotant l'initiative | Cartographie le processus de bout en bout et définit ce que Fin doit faire pour bien le réaliser |
Sponsor direct | Responsable du support, CX ou des opérations | Approuve la Procédure en priorité et donne au champion le mandat d'avancer |
Propriétaire du système | L'équipe ou la personne responsable de l'outil interne concerné (par exemple, administrateur Salesforce, responsable de l'équipe de facturation, propriétaire Jira) | Confirme quelles données existent, qui peut y accéder et quelles contraintes s'appliquent |
Responsable technique | Développeur, architecte ou responsable technique du système connecté | S'aligne sur la faisabilité, définit le point de terminaison et les champs autorisés, et confirme le calendrier |
Ce n'est pas toujours une conversation d'ingénierie. Si les données dont Fin a besoin se trouvent dans Salesforce, Jira, votre plateforme de facturation ou un autre outil interne, le principal intervenant peut être l'équipe qui possède ce système, pas un ingénieur logiciel. Identifiez d'abord le propriétaire du système, puis déterminez si une implication de l'ingénierie est nécessaire.
Le cas d'affaires par intervenant
La même Procédure peut être présentée très différemment selon les personnes présentes. Avant de préparer votre argumentaire, découvrez les priorités dont votre direction est déjà responsable, puis présentez la Procédure comme une contribution directe à l'un de ces objectifs.
Pour les responsables techniques, il est préférable de limiter la demande
"Nous ne demandons pas à l'ingénierie de gérer un workflow AI. Nous demandons de l'aide pour exposer un point de terminaison sécurisé afin que l'équipe support puisse automatiser elle-même un processus répétitif à fort volume. Une fois le point de terminaison en place, l'équipe CX construit et maintient la Procédure de manière autonome, sans intervention continue de l'ingénierie."
À partager : Le point de terminaison spécifique, les champs nécessaires, le type de requête (GET ou POST) et la méthode d'authentification. Plus la demande est précise, plus il est facile pour un ingénieur d'estimer et de planifier.
Concernant l'investissement en temps : Pour les équipes disposant d'API bien documentées, la configuration du Data Connector est généralement un travail limité. Nous avons vu une équipe de développement cliente mettre en place un connecteur en lecture seule en moins d'une heure. La portée est similaire à celle de toute autre intégration API, pas un nouveau système.
Pour les responsables support et CX, il est préférable de se concentrer sur la résolution
"Sans cette intégration, Fin ne peut qu'expliquer le processus. Avec elle, Fin peut compléter le processus. Cela élimine les efforts humains évitables et rend l'expérience client instantanée."
À partager : Le volume de conversations que cette Procédure gérerait, le temps moyen de traitement actuel et l'amélioration attendue du taux de résolution.
Pour la direction exécutive, il est préférable de s'aligner sur une priorité existante
"Dites-nous l'objectif sur lequel vous êtes déjà évalué — que ce soit le CSAT, le temps de traitement ou la réduction de la charge manuelle — et nous définirons cette Procédure pour montrer un résultat direct à cet égard. Cela ne nécessite pas de cas d'affaires propre. C'est une contribution directe à quelque chose que vous suivez déjà."
Une note sur la présentation : Pour certaines organisations, la valeur monétaire de l'automatisation est significative. Pour d'autres, les économies financières d'une seule Procédure peuvent ne pas être significatives à leur échelle. Dans ces cas, mettez en avant l'impact qualitatif : amélioration des scores d'expérience client, résolution plus rapide et réduction des frictions dans les workflows à fort volume. Connaissez votre audience et mettez en avant ce qui compte le plus pour elle.
Gérer les objections courantes
Ils disent... | Vous répondez... |
"Nous n'avons pas la capacité." | "C'est pourquoi c'est un pilote restreint. En supprimant cette charge manuelle récurrente de l'équipe, nous créons en fait de la capacité pour les sprints futurs." |
"Nous ne voulons pas d'accès système large." | "Les Data Connectors sont limités à des points de terminaison et champs de réponse spécifiques. Nous pouvons commencer avec un accès en lecture seule pour garantir la sécurité." |
"Nous avons besoin que l'API soit entièrement construite d'abord." | "Nous pouvons commencer la conception maintenant. Intercom prend en charge des réponses JSON d'exemple lors de la configuration, et nous pouvons valider la logique avec des simulations avant que l'API soit en ligne." Vous pouvez aussi utiliser l'étape Ask teammate comme solution temporaire, elle permet à un coéquipier de compléter manuellement cette étape pendant que le connecteur est en cours de construction, vous permettant de tester le flux complet de la procédure de bout en bout. |
"Ce n'est pas prévu dans notre feuille de route ce trimestre." | "Compris. Pouvons-nous l'inclure dans le prochain cycle de planification ? En attendant, nous aurons le processus cartographié, les champs documentés et la métrique de succès définie — ainsi, lorsque la capacité sera disponible, la demande sera prête." |
Une fois l'alignement avec l'ingénierie obtenu, partagez le guide Créer des data connectors pour Fin avec votre développeur ou propriétaire du système. Il couvre tout le processus d'installation, y compris la connexion API, l'authentification, la transformation des données et les tests.
Si les ressources internes sont limitées
Parfois, le véritable obstacle est le calendrier de la feuille de route. L'ingénierie peut être favorable en principe mais indisponible avant le prochain cycle de planification. C'est un résultat raisonnable, pas un échec.
Que faire en attendant
1. Cartographiez le processus de bout en bout en langage clair. Documentez chaque étape, chaque champ de données et chaque point de contact système.
2. Construisez des Procédures qui n'ont pas besoin de Data Connectors. Le dépannage guidé, les flux de triage et l'automatisation basée sur la knowledge base créent tous de la valeur dès maintenant.
3. Utilisez l'étape Loop in teammate / agent comme pont pour les étapes qui utiliseront finalement un Data Connector.
4. Recueillez des données de volume et suivez les résultats des Procédures déjà construites — cela devient la preuve pour votre prochaine demande.
5. Réduisez la portée autant que possible pour que la demande d'ingénierie soit prête à être intégrée dès que la capacité sera disponible.
Obtenez de l'aide extérieure
Participez aux Intercom Community Meetup Office Hours hebdomadaires pour des questions-réponses et un soutien encadré par des mentors
Pour obtenir de l'aide sur la définition du périmètre, discuter des obstacles et entendre comment d'autres équipes ont géré des conversations internes similaires. Utile en général et gratuit
Engagez un Expert pour un soutien personnalisé en 1:1
Pour un soutien plus pratique et dédié, le programme Experts vérifiés vous met en relation avec des consultants indépendants et des développeurs spécialisés dans Fin et Data Connectors. Une bonne option si vous souhaitez un accompagnement 1:1 et êtes prêt à investir dans une approche sur mesure
Conseil : Le Démarrage rapide : Créez une procédure Fin vous guide pas à pas pour construire votre première procédure, avec un exemple concret utilisant un Data Connector.
Ressources associées
FAQ
Faut-il créer une nouvelle API pour utiliser les procédures ?
Faut-il créer une nouvelle API pour utiliser les procédures ?
Pas nécessairement, si une API bien documentée existe déjà (par exemple Stripe ou Shopify), il s'agit généralement d'une intégration simple et peu coûteuse. L'ingénierie doit simplement exposer le point de terminaison spécifique et les champs que Fin est autorisé à utiliser.
Peut-on tester une procédure avant que l'API soit prête ?
Peut-on tester une procédure avant que l'API soit prête ?
Oui, Intercom prend en charge des réponses JSON d'exemple lors de la configuration, vous permettant de construire et valider la logique avec des simulations avant la connexion à l'API en direct.
L'ingénierie doit-elle créer la procédure elle-même ?
L'ingénierie doit-elle créer la procédure elle-même ?
Habituellement non, l'équipe support ou opérations gère la logique de la procédure — rédaction des étapes, tests et itérations après lancement. L'ingénierie ou le propriétaire du système active la couche de données : exposition du bon point de terminaison, définition des champs accessibles par Fin, et configuration de l'authentification. Une fois cela en place, l'équipe CX peut construire et mettre à jour la procédure de manière autonome.
Que faire si nous n'avons qu'un accès API en lecture seule au départ ?
Que faire si nous n'avons qu'un accès API en lecture seule au départ ?
C'est un point de départ tout à fait valide. Une procédure en lecture seule, par exemple pour vérifier le statut d'un abonnement ou les détails d'une commande, supprime un effort manuel significatif et offre un résultat mesurable sur lequel s'appuyer.
Combien de temps faut-il généralement à l'ingénierie pour configurer un Data Connector ?
Combien de temps faut-il généralement à l'ingénierie pour configurer un Data Connector ?
Cela dépend de la complexité, mais pour les équipes disposant d'API bien documentées, un Data Connector en lecture seule peut être configuré relativement rapidement — parfois en moins d'une heure. La portée est similaire à celle de toute intégration API standard : définir le point de terminaison, configurer l'authentification, mapper les champs de réponse. L'équipe CX gère tout le reste.
Peut-on créer des procédures sans aucune intervention de l'ingénierie ?
Peut-on créer des procédures sans aucune intervention de l'ingénierie ?
Oui. Les procédures utilisant le contenu de la knowledge base, les workflows de dépannage guidé, la logique de triage ou l'étape Ask Teammate ne nécessitent pas de Data Connectors ni de travail d'ingénierie. Ce sont d'excellents points de départ pour prendre confiance avant de passer aux procédures connectées.