Passer au contenu principal

Dépannage lorsqu'un Workflow ne se déclenche pas

Conseils de dépannage et configurations pouvant empêcher vos Workflows de se déclencher comme prévu.

Écrit par Beth-Ann Sher

Diagnostiquez pourquoi un Workflow ne s'exécute pas comme prévu — y compris les conversations envoyées à la mauvaise équipe, le routage vers la mauvaise inbox, l'assignation qui ne fonctionne pas comme prévu, ou un workflow complètement ignoré. Cela couvre les causes les plus courantes : paramètres Messenger et automatisation, incompatibilités de déclencheurs et d'audience, conflits de priorité de workflow, 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

Que votre workflow ne se déclenche pas du tout, que les conversations soient routées vers la mauvaise équipe ou inbox, ou que les assignations ne fonctionnent pas comme prévu, voici les principaux points à vérifier en premier :

  • Paramètres fondamentaux : Le Messenger est-il actif et les Workflows sont-ils activés pour la bonne audience ?

  • Règles et déclencheurs : Les conditions pour votre audience, 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 horaires de bureau d'un coéquipier ont-ils empêché le workflow de s'exécuter ?

  • Conditions avancées : Des points de données spécifiques, comme le statut du Ticket, correspondent-ils parfaitement ?


Des conversations envoyées à la mauvaise équipe ou inbox ?

Si les conversations sont assignées à la mauvaise équipe, arrivent dans la mauvaise inbox, ou si le routage ne fonctionne pas comme prévu, la cause est presque toujours l'une des suivantes :

  • Un workflow de priorité plus élevée s'exécute à la place — voir « Un autre workflow pourrait-il avoir la priorité sur le mien ? » ci-dessous.

  • Le ciblage de l'audience est trop restreint — un workflow ciblant uniquement les Users ignorera les Leads, les laissant non assignés ou routés vers une solution de secours. Voir « Pourquoi ma règle d'audience ne correspond-elle pas aux bons clients ? »

  • L'étape d'assignation est manquante — si le workflow n'inclut pas une étape explicite Assign to team ou Assign to teammate, les conversations retombent sur Non assigné. Voir l'article sur les workflows d'assignation lié ci-dessous.

  • Le workflow ne se déclenche pas du tout — si aucun workflow ne se déclenche, aucune assignation n'a lieu. Continuez à lire cet article pour diagnostiquer pourquoi.

Pour un guide complet sur les problèmes spécifiques d'assignation (conversations non assignées, Round Robin, disponibilité de l'équipe), voir Gérer et dépanner les Workflows d'assignation.


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 d'audience ou l'attribut de données pertinent dans votre workflow pour correspondre à l'état attendu, puis retestez avec la même conversation pour confirmer que le problème est résolu.

  1. Accédez à la vue d'ensemble des Workflows.

  2. Cliquez sur « Dépanner » et collez l'URL de la conversation.

  3. 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 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 Messenger qui peut être configuré pour limiter qui peut démarrer une conversation. Comme cela peut empêcher les clients de démarrer 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 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 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 et empêcher leur déclenchement.

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 entre 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'activeront. 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 pour votre workflow et la configuration des paramètres de déclenchement détermineront 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 (Application Programming Interface) peut ne pas inclure un message initié par le client, ce qui peut empêcher le workflow de se déclencher.

Filtres de contenu des messages

Si votre workflow ne se déclenche pas pour des actions spécifiques, vérifiez les incompatibilités dans vos 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 d'utiliser des filtres email. N'oubliez pas non plus 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 réussite du déclenchement.

Incompatibilités de type de profil (Users, Leads et Visitors)

Lors de la configuration des déclencheurs de workflow, vérifiez que votre configuration d'audience 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 toutes les audiences prévues, é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 visitor dans le workflow, car celui-ci utilise un instantané de leur 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 profil pour que tout le monde corresponde au Workflow.

Capture d'écran du panneau des paramètres de ciblage d'audience du Workflow Intercom. Trois cases à cocher sont affichées pour les types de contacts : Users, Leads et Visitors. Les trois sont sélectionnées. Pour éviter qu'un workflow ne saute des contacts qui ne correspondent pas à un seul type de profil, assurez-vous que les trois cases sont cochées.

De plus, assurez-vous que l'adresse email à laquelle les clients envoient des messages est correctement définie dans les paramètres d'audience 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 à traiter les emails transférés doivent toujours vérifier que l'adresse de destination du transfert 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 elle n'a pas démarré dans le Messenger (le client a répondu à un message sortant).

  • Si vous souhaitez que toutes les conversations soient étiquetées, vous devriez plutôt utiliser le déclencheur « Lorsque le client envoie un message ».

