Comment défendre les procédures Fin en interne

Obtenir que Fin réponde aux questions est une première étape importante. Les procédures 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 procédures Fin 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 procédures Fin 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 procédures Fin vs. avec procédures Fin

Sans procédures Fin	Avec procédures Fin
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 2026 sur la transformation du service client 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 procédures Fin 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à.

Procédures Fin 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
Procédures 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)

Procédures Fin utilisant l'étape Ask Teammate :

Si une procédure Fin a besoin d'informations d'un autre système mais que l'ingénierie n'est pas encore disponible, vous pouvez utiliser l'étape Ask Teammate 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 procédure et de collecter des données sur son impact.

Commencer ici vous donne deux avantages : vous apprenez à construire des procédures Fin, 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 procédures Fin 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 API 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 (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 connecteur est généralement conçu pour une tâche spécifique. En savoir plus sur les Data Connectors.

Une procédure Fin utilise ces connecteurs dans un processus à plusieurs étapes, permettant à Fin de faire plus que répondre à une question, mais d'aider à résoudre le problème. En savoir plus sur les procédures Fin.

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 »
Procédure Fin : 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 API avec Data Connectors.

Comment choisir votre première procédure Fin

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 souhaitez automatiser et les données minimales dont Fin a besoin pour bien faire.

Une bonne première procédure Fin est généralement étroite, répétitive, et déjà bien comprise par votre équipe support.

Astuce 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 procédure 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	À quoi faire attention
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 a besoin en une phrase sans utiliser de termes techniques. Fin n'a besoin que 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 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 a besoin : Date de renouvellement, nom du plan, statut de l'abonnement — trois champs d'un seul endpoint
Première demande : « Nous avons besoin d'un endpoint 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 Procedures 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 Procedures.

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, en faisant 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 Procedures, et estimez l'amélioration du taux de résolution selon la fréquence d'apparition de ces demandes. Cela transforme une idée générale en un plan concret et défini.

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 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 »)
Un indicateur 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 d'apparition 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

Construire une Procedure 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 Procedure 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 Procedure, les scénarios de test et les indicateurs de succès	Définir l'endpoint, 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 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 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 implication 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 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."
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 cadrerons 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 futurs sprints."
"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 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 Ask Teammate 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 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 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 plus sur mesure

Conseil : Le Démarrage rapide : Créez une procédure Fin vous guide pas à pas dans la création de votre première procédure, avec un exemple concret utilisant un Data Connector.

Ressources associées

FAQ

Doit-on 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.

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 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 consulter 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 du reste.

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.