Utilisez cet article pour diagnostiquer pourquoi un Workflow ne s'exécute pas comme prévu. Il couvre les causes les plus courantes : paramètres du Messenger et de l'automatisation, incompatibilités des déclencheurs et du public, conflits de priorité des workflows, actions et timing des coéquipiers, configuration des canaux, conflits avec Fin AI Agent, et échecs des workflows de fermeture automatique.
Cet article s'adresse aux coéquipiers qui créent et gèrent des Workflows dans Intercom. Vous aurez besoin d'accéder au constructeur de Workflows pour appliquer les corrections décrites ici.
Liste de contrôle de dépannage
Avant de commencer, passez rapidement en revue ces domaines clés où les problèmes surviennent fréquemment :
Paramètres fondamentaux : Le Messenger est-il actif et les Workflows sont-ils activés pour le bon public ?
Règles et déclencheurs : Les conditions pour votre public, vos canaux et vos déclencheurs sont-elles configurées exactement comme prévu ?
Priorité du Workflow : Un autre workflow plus général s'exécute-t-il à la place de celui que vous attendez ?
Timing et actions des coéquipiers : La réponse, la planification ou les heures de bureau d'un coéquipier ont-elles empêché l'exécution du workflow ?
Conditions avancées : Des points de données spécifiques, comme le statut du Ticket, correspondent-ils parfaitement ?
Outil de dépannage des Workflows
Utilisez l'Outil de dépannage des Workflows pour identifier les conditions non correspondantes. Si l'outil identifie une condition non correspondante, mettez à jour la règle de déclenchement, le paramètre du public ou l'attribut de données pertinent dans votre workflow pour correspondre à l'état attendu, puis testez à nouveau avec la même conversation pour confirmer que le problème est résolu.
Accédez à la vue d'ensemble des Workflows.
Cliquez sur « Dépanner » et collez l'URL de la conversation.
Examinez les résultats pour voir quelles conditions ont été remplies et lesquelles ne l'ont pas été — l'outil met en évidence toute règle bloquant le déclenchement du workflow.
Note : Le dépanneur évalue les conditions dans l'ordre et s'arrête dès qu'une condition ne correspond pas comme requis. Cela signifie que si une condition antérieure échoue, les conditions restantes ne seront pas évaluées — seule la première condition non correspondante sera affichée.
Pourquoi mon Messenger ne déclenche-t-il pas le workflow ?
Avant de vérifier le workflow lui-même, assurez-vous que vos paramètres Messenger et d'automatisation sont correctement configurés pour permettre le démarrage des conversations.
Paramètres des conversations entrantes
Contrôler le volume des conversations entrantes est un paramètre du Messenger qui peut être configuré pour limiter qui peut démarrer une conversation. Comme cela peut empêcher les clients de commencer une conversation, les Workflows avec un déclencheur basé sur la conversation (par exemple « Customer opens a new conversation in the Messenger », « Customer sends their first message », « Customer sends any message ») ne se déclencheront jamais pour ces clients.
Messenger désactivé
Afficher le lanceur Messenger est un paramètre du Messenger qui peut être configuré pour cacher le Messenger aux clients. Si le Messenger est caché aux clients, tout Workflow impliquant une interaction avec le Messenger (par exemple « When a customer visits your site », « When a customer clicks on a website element », « When a customer opens the Messenger ») ne se déclenchera jamais pour ces clients.
Bases de l'automatisation
Si vous avez activé les évaluations de conversation dans vos paramètres Simple automations pour les Leads et Users, cela peut gêner le bon fonctionnement des déclencheurs d'inactivité. Cela peut interrompre involontairement d'autres Workflows orientés client.
Pour éviter ce problème, utilisez la solution suivante :
Au lieu d'envoyer l'évaluation de la conversation via les paramètres de base, vous devriez créer un Workflow pour envoyer ces évaluations à la place. Cela évitera le problème à l'avenir.
Pourquoi le bon type de déclencheur ne se déclenche-t-il pas ?
Incompatibilités des déclencheurs email et sortants
Certains types de déclencheurs, comme « Customer sends their first message » ou « Customer sends any message », déterminent quels workflows s'activent. Par exemple, « Customer sends their first message » se déclenche une fois par conversation, tandis que « Customer sends any message » se déclenche pour chaque message suivant. Cette compréhension est essentielle pour structurer efficacement les workflows sans chevauchements inattendus. Le choix du déclencheur et sa configuration déterminent qui/quoi peut correspondre au workflow et s'il se déclenche. Par exemple, utiliser un déclencheur « When a ticket is created » pour des tickets créés via l'API d'Intercom peut ne pas inclure un message initié par le client, ce qui peut empêcher le déclenchement du workflow.
Filtres de contenu des messages
Si votre workflow ne se déclenche pas pour certaines actions, vérifiez les critères cibles. Par exemple, si un workflow ne se déclenche pas pour un email spécifique, vérifiez que les conditions email dans vos paramètres de déclenchement sont correctes. Pour router efficacement les emails entrants, utilisez le déclencheur « Customer Sends First Message » et filtrez par attributs email plutôt que par filtres email. N'oubliez pas que les workflows sortants comme « Customer visits a page » sont conçus pour des déclencheurs spécifiques et ne sont généralement pas liés au démarrage d'une conversation.
Si votre workflow utilise des filtres de contenu de message, vérifiez s'ils sont trop restrictifs. Utiliser « Message content is » nécessite une correspondance exacte, tandis que « Message content contains » est plus flexible et augmente les taux de succès des déclencheurs.
Incompatibilités de type de profil (Users, Leads et Visitors)
Lors de la configuration des déclencheurs de workflow, vérifiez que la configuration de votre public correspond à votre intention. Si un workflow est configuré pour cibler uniquement les Users, il ne se déclenchera pas pour les conversations initiées par des Leads. Pour assurer une activation correcte du workflow pour tous les publics visés, élargissez vos règles d'audience pour inclure tous les groupes pertinents.
Lors de la configuration d'un workflow « Customer sends their first message », notez que si un visiteur pour la première fois ouvre le Messenger et déclenche le workflow, il sera ensuite considéré comme un lead mais évalué comme un visiteur dans le workflow, car celui-ci utilise un instantané de son profil.
Si le Workflow cible uniquement les Leads et Users, il ne se déclenchera pas pour ce Visitor. Envisagez d'ajouter tous les types de profils pour que tout le monde corresponde au Workflow.
De plus, assurez-vous que l'adresse email à laquelle les clients envoient des messages est correctement définie dans les paramètres de public cible et de déclenchement du workflow, en utilisant des filtres tels que « Email to » ou « Email recipient » pour plus de précision. Les Workflows destinés à gérer les emails transférés doivent toujours vérifier que l'adresse de transfert cible est correctement configurée et que le transfert automatique est activé.
Exemple :
Vous configurez un workflow avec le déclencheur « When customer opens a new conversation in the Messenger » et ajoutez une étape pour taguer toutes ces conversations.
Un client répond à un message que vous avez envoyé depuis Outbound.
Cette conversation ne serait pas taguée car il n'a pas démarré la conversation dans le Messenger (il a répondu à un message sortant).
Si vous voulez que toutes les conversations soient taguées, vous devriez utiliser le déclencheur « When customer sends any message » à la place.
Ciblez-vous les bonnes personnes (Users vs. Leads) ?
Si un workflow (par exemple, une réponse hors heures) ne se déclenche pas parce qu'il cible les « Users » mais que la conversation est avec un « Lead », votre automatisation ne fonctionnera pas comme prévu. Vérifiez toujours si votre workflow doit inclure à la fois Users et Leads dans ses paramètres de déclenchement. Des règles d'audience mal configurées peuvent entraîner des leads ou users non traités.
Les règles de ciblage d'audience peuvent influencer qui sera affecté par un Workflow. Si le client ne correspond pas aux critères d'audience spécifiés, le Workflow ne se déclenchera pas. Lors des tests, sachez que les workflows configurés pour « users only » peuvent échouer en mode navigation privée ou sur des navigateurs où l'utilisateur n'est pas reconnu (souvent identifié comme visiteur ou lead). Pour des tests complets, mettez à jour les paramètres d'audience de votre workflow pour inclure tous les types de participants pertinents (visitors, leads et users). Par exemple, un workflow ciblant uniquement les Users ne se déclenchera pas pour les Leads. De même, si un workflow nécessite des tags ou attributs spécifiques (par exemple un tag comme to_drop_off_detected), il ne se déclenchera pas si ces conditions ne sont pas remplies.
Pourquoi un seul workflow s'exécute-t-il alors que plusieurs devraient se déclencher ?
Workflows orientés client vs Workflows en arrière-plan
Les Workflows dans Intercom sont catégorisés en workflows orientés client ou en arrière-plan. Les workflows orientés client impliquent des interactions visibles, comme l'envoi de messages automatisés, tandis que les workflows en arrière-plan effectuent des actions invisibles pour le client, comme le marquage des conversations ou la fermeture des fils. Important : pour un type de déclencheur unique, un seul workflow orienté client s'exécutera, mais tous les workflows en arrière-plan correspondants peuvent s'exécuter. Cette distinction permet à différents workflows de coexister sans conflit. Un seul workflow orienté client se déclenche par conversation. Lorsque plusieurs workflows correspondent au même déclencheur, Intercom priorise et active le workflow le mieux classé dans les paramètres du workflow.
Vous ne pouvez avoir qu'un seul workflow orienté client en cours dans une conversation à la fois. Les actions qui interrompraient un workflow orienté client et permettraient d'en déclencher un autre sont des actions de coéquipier et incluent :
Ouvrir
Ouvrir et réaffecter
Envoyer un commentaire
Mettre en veille
Note : Un workflow orienté client conserve sa place même en attendant une réponse du client — pas seulement pendant l'exécution active des étapes. Cela signifie que les événements suivants (comme la création d'un ticket ou un nouveau message client) ne déclencheront pas un nouveau workflow orienté client tant que le premier reste actif, même si le nouvel événement utilise un type de déclencheur complètement différent. Par exemple, si un workflow de Suggestion d'article est actif et attend une réponse dans une conversation, un workflow « Quand un ticket est créé » ne se déclenchera pas tant que le premier workflow n'est pas interrompu ou désactivé. Pour résoudre cela, désactivez ou mettez en pause le workflow bloquant, ou utilisez une action de coéquipier (ouvrir, réaffecter, commenter ou mettre en veille) pour l'interrompre.
Note : Les workflows en arrière-plan sont conçus pour exécuter l'automatisation indépendamment des actions des coéquipiers et ne s'arrêtent pas lorsque les coéquipiers répondent ou mettent les conversations en veille.
Après qu'un workflow orienté client a été interrompu, un autre workflow orienté client peut intervenir.
Les réponses aux messages sortants ne déclencheront que les workflows configurés sur « le client envoie son premier message », pas ceux configurés sur « le client ouvre une nouvelle conversation ». Cette distinction aide à garantir que les workflows sont configurés correctement pour différents types de conversations. Par exemple, un déclencheur « Premier message » ne se déclenchera pas pour les réponses aux e-mails sortants, car ceux-ci sont considérés comme des continuations de conversations existantes.
Pourquoi ma règle d'audience ne correspond-elle pas aux bons clients ?
Les règles de ciblage d'audience peuvent influencer qui sera affecté par un Workflow. Si le client ne correspond pas aux critères d'audience spécifiés, le Workflow ne se déclenchera pas.
Vos règles AND / OR fonctionnent-elles comme prévu ?
Si votre workflow utilise plusieurs conditions reliées par "AND", et que les résultats sont insatisfaisants, envisagez de passer à la logique "OR" si déclencher un workflow en remplissant n'importe quelle condition répond à vos besoins. Pour les cas nécessitant que toutes les conditions soient remplies, assurez-vous que les attributs et valeurs sont correctement alignés dans la configuration. Lors de l'utilisation de règles "OR" dans le ciblage d'audience, une seule condition doit être vraie pour que la règle s'applique. Cela signifie que si l'une des conditions individuelles correspond, le workflow se déclenchera, même si d'autres conditions ne le font pas.
Exemple :
Disons que vous configurez une règle d'audience basée sur l'attribut Ville avec la logique suivante :
"La ville n'est pas Dublin" OU "La ville n'est pas Londres".
Si un utilisateur est à Londres, la règle s'évalue comme suit :
D'abord, elle vérifie : La ville n'est pas Dublin → Comme l'utilisateur est à Londres, cette condition est vraie.
Parce qu'une règle "OR" ne nécessite qu'une condition vraie, le workflow ne vérifie pas la deuxième condition (si la ville n'est pas Londres). La règle est déjà satisfaite, et le workflow continue.
Cela signifie que les utilisateurs à Dublin ou Londres peuvent encore recevoir le message ou déclencher le workflow de manière inattendue.
Les règles OR se déclenchent si n'importe quelle condition est remplie.
Les règles OR négatives peuvent entraîner des correspondances non intentionnelles car une fois qu'une condition est vraie, les autres sont ignorées.
Utilisez les règles AND lorsque vous avez besoin que toutes les conditions soient remplies avant de déclencher le workflow.
Assurez-vous que les conditions de branchement sont définies dans les règles d'audience plutôt que dans des étapes spécifiques du workflow.
Cela garantit que seules les conversations éligibles sont acheminées via le workflow dès le départ.
Donc, si vous souhaitez exclure les utilisateurs à la fois à Dublin et à Londres, vous devez passer de la logique "OR" à la logique "AND" :
"La ville n'est pas Dublin" ET "La ville n'est pas Londres".
Avec cette configuration :
L'utilisateur ne doit pas être à Dublin et ne doit pas être à Londres pour que le workflow se déclenche.
S'il est dans l'une ou l'autre ville, la règle d'audience ne correspond pas, et le workflow ne se déclenche pas.
Points clés
Lors de la configuration des règles d'audience pour les workflows Intercom :
Les règles OR se déclenchent si n'importe quelle condition est remplie.
Les règles OR négatives peuvent entraîner des correspondances non intentionnelles car une fois qu'une condition est vraie, les autres sont ignorées.
Utilisez les règles AND lorsque vous avez besoin que toutes les conditions soient remplies avant de déclencher le workflow.
Données personnelles & données d'entreprise
Votre Workflow peut avoir des déclencheurs spécifiques basés sur des données personnelles ou d'entreprise — ceux-ci peuvent être des attributs de données standard ou attributs de données personnalisés disponibles dans Intercom. Vous devez vérifier les critères et conditions définis pour ces déclencheurs, et vous assurer que les données sont correctement saisies et correspondent aux règles définies.
Exemple :
Lors de l'utilisation de branches dans un workflow, si vous vérifiez :
"L'attribut entreprise n'est pas".
Le client doit être rattaché à une entreprise pour remplir la condition et correspondre. Si nous n'avons pas d'entreprise pour vérifier l'attribut, nous ne supposerons pas que la condition est vraie - nous passerons plutôt à un autre chemin.
Lorsqu'une conversation est acheminée par la logique du workflow, le système utilisera l'entreprise la plus récemment mise à jour associée à l'utilisateur si aucune entreprise spécifique n'est définie, et que les conditions de branche utilisant des règles OR négatives peuvent entraîner un routage inattendu si elles ne sont pas soigneusement ordonnées. Assurez-vous de spécifier l'entreprise dans la session et de revoir l'ordre des branches pour garantir un routage correct.
Les règles d'audience utilisant "Dernière prise de contact" ne correspondent pas au contact qui vient de vous envoyer un message
Si votre workflow utilise une règle d'audience comme "Dernière prise de contact inconnue" ou "Dernière prise de contact il y a plus de X jours", vous pouvez constater que le workflow ne se déclenche jamais pour le client qui vient d'envoyer un message — même s'il apparaît dans l'aperçu de la taille de l'audience.
C'est un comportement attendu : lorsqu'un message entrant arrive, Intercom met à jour le timestamp "Dernière prise de contact" du contact avant que l'évaluation de la règle d'audience du workflow ne s'exécute. Au moment où l'évaluation se fait, le contact vient d'être entendu, donc les deux conditions évaluent à faux et le workflow ne se déclenche pas pour l'expéditeur.
Note : L'aperçu de la taille de l'audience (par exemple « 980 personnes dans votre audience ») lit les valeurs d'attribut actuelles et peut être trompeur. L'évaluation en direct considère la valeur après la mise à jour par le message entrant — donc un contact visible dans l'aperçu peut ne pas correspondre lorsqu'il écrit réellement. Cela s'applique également à tous les canaux entrants : Messenger, e-mail, SMS, et autres.
Alternatives recommandées :
Pour répondre à chaque message entrant quel que soit l'historique du contact : supprimez entièrement la règle "Dernière prise de contact" et ciblez les Leads et Users sur le canal pertinent.
Pour cibler uniquement les contacts tout neufs : utilisez "Inscription inconnue." Cet attribut n'est pas réinitialisé par les messages entrants, il n'y a donc pas de condition de concurrence.
Pour réengager les contacts dormants : utilisez "Dernier contact il y a plus de X jours." L'attribut "Dernier contact" enregistre quand vous avez envoyé un message sortant pour la dernière fois — il n'est pas mis à jour quand un client vous écrit, donc il reste précis au moment de l'évaluation.
Le timing, la planification ou une action de coéquipier pourraient-ils bloquer le workflow ?
En utilisant la planification, vous pouvez contrôler quand et pendant combien de temps un Workflow est actif. Il arrive souvent qu'un Workflow ne se déclenche pas parce que les critères de planification ne sont pas remplis. Des facteurs externes peuvent empêcher un workflow de s'exécuter, même si toutes les règles sont correctes.
Un coéquipier a-t-il répondu ou agi en premier ?
Si un coéquipier ouvre, réaffecte ou envoie un commentaire dans une conversation, cela peut interrompre et terminer tout workflow orienté client actif. De même, si un workflow a un délai, une réponse d'un coéquipier avant la fin du délai l'annulera. De plus, les workflows reposant sur des déclencheurs non réactifs peuvent ne pas s'activer si le dernier message a été envoyé par un bot plutôt que par un coéquipier.
Conversations en snooze et déclencheurs non réactifs
Pour les workflows qui utilisent une conversation en snooze comme condition de déclenchement, la conversation doit rester en snooze en continu jusqu'à ce que le client devienne non réactif. Si la conversation est désactivée du snooze avant ce moment — par exemple, par un coéquipier ou un minuteur automatique — le déclencheur d'inactivité ne se déclenchera pas, même si le client devient ensuite non réactif.
Note : Si une conversation est désactivée du snooze et que le client devient ensuite non réactif, le déclencheur de non-réponse ne se déclenchera pas à nouveau. Pour que le déclencheur fonctionne de nouveau, le client doit d'abord répondre pour rouvrir la conversation, puis redevenir non réactif pendant que la conversation reste en snooze.
Planning de date personnalisé
Le Workflow peut avoir un planning de date personnalisé — par exemple, pour ne se déclencher qu'entre le vendredi soir et le samedi matin. Dans ce cas, tester le Workflow en dehors de ces heures ne déclenchera pas le Workflow — quel que soit le trigger sélectionné. Par exemple, si un workflow est configuré pour s'exécuter les samedis entre 00:00 et 08:00 GMT, il ne se déclenchera pas pour des événements survenant à 20:01 UTC le même jour.
Heures de bureau
Vous pouvez avoir configuré les Heures de bureau pour que votre Workflow se déclenche — soit pendant les heures de bureau, soit en dehors des heures de bureau. Les Workflows utilisent uniquement les heures de bureau par défaut, pas les heures personnalisées définies pour des équipes individuelles.
Nous recommandons de déplacer les règles des heures de bureau à l'intérieur de vos Workflows sous forme de branches conditionnelles, plutôt que dans les paramètres de déclenchement d'un Workflow.
Les paramètres de déclenchement sont évalués lorsque votre client interagit avec le Messenger, tandis que les branches sont évaluées en temps réel pendant une conversation, ce qui les rend bien plus efficaces pour gérer les conditions basées sur le temps.
Les Workflows ne s'appliquent pas rétroactivement
Les Workflows ne se déclenchent que sur les conversations qui commencent après la création et la mise en ligne du workflow. Si une conversation a commencé avant l'existence d'un workflow, ce workflow ne s'appliquera pas — même si la conversation remplit toutes les conditions de déclenchement. Pour gérer les conversations préexistantes, gérez-les manuellement ou utilisez un workflow en arrière-plan qui agit sur les attributs existants de la conversation.
La configuration du canal pourrait-elle empêcher le workflow ?
Si votre Workflow est configuré pour des canaux spécifiques comme Email, SMS ou les réseaux sociaux, assurez-vous que le canal est correctement connecté et actif. Un canal déconnecté pourrait être la raison pour laquelle un Workflow ne se déclenche pas. De plus, assurez-vous que les paramètres du canal de votre workflow correspondent à la manière dont les users interagissent - si un workflow est configuré pour ne se déclencher que via "email" et que l'utilisateur interagit via le Messenger, le workflow ne se déclenchera pas. Pour les workflows email, assurez-vous que le canal Email est activé dans la configuration. Sans ce canal actif, les conversations email ne déclencheront pas les workflows respectifs. Par exemple, un workflow ciblant les canaux Web, iOS et Android ne se déclenchera pas pour les conversations email.
Assurez-vous que les workflows impliquant des emails ont le canal email correctement configuré et actif dans les paramètres de déclenchement. Vérifiez également si Simple Deploy a été activé, car il peut remplacer les workflows email.
Note :
Lors de l'utilisation d'un workflow "When customer sends their first message" contenant des éléments destinés au client, il doit y avoir un intervalle de plus de 2 minutes entre les nouvelles conversations démarrées par le même client pour que le workflow se déclenche à nouveau. Si l'intervalle est inférieur à 2 minutes, le workflow ne s'activera pas. Cette restriction s'applique uniquement aux workflows destinés au client — les workflows en arrière-plan tels que le marquage ou l'assignation des conversations ne sont pas soumis à cette limite et continueront de fonctionner.
Pour les conversations email entrantes spécifiquement, il existe un cas particulier supplémentaire : lorsque plusieurs emails du même expéditeur arrivent en quelques secondes, seuls le premier ou les deux premiers emails sont capturés par le déclencheur "Customer sends their first message". Les emails simultanés suivants correspondent uniquement au déclencheur "Customer sends any message". Si les conversations arrivent non assignées sans automatisation, ce comportement en rafale peut en être la cause. En solution de contournement, déclenchez manuellement un workflow réutilisable depuis la conversation affectée en utilisant Cmd/Ctrl + K > Trigger reusable workflow.
Comment empêcher le même workflow de se déclencher plusieurs fois ?
Lors de la configuration des workflows qui répondent aux messages des clients, vous pouvez vouloir empêcher le même workflow de se déclencher plusieurs fois dans une conversation, surtout lorsque les users ajoutent des détails supplémentaires.
Solution : Utilisez des tags de conversation pour contrôler les déclencheurs de workflow
Ajoutez un tag spécifique (par exemple, "Pricing") aux conversations lorsque votre workflow s'exécute.
Configurez les workflows pour vérifier l'absence de ce tag avant de se déclencher.
Cette approche garantit que chaque workflow ne se déclenche qu'une seule fois par conversation, évitant ainsi les réponses automatisées en double.
Assurez-vous que le tag référencé dans le workflow est un tag de Conversation, car les tags User ne peuvent pas être utilisés dans les filtres ou workflows au niveau de la conversation.
Ce système de tagging est particulièrement utile pour les workflows déclenchés par des conditions comme "Customer sends their first message" ou "Customer sends any message" où les messages de suivi pourraient potentiellement relancer votre automatisation. De plus, notez qu'un tag ne peut être appliqué qu'une seule fois par conversation. Si le tag a déjà été ajouté auparavant, le workflow ne le réappliquera pas.
Pourquoi mon workflow ne se déclenche-t-il pas sur la bonne URL de page ?
Assurez-vous que le Workflow est correctement configuré pour se déclencher sur les bonnes URL de page ou dans les bonnes applications sur les appareils iOS & Android. Une mauvaise configuration dans ces paramètres peut empêcher le Workflow de se déclencher.
Bonnes pratiques de ciblage URL
Le ciblage URL de la page actuelle peut être ajouté dans la section "Où envoyer" ou dans la section principale de ciblage Audience dans les paramètres du Trigger rule. Cependant, leur fonctionnalité diffère selon la section où ils sont placés :
Ciblage Audience : Les configurations URL ici ciblent les users en fonction de la dernière page visitée. Ces données peuvent ne pas toujours être à jour, ce qui peut entraîner un déclenchement inexact des Workflows.
Où envoyer : Offre un ciblage plus fiable basé sur la page réelle sur laquelle l'utilisateur se trouve actuellement. Cela correspond généralement au résultat souhaité.
Note : L'utilisation du ciblage URL dans la section Où envoyer désactivera le bot entrant sur iOS & Android, car les applications mobiles ne reconnaissent pas les URL. Si le ciblage URL est crucial, créez un bot spécifiquement pour le web Messenger et un autre pour iOS & Android sans règles URL.
URL de la page actuelle sur les applications monopage (SPAs)
L'attribut URL de la page actuelle dans les conditions de workflow reflète l'URL qui a été suivie lorsque la session Messenger a commencé — pas la page actuelle réelle du client. Sur les applications monopage (SPAs), où la navigation se fait sans rechargement complet de la page, cela signifie que l'URL peut sembler obsolète et ne pas correspondre à ce que le client voit actuellement.
Note : Il s'agit d'une limitation connue de la gestion de la navigation par les SPAs. Le Messenger JS n'est réinitialisé que lors des chargements complets de page, donc les changements dynamiques d'URL ne sont pas automatiquement suivis.
Solution de contournement : Utilisez l'API Intercom Messenger JS pour pousser l'URL actuelle en tant qu'attribut de données personnalisé chaque fois que la route change dans votre SPA. Vous pouvez ensuite utiliser cet attribut de données personnalisé comme condition URL dans le workflow au lieu de vous fier à URL de la page actuelle.
Problèmes de synchronisation avec les conversations créées via API
Les workflows reposant sur les conditions 'URL de la page actuelle' peuvent échouer pour les conversations créées via API. Il peut y avoir un décalage temporel entre le moment où l'URL est rapportée et celui où la conversation est créée via l'API, ce qui signifie que la condition URL peut ne pas être satisfaite à temps. Si vous créez des conversations via l'API et comptez sur des déclencheurs basés sur l'URL, testez soigneusement ou utilisez plutôt des conditions non basées sur l'URL.
Conditions URL dans les branches de workflow
Les conditions URL dans les branches de workflow sont évaluées au moment de la création de la conversation. Si le client navigue vers une URL différente après le début de la conversation, la condition de branche ne sera pas mise à jour pour refléter la nouvelle URL — le chemin Sinon sera suivi à la place. Concevez la logique de branchement en tenant compte de cela, et envisagez d'utiliser des attributs de données mis à jour via l'API Messenger JS pour un suivi dynamique des URL.
Pourquoi "URL de la page actuelle" ne fonctionne pas pour les conversations Facebook/Instagram
Le filtre "URL de la page actuelle" ne s'applique qu'aux pages où le Intercom Messenger est installé. Cela signifie qu'il ne capture pas les URL des conversations provenant de plateformes externes comme Facebook, car ces interactions ont lieu en dehors de votre site web.
Pour filtrer correctement les conversations provenant de différents canaux (par exemple Facebook et Instagram), vous devriez utiliser le filtre "URL de page" à la place. Ce filtre peut suivre la page référente ou les sources externes, vous permettant de segmenter correctement et de déclencher des workflows en fonction du lieu de départ de la conversation.
Workflows ne se déclenchant pas sur les pages d'articles
Si un workflow ne se déclenche pas sur les pages d'articles, vérifiez les règles d'exclusion d'audience qui pourraient bloquer les URL des articles :
Un autre workflow pourrait-il avoir la priorité sur le mien ?
Si une conversation remplit les règles de plusieurs workflows actifs, Intercom ne lancera que celui avec la priorité la plus élevée. Vous ne pouvez avoir qu'un seul workflow destiné au client en cours d'exécution dans une conversation à la fois.
Un autre Workflow s'exécute-t-il en premier ?
Les Workflows sont priorisés dans une liste de haut en bas dans vos paramètres. Si un workflow général est en haut de la liste, il peut se déclencher et empêcher un workflow plus spécifique plus bas de s'exécuter. Ajustez la priorité pour garantir que les workflows importants prennent le pas.
Par exemple : Un workflow général « Welcome » en haut de votre liste remplacera un workflow spécial « VIP Clients » en dessous, même si le client est un VIP.
Pour corriger cela :
Les paramètres de Fin AI Agent pourraient-ils bloquer mon workflow ?
Fin AI Agent peut parfois interagir avec les Workflows de manière à provoquer un comportement inattendu. Voici comment résoudre les problèmes courants liés aux workflows avec Fin :
Priorisation de Fin et des Workflows avec Simple deployment
Lorsque le Simple deployment de Fin et les workflows sont activés pour le même public, Simple deployment a la priorité et seul Fin répondra. Pour permettre le déclenchement des workflows, ajustez le ciblage du public pour qu'ils ne se chevauchent pas, ou désactivez Simple deployment.
Activation du CSAT pour les clôtures de Workflow Fin
Les Workflows Customer Satisfaction Score (CSAT) ne se déclenchent pas automatiquement lorsque Fin clôt une conversation. Pour garantir l'envoi des enquêtes CSAT, configurez-les dans le Workflow en utilisant l'étape « Let Fin answer ». Pour des instructions détaillées, consultez la documentation Fin CSAT.
CSAT envoyé sur d'anciennes conversations
Les enquêtes CSAT déclenchées par les workflows peuvent être envoyées à la clôture d'une conversation, même si le dernier message date de plus de 7 jours. Cela se produit car la règle de non-réponse de 7 jours s'applique uniquement au CSAT automatisé général d'Intercom, pas aux enquêtes déclenchées par les workflows.
CSAT envoyé malgré les tags d'exclusion
Les enquêtes CSAT peuvent encore être envoyées si les conditions du workflow utilisent la logique OU ou si les tags d'exclusion (par exemple, « no_csat ») ne font pas partie du même groupe de prédicats. Pour éviter cela :
Configurez les conditions dans un seul groupe de prédicats en utilisant la logique ET, en vous assurant que les tags d'exclusion sont évalués avec les autres conditions.
Problèmes de ciblage des Workflows CSAT
Les workflows CSAT peuvent ne pas se déclencher pour certains users ou canaux si le ciblage est trop restrictif. Par exemple, les workflows limités aux users connectés excluront les leads. Pour inclure tous les users :
Mettez à jour le public du workflow pour inclure à la fois les Users et les Leads.
Correction étape par étape pour CSAT non envoyé dans les workflows Fin-first
Ouvrez le workflow Fin-first dans Workflow Builder.
Modifiez l'étape « Let Fin answer ».
Activez « Demander une évaluation de la conversation (CSAT) » et spécifiez quand l'envoyer (par exemple, après résolution confirmée ou inactivité).
Enregistrez et activez le workflow. Note : Le CSAT Simple Automation s'applique uniquement aux conversations répondues par un humain ; les workflows doivent gérer le CSAT pour les conversations résolues par Fin.
Users interrogés de manière répétitive
Les workflows configurés pour « Get context about issue upfront » peuvent amener les users à être sollicités plusieurs fois pour la même information (par exemple, nom, email). Pour corriger cela, désactivez ce paramètre sous Fin AI Agent > Simple Automation > Get context about issue upfront pour les users et les leads.
Invite de capture d'email n'apparaissant pas dans Fin pour les conversations Sales
Si vous avez configuré une étape de workflow pour capturer l'adresse email d'un lead mais que l'invite n'apparaît pas dans Fin pour les conversations Sales, vérifiez les points suivants :
Conflit « Get context about issue upfront » : Si Get context about issue upfront est activé sous Fin AI Agent > Simple Automation pour les Leads, cela peut supprimer les étapes de capture d'email dans les workflows Fin pour Sales. Fin pour Sales gère la qualification des leads indépendamment, et les deux peuvent entrer en conflit — l'invite email peut être ignorée car Fin pour Sales suppose qu'il collectera les coordonnées via son propre flux de qualification. Pour corriger cela, désactivez Get context about issue upfront pour les Leads sous Simple Automation et utilisez plutôt une étape dédiée de capture d'email dans votre workflow.
Conflit de priorité de workflow : Un workflow client à priorité plus élevée peut être en cours d'exécution au lieu de votre workflow de capture d'email. Vérifiez l'ordre de priorité des workflows et assurez-vous que votre workflow Fin pour Sales est au-dessus de tout workflow général de capture ou de bienvenue qui pourrait intercepter le même public.
Le lead a déjà une adresse email : Si Intercom possède déjà une adresse email pour le lead issue d'une session précédente, l'étape de capture d'email peut être ignorée. Ajoutez une règle d'audience pour n'afficher l'étape que lorsque l'attribut email est inconnu.
Note : Les étapes de capture d'email dans les workflows Fin pour Sales doivent toujours inclure une branche de secours pour les cas où l'email du lead est déjà connu — sinon l'étape peut bloquer le reste du workflow pour les leads revenants.
Interférence du Simple deployment pour Fin
Si le Simple deployment pour Fin est actif, il peut remplacer vos workflows personnalisés, faisant que les visiteurs voient les déploiements Fin au lieu de votre workflow Intercom configuré. Si vos workflows ne se déclenchent pas comme prévu et que vous utilisez Fin, essayez de désactiver « Simple Deploy for Fin » pour garantir que vos workflows puissent se déclencher pour les users.
Échec du Workflow Fin à traiter les emails
Les Workflows basés sur les emails peuvent échouer si les emails ne sont pas correctement transférés depuis l'adresse désignée vers Intercom. Vérifiez la configuration du transfert d'emails car des erreurs ici empêchent souvent le traitement des emails. Assurez-vous que les emails transférés incluent correctement l'adresse email du destinataire prévue dans les filtres du workflow. De plus, vérifiez que le statut de transfert automatique est activé (« ON ») et que votre configuration de workflow email prend bien en charge les emails entrants des adresses de transfert désignées. Si les emails ne déclenchent aucun workflow, vérifiez que la bonne adresse email est définie dans le workflow ou via le ciblage du public. Ajouter l'email de support aux conditions de déclenchement du workflow peut aider à résoudre ces problèmes.
Transfert d'emails et règles de workflow
Lorsque les emails sont transférés via des listes de distribution, les conditions de domain peuvent ne pas correspondre car la conformité DMARC (Domain-based Message Authentication, Reporting and Conformance) réécrit les en-têtes.
Pour préserver les informations de l'expéditeur original :
Transférez les emails via un routage côté serveur (par exemple, redirection Google ou Microsoft 365), en évitant les listes de distribution comme Google Groups.
Prévention des conditions de concurrence dans l'évaluation des workflows
Les workflows peuvent se déclencher par erreur si une réaffectation est traitée après l'évaluation.
Minimisez ces erreurs en :
Révisant l'ordre des conditions pour s'assurer que les exclusions sont appliquées en premier.
Testant les workflows de manière approfondie lors des scénarios de réaffectation.
Éviter la mauvaise classification par Fin
Si Fin classe mal les conversations dans votre workflow Intercom, affinez vos descriptions d'attributs pour améliorer la correspondance :
Rédigez des descriptions claires et contextuelles pour chaque attribut.
Ajoutez des mots-clés spécifiques au domain souvent associés aux phrases clients.
Testez les descriptions avec des conversations exemples.
Pourquoi mon workflow d'auto-clôture ne fonctionne-t-il pas comme prévu ?
Les workflows d'auto-clôture ferment automatiquement les conversations en fonction de déclencheurs et conditions spécifiques — comme l'inactivité du client ou des actions prédéfinies dans le workflow. Ils aident à garder votre inbox organisée et assurent une résolution rapide des conversations. Utilisez cette section si votre workflow d'auto-clôture ne se déclenche pas, ferme les conversations trop tôt ou est interrompu de manière inattendue.
Pourquoi mon workflow d'auto-clôture ne s'est-il pas déclenché ?
Raisons courantes pour lesquelles un workflow d'auto-fermeture ne se déclenche pas :
Vérifiez les pannes pendant la période concernée — un incident actif a peut-être empêché le workflow de s'exécuter.
Assurez-vous que les conditions de déclenchement correspondent à l'état de la conversation. Par exemple, si votre audience inclut uniquement des 'Users', le workflow ne se déclenchera pas pour les 'Leads'. Étendez vos règles d'audience pour inclure tous les types de profils pertinents.
Si votre workflow d'auto-fermeture s'exécute alors qu'il ne devrait pas, les causes les plus courantes sont :
Conflit de déploiement simple : Si le déploiement Simple de Fin (une configuration Fin en une seule étape sans logique complète de workflow) est actif pour la même audience, il prend la priorité et peut empêcher les workflows d'auto-fermeture de se déclencher. Pour résoudre ce problème, désactivez le déploiement Simple ou ajustez le ciblage de l'audience pour éviter le chevauchement.
Action d'un coéquipier interrompant le workflow : Les actions des coéquipiers — comme ouvrir, réaffecter ou commenter une conversation — peuvent interrompre un workflow d'auto-fermeture actif et empêcher la fermeture de la conversation. Les workflows basés sur des déclencheurs d'inactivité peuvent aussi échouer si une action d'un coéquipier réinitialise le minuteur d'inactivité.
Temps de refroidissement de 2 minutes : Les workflows avec des actions visibles par le client (comme l'envoi d'un message) ont un temps de refroidissement de 2 minutes entre les déclenchements pour le même client. Cela évite les boucles avec les répondeurs automatiques mais peut empêcher l'auto-fermeture si une conversation a été rouverte dans ce délai. Pour garantir une auto-fermeture cohérente, créez des workflows séparés utilisant uniquement des actions en arrière-plan non visibles (comme la fermeture ou le marquage) plutôt que des étapes de message visibles par le client.
Pourquoi mon workflow d'auto-fermeture s'est-il déclenché de manière inattendue ?
Si votre workflow d'auto-fermeture s'exécute alors qu'il ne devrait pas, les causes les plus courantes sont :
Examinez les règles d'audience — en particulier les conditions OU, qui ne nécessitent qu'une seule condition remplie. Un client peut correspondre au workflow par inadvertance si une condition est vraie.
Vérifiez les changements d'état de la conversation, comme les tickets marqués 'waiting_on_customer', qui peuvent satisfaire les conditions de déclenchement de manière inattendue.
Pourquoi les conversations se ferment-elles trop tôt ou ne se ferment-elles pas du tout ?
Chaque bloc Let Fin answer dans un workflow a son propre minuteur d'auto-fermeture. Si le minuteur est réglé trop court, les conversations peuvent se fermer avant que le client ait eu le temps de répondre. Pour corriger cela, cliquez sur le bloc Let Fin answer, ouvrez les paramètres d'auto-fermeture et augmentez la durée du minuteur.
Si les conversations ne se ferment jamais malgré l'exécution du workflow, vérifiez les points suivants :
Vérifiez que les règles d'assignation ne rouvrent pas les conversations après leur fermeture par le workflow.
Si vous avez désactivé l'option Set expectation for human support, la case Auto-close abandoned workflow conversations sera également désactivée — elle n'est disponible que lorsque l'escalade vers un humain est configurée. Si vous souhaitez une auto-fermeture sans escalade, ajustez le workflow en conséquence.
Adaptez les paramètres d'auto-fermeture au type de déclencheur du workflow pour plus de cohérence — par exemple, les déclencheurs basés sur l'inactivité nécessitent un minuteur d'inactivité configuré sur le même bloc.
Auto-fermeture pour les workflows email
Pour les workflows basés sur email, assurez-vous que les paramètres d'auto-fermeture sont configurés pour gérer les emails transférés. Vérifiez que l'action d'auto-fermeture correspond aux conditions de déclenchement du workflow, et que les emails transférés incluent l'adresse du destinataire prévu afin que le workflow puisse les reconnaître correctement.
Note : Ajouter une étape d'action Close dans un workflow réutilisable est la méthode la plus fiable pour garantir la fermeture lors de l'utilisation de flux complexes à branches — ne vous fiez pas uniquement aux minuteurs d'inactivité dans les workflows réutilisables.
Pourquoi mon connecteur de données échoue-t-il dans un workflow déclenché par un visiteur ?
Les connecteurs de données nécessitent un contact identifié et une conversation active pour fonctionner. Si un connecteur de données s'exécute immédiatement lorsqu'un workflow se déclenche à la visite d'une page, il échouera pour les visiteurs non identifiés. Pour utiliser un connecteur de données de manière fiable dans un workflow déclenché par un visiteur :
Déclenchez le workflow à la visite de la page.
Affichez un message avec un bouton.
Exécutez le connecteur de données après que le bouton a été cliqué — à ce moment, une conversation existe et le contact peut être identifié.
En vérifiant ces points et en confirmant la bonne configuration, vous pouvez non seulement identifier la cause potentielle d'un Workflow qui ne se déclenche pas, mais aussi vous assurer qu'il est configuré correctement pour les opérations futures. 👌
Si vous avez encore besoin d'aide pour déboguer votre Workflow, contactez notre équipe Support via le Messenger.
Note : Sur Messenger mobile iOS et Android, les cartes d'articles intégrées ajoutées via les étapes de Workflow ne s'afficheront pas pour les utilisateurs. Pour garantir l'accès au contenu du Help Center aux utilisateurs mobiles, utilisez du texte hyperlié ou ajoutez un bouton URL pointant directement vers l'article.