Ciblez-vous les bonnes personnes (Users vs. Leads) ?

Si un workflow (par exemple, une réponse hors horaires) ne se déclenche pas parce qu'il cible les « Users » alors 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 de workflows, sachez que les workflows configurés pour « users uniquement » 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 (visiteurs, 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 classés en workflows orientés client ou workflows 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 l'étiquetage 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 actif 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 :
​
​Ouverture
Ouverture et réaffectation
Envoi d'un commentaire

Mise 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 « Lorsqu'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 (ouverture, réaffectation, commentaire ou mise 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 emails sortants, car celles-ci sont considérées 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 une seule condition suffit. 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 des 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 correspondent pas.

Exemple :

Supposons que vous configuriez 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'évaluera 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 seule 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 users à 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 des 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 de l'entreprise n'est pas".
​
Le client doit être rattaché à une entreprise pour que la règle de condition soit remplie et corresponde. 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 vérifier 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 constaterez peut-être 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 des règles d'audience du workflow ne s'exécute. Au moment où l'évaluation de la règle 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 actuelles des attributs et peut être trompeur. L'évaluation en temps réel 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, email, 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 "Last heard from" et ciblez les Leads et Users sur le canal pertinent.

  • Pour cibler uniquement les contacts tout neufs : utilisez "Signed up is unknown." 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 inactifs : utilisez "Last contacted is more than X days ago." L'attribut "Last contacted" enregistre la dernière fois où vous avez envoyé un message sortant — il n'est pas mis à jour lorsque le client vous écrit, donc il reste précis au moment de la correspondance.


Le calendrier, la planification ou une action d'un 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 pris une action en premier ?

Si un coéquipier ouvre, réaffecte ou envoie un commentaire dans une conversation, cela peut interrompre et mettre fin à tout workflow actif orienté client. De même, si un workflow comporte un délai, une réponse d'un coéquipier avant la fin du délai l'annulera. De plus, les workflows dépendant de 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 utilisant 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 non réactif 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.

Planification de date personnalisée

Le Workflow peut avoir une planification de date personnalisée — par exemple, pour ne se déclencher que du vendredi soir au samedi matin. Dans ce cas, tester le Workflow en dehors de ces heures ne déclenchera pas le Workflow — quel que soit le déclencheur 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 avez peut-être 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 d'intégrer les règles d'heures de bureau dans 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 cela peut remplacer les workflows email.

Note :

  • Lors de l'utilisation d'un workflow "When customer sends their first message" contenant des éléments orientés client, il doit y avoir un intervalle de plus de 2 minutes entre les nouvelles conversations lancé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 orientés client — les workflows en arrière-plan comme le marquage ou l'affectation des conversations ne sont pas soumis à cette limite et s'exécuteront toujours.

  • Pour les conversations email entrantes spécifiquement, il existe un cas particulier : lorsque plusieurs emails du même expéditeur arrivent en quelques secondes, seuls les un ou 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 ?

Lorsque vous configurez des workflows qui répondent aux messages des clients, vous pouvez vouloir empêcher qu'un même workflow se déclenche 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éclenchements 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. Notez également 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 et Android. Une mauvaise configuration dans ces paramètres peut empêcher le Workflow de se déclencher.

Bonnes pratiques de ciblage URL

Le ciblage par URL de page actuelle peut être ajouté dans la section "Où envoyer" ou dans la section principale de ciblage d'audience dans les paramètres de règle de déclenchement. Cependant, leur fonctionnalité diffère selon la section où ils sont placés :

  • Ciblage d'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 des déclenchements de Workflows inexactes.

  • 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é.

Capture d'écran du panneau des paramètres de déclenchement de Workflow Intercom montrant deux zones distinctes de configuration URL. La section 'Ciblage d'audience' évalue l'URL de la dernière page visitée par un visiteur, qui peut être obsolète. La section 'Où envoyer' cible la page actuelle en direct du visiteur et est l'option la plus fiable pour les déclencheurs de workflow basés sur la page.

Note : Utiliser le ciblage URL dans la section Où envoyer désactivera le bot entrant sur iOS et 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 et Android sans règles URL.

URL de page actuelle sur les applications monopages (SPAs)

L'attribut URL de 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 monopages (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 : C'est 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 JS Intercom Messenger pour pousser l'URL actuelle comme 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 page actuelle.

Problèmes de synchronisation avec les conversations créées via API

Les workflows reposant sur les conditions "URL de 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 JS Messenger pour un suivi dynamique des URL.

