Comment défendre les Fin Procedures en interne

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 qui gère 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. Il s'agit d'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 besoin de connexion.

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 en cours de construction, vous permettant de tester le flux complet de la procedure de bout en bout 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 vous sont nouveaux, cette section couvre ce que vous devez savoir pour définir la demande et l'expliquer en interne.

Une API (Interface de Programmation d'Applications) 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 un argumentaire de fonctionnalité. Avant d'impliquer l'ingénierie, écrivez le processus exact que vous souhaitez 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
API availability	Une API bien documentée existe déjà (par exemple 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 exemple « 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 une métrique de succès claire avant de construire (par exemple 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 en même temps

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 exemple, 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 exemple, traiter un remboursement, annuler un abonnement, mettre à jour un enregistrement). Cela nécessite une implication plus profonde de l'ingénierie et survient 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 de 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 pour les 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 agir 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 à Recommendations et autres insights pilotés par l'IA, vous aurez besoin du module complémentaire 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 clair. 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 agir. 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 exemple, « statut de commande, numéro de suivi, date de livraison estimée »)
Une métrique de succès que vous pouvez mesurer avant et après (par exemple, « taux de résolution des requêtes sur le statut de commande »)
Données de volume montrant la fréquence à laquelle ce problème survient (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

Construire 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 des étapes, des outils et des 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 métriques de succès	Définir le point de terminaison, le type de requête (par exemple 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 propriétaire 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 quelles priorités votre direction assume déjà, 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étable à 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."
Ce qu'il faut 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.
Aborder 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 client 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 du support et du 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."
Ce qu'il faut 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à mesuré — que ce soit le CSAT, le temps de traitement ou la réduction de la charge manuelle — et nous adapterons 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 public et mettez en avant ce qui compte le plus pour lui.

Gérer les objections courantes

Ils disent...	Vous dites...
"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 par 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 construit, pour 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'intégrer dans le prochain cycle de planification ? En attendant, nous aurons cartographié le processus, documenté les champs et défini la métrique de succès — 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. Rassemblez les données de volume et suivez les résultats des Procédures que vous avez 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 un mentor

Pour obtenir de l'aide sur la définition du périmètre, discuter des blocages 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 plus 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

Avons-nous besoin de 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 contenue et peu lourde. L'ingénierie doit simplement exposer le point de terminaison spécifique et les champs que Fin est autorisé à utiliser.

Pouvons-nous 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 à l'aide de simulations avant que l'API en direct soit connectée.

L'ingénierie doit-elle construire la procédure elle-même ?

Habituellement non, l'équipe support ou opérations est responsable de la logique de la procédure — rédiger les étapes, la tester et l'itérer après le lancement. L'ingénierie ou le propriétaire du système active la couche de données : exposer le bon point de terminaison, définir les champs accessibles par Fin, et configurer la méthode d'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 ?

C'est un point de départ parfaitement 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 toujours un effort manuel significatif et vous donne un résultat mesurable sur lequel construire.

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'APIs 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 s'occupe de tout le reste.

Pouvons-nous créer des procédures sans aucune implication de l'ingénierie ?

Oui. Les procédures qui utilisent 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.