Pourquoi "URL de page actuelle" ne fonctionne pas pour les conversations Facebook/Instagram

Le filtre "URL de 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 devez utiliser plutôt le filtre "Page URL". 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 point 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 :

  • Allez dans Paramètres → Messenger → Widget Messenger → Afficher le lanceur Messenger et vérifiez si des règles d’affichage conditionnel basées sur l’URL sont actives.

  • Si une règle masque le Messenger sur les URL correspondant à votre domaine help center (par exemple intercom.com/help/*), le Messenger ne se chargera pas sur les pages d’articles — et sans Messenger, tout Workflow reposant sur une interaction Messenger ne se déclenchera pas.

  • Pour corriger cela, ajoutez une exception pour votre modèle d’URL help center, ou supprimez la règle d’exclusion si elle n’est pas nécessaire.

Note : Cela n’affecte que les Workflows impliquant une interaction Messenger (par exemple « Quand un client visite une page », « Quand un client ouvre le Messenger »). Les workflows en arrière-plan et les workflows email ne sont pas affectés par les paramètres de visibilité du Messenger.


Un autre workflow pourrait-il avoir la priorité sur le mien ?

Si une conversation remplit les conditions de plusieurs workflows actifs, Intercom exécutera uniquement celui avec la priorité la plus élevée. Vous ne pouvez avoir qu’un seul workflow orienté client actif 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 passent en premier.

Par exemple : Un workflow général « Bienvenue » en haut de votre liste remplacera un workflow spécial « Clients VIP » en dessous, même si le client est VIP.

Pourquoi l’affectation à une équipe supprime-t-elle une affectation individuelle existante ?

Affecter une conversation à une équipe juste après l’avoir assignée à un coéquipier individuel supprime cette affectation individuelle. Si la logique de votre workflow assigne d’abord à un coéquipier puis à une équipe dans la même étape ou une étape suivante, l’affectation à l’équipe remplacera celle à l’individu. Pour éviter cela, assurez-vous que votre workflow ne réalise pas les deux affectations consécutivement sauf si l’affectation au niveau équipe est intentionnelle.

Pour corriger cela :


Les paramètres Fin AI Agent pourraient-ils bloquer mon workflow ?

Fin AI Agent peut parfois interagir avec les Workflows de manière à provoquer des comportements inattendus. Voici comment résoudre les problèmes courants liés à Fin dans les workflows :

Priorisation de Fin et des Workflows avec Simple deployment

Lorsque le Simple deployment de Fin et les workflows sont activés pour la même audience, Simple deployment a la priorité et seul Fin répondra. Pour permettre le déclenchement des workflows, ajustez le ciblage d’audience pour qu’ils ne se chevauchent pas, ou désactivez Simple deployment.

Activation du CSAT pour les clôtures de Workflow Fin

Les workflows de 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 de la 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 workflow.

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 utilisateurs ou canaux si le ciblage est trop restrictif. Par exemple, les workflows limités aux utilisateurs connectés excluront les leads. Pour inclure tous les utilisateurs :

  • Mettez à jour l’audience du workflow pour inclure à la fois Users et Leads.

Correction étape par étape pour CSAT non envoyé dans les workflows Fin-first

  1. Ouvrez le workflow Fin-first dans Workflow Builder.

  2. Modifiez l’étape "Let Fin answer".

  3. Activez "Demander une évaluation de la conversation (CSAT)" et spécifiez quand l’envoyer (par exemple, après résolution confirmée ou inactivité).

  4. Enregistrez et activez le workflow. Note : Le CSAT Simple Automation ne s’applique qu’aux conversations répondues par un humain ; les workflows doivent gérer le CSAT pour les conversations résolues par Fin.

Utilisateurs sollicités par des questions répétitives

Les workflows configurés pour "Obtenir le contexte du problème en amont" peuvent amener les utilisateurs à être sollicités plusieurs fois pour les mêmes informations (par exemple, nom, email). Pour corriger cela, désactivez ce paramètre sous Fin AI Agent > Simple Automation > Obtenir le contexte du problème en amont pour les users et leads.

L’invite de capture d’email n’apparaît 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 "Obtenir le contexte du problème en amont" : Si Obtenir le contexte du problème en amont est activé sous Fin AI Agent > Simple Automation pour les Leads, cela peut supprimer les étapes de capture d’email dans Fin pour les workflows Sales. Fin for 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 for Sales suppose qu’il collectera les coordonnées via son propre flux de qualification. Pour corriger cela, désactivez Obtenir le contexte du problème en amont pour les Leads sous Simple Automation et comptez plutôt sur une étape dédiée de capture d’email dans votre workflow.

  • Conflit de priorité de workflow : Un workflow orienté client à priorité plus élevée peut s’exécuter à la place de votre workflow de capture d’email. Vérifiez l’ordre de priorité des workflows et assurez-vous que votre workflow Fin for Sales est placé au-dessus de tout workflow général de capture ou de bienvenue qui pourrait intercepter la même audience.

  • Leads ayant 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 for 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 voir aux visiteurs 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.

Workflow Fin ne traitant pas 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 bien 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 destinataire prévue dans les filtres du workflow. De plus, vérifiez que le statut de transfert automatique est activé 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 a été définie dans le workflow ou via le ciblage d’audience. Ajouter l’email de support aux conditions de déclenchement du workflow peut aider à résoudre ce problème.

Transfert d’emails et règles de workflow

Lorsque les emails sont transférés via des listes de distribution, les conditions de domaine 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évenir les 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 garantir 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 domaine souvent associés aux phrases des clients.

  • Testez les descriptions avec des exemples de conversations.


Pourquoi mon workflow d'auto-fermeture ne fonctionne-t-il pas comme prévu ?

Les workflows d'auto-fermeture 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-fermeture ne se déclenche pas, ferme les conversations trop tôt ou est interrompu de manière inattendue.

Note : La fonction Auto-close s'applique uniquement aux conversations de workflow abandonnées. Les chats réguliers ou messages sortants en attente d'une réponse utilisateur ne sont pas considérés comme actifs et ne se fermeront pas automatiquement.

Configurer un workflow d'auto-fermeture

Pour créer un workflow d'auto-fermeture, allez dans Fin AI Agent Workflows dans votre application Intercom. Sélectionnez + Nouveau workflow et choisissez le modèle : Relancer les clients inactifs. Réglez le minuteur d'inactivité pour déterminer combien de temps attendre une réponse client avant de déclencher le workflow. La durée doit être comprise entre 3 secondes et 14 jours. Spécifiez les canaux (par exemple Web, iOS, Android, email, SMS) où ce workflow s'appliquera.
​
Pourquoi mon workflow d'auto-fermeture 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 peut avoir 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". Élargissez vos règles d'audience pour inclure tous les types de profils pertinents.

  • Si votre workflow d'auto-fermeture se déclenche 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 é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 cela, désactivez le déploiement Simple ou ajustez le ciblage de l'audience pour éviter le chevauchement.

  • Une action d'un coéquipier a interrompu 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 fermer ou taguer) 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 se déclenche alors qu'il ne devrait pas, les causes les plus courantes sont :

  • Passez en revue les règles d'audience — en particulier les conditions OU, qui ne nécessitent qu'une seule condition vraie. Un client peut correspondre au workflow par inadvertance si une condition est remplie.

  • 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 pas du tout ?

Utiliser les Tags pour les fermetures de chat temporisées

Pour fermer les chats après une période spécifique, utilisez une approche basée sur les tags :

  • Ajoutez un tag de conversation (par exemple, "Agent?") lors de la sollicitation du client.

  • Retirez le tag si le client répond.

  • Configurez un workflow pour fermer les conversations avec ce tag après le temps spécifié.

  • Assurez-vous que les tags sont retirés lorsqu'une conversation est assignée à un agent pour éviter une fermeture prématurée.

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.

Vérifiez également la présence d'un paramètre intitulé "fermer les conversations Fin abandonnées après 3 minutes" dans le bloc "Let Fin Answer". Désactivez ce paramètre pour permettre aux conversations de rester ouvertes jusqu'à leur fermeture manuelle par un membre de l'équipe.

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 votre objectif est l'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.

  • Assurez-vous que l'option "Si Fin a répondu à la question" est cochée dans les paramètres du workflow. Cela garantit l'auto-fermeture pour les nouvelles conversations.

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 prendre en compte 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 manière la plus fiable d'assurer la fermeture lors de flux complexes à branches multiples — ne comptez pas uniquement sur les 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 :

  1. Déclenchez le workflow à la visite de la page.

  2. Affichez un message avec un bouton.

  3. Exécutez le connecteur de données après que le bouton ait é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'article intégrées ajoutées via des étapes de Workflow ne s'afficheront pas pour les users. Pour garantir l'accès au contenu du Help Center aux utilisateurs mobiles, utilisez du texte avec lien hypertexte ou ajoutez un bouton URL pointant directement vers l'article.

Avez-vous trouvé la réponse à votre question ?