Passer au contenu principal

Run Simulations for Fin Procedures

Learn how to use Simulations to validate Fin Procedures, build confidence, and catch problems before they impact customers.

Écrit par Dawn

Simulations allow you to validate Fin Procedures, build confidence in your automation, and catch problems before they impact your customers. By modeling full conversations, simulations help your team handle high-volume or complex scenarios, such as cancellations and refunds, with certainty.

Designed to replace time-consuming manual checks, simulations help you identify issues or gradual changes in Fin's behavior as your business logic evolves.


Accessing simulations

Simulations are located within the testing panel of a Procedure. To access them:

  1. Open the Procedure you wish to test.

  2. Click Test in the top right corner of the canvas.

  3. Select the Simulations tab in the right-hand panel

Note: Accessing Simulations requires the following permissions:

  • "Can manage workspace data",

  • "Can access lead and user profile pages" and

  • "Can access lists of people, companies, and accounts".

If the Simulations button isn't responding, check with your workspace admin that these permissions are enabled for you in Settings > Workspace > Teammates.

Simulations bypass intent matching. Unlike Preview or live conversations, simulations don't check your 'When to use this Procedure' instructions, they assume the Procedure has already been triggered and run it directly. This makes simulations ideal for testing execution logic in isolation.

Important:

  • Preview shows the full customer-facing experience, using it while your procedure is live can expose messages to real customers.

  • Simulations run the procedure in the background with no customer-facing output, making them the safest way to validate logic before going live. Use Preview for quick spot checks; use Simulations before every publish.


Creating a simulation

You can create a simulation in two ways: using AI-generated suggestions for a quick start, or manually defining the scenario for full control.

  • AI-generated simulations: Use these to quickly cover common or expected customer scenarios based on your instructions. Fin AI generates "ready-made" starter tests to save you time.

  • Manual simulations: Use these when you need precise control over data, specific edge cases, or particular branches in your logic.

AI-generated simulations

Based on your instructions, Fin AI will generate starter tests to help you quickly create "ready-made" simulations.

  1. Open the Simulations tab in the right-hand panel of your Procedure.

  2. Under Suggested for these instructions, review the list of proposed scenarios (e.g., "Full cancellation request").

  3. Click the Play icon next to a suggestion to run it instantly.

  4. Once a simulation is created or accepted from the suggestions, it will appear in your list. You can then click Run all to execute all of your saved simulations at once.

Manually created simulations

You can also build a simulation from scratch to test specific edge cases based on the Procedure instructions.

  1. In the Simulations tab, click + New.

  2. Simulation name: Give your simulation a clear title.

  3. Simulate as: Choose a specific user or brand to test personalization. You can select from a dropdown list of real users in your workspace.

  4. Customer's opening message: Enter the first message the customer sends (e.g., "I need help with my order"). You can also attach an image, such as a screenshot of an error, to test how Fin handles visual context.

  5. Additional details: Provide guidance regarding the customer's situation or specific actions they have taken.

Select a channel

Simulations allow you to select the channel Fin will use for this simulation, so you can test how Fin behaves. Use the channel dropdown to switch between Messenger and Email before running your simulation.

Note: Fin behaves differently depending on the channel. In Email, Fin aggregates multiple pieces of information into a single response rather than sending several messages. Guidance and Content targeting can also be configured per channel - for example, Email responses can be set to use a more formal tone or include a specific introduction.

Define available data

The Customer data available to Fin section allows you to define the data Fin has access to during the test. This ensures you are testing against precise data values rather than relying on vague descriptions.

  • Simulation time: Use this to define "when" the scenario is happening. Setting a specific date and time allows you to test time-sensitive logic, such as checking if a customer is within a 30-day refund window.

  • Attributes and Data Connectors: This section pre-populates with the attributes referenced in your Procedure. Update these values (e.g., set People.Plan to "Pro") to test different branching outcomes.

Note: To ensure your simulation runs accurately, place data based on when Fin should "know" it:

  • Use Attributes: If Fin is supposed to already know the information at the start of the conversation (e.g., the customer's current Plan or Sign-up date).

  • Use Additional details: If the information is meant to be provided by the customer during the conversation (e.g., the customer provides their "Order ID" in a follow-up response). This allows you to test if Fin correctly captures and stores that data in an attribute.

Note:

  • Data Connectors don't use live user data in simulations. Instead of calling your external system, Fin uses the test values you define in the Customer data available to Fin section. Make sure you've populated your Data Connector fields with the values you want Fin to use during the test — otherwise the connector will return empty results.

  • The Customer data available to Fin section only shows and retains attributes that are explicitly referenced in your Procedure's instructions or a code block. If you manually add an attribute using the + Add attribute button but that attribute isn't referenced anywhere in the Procedure, the system will not save it — it disappears after you save because it has no effect on the simulation. To add a custom value that persists, make sure the attribute is first used in the Procedure itself.

Evaluate Fin's behavior

Define the criteria that must be true for the test to pass. Click + Add criteria and select:

  • Fin reply: Spécifiez ce que Fin doit (ou ne doit pas) dire pendant la conversation.

  • Attributes: Vérifiez si un attribut a été défini, n'a pas été défini, était égal à, ou n'était pas égal à une valeur spécifique.

  • Data connector: Vérifiez si un connector est déclenché, n'est pas déclenché, ou est déclenché exactement X fois.

  • Instruction outcome : Vérifiez si la conversation a atteint une conclusion spécifique, comme la fin, le transfert à un collègue, ou d'autres résultats tels que le passage à une procédure différente.

Une fois configuré, cliquez sur Save.

Note: Lorsque vous cliquez sur Save, Fin utilise l'IA pour examiner votre formulaire de simulation. Si les instructions sont floues ou si les critères de réussite sont incohérents, vous verrez des recommandations pour améliorer le test afin d'obtenir des résultats plus précis.


Meilleures pratiques pour la couverture des simulations

Pour tirer le meilleur parti des simulations, structurez votre suite de tests autour de ces principes :

  • Testez une branche par simulation. Si votre Procedure a des Conditions ou des sous-procédures avec plusieurs chemins, créez une simulation distincte pour chaque branche. Cela constitue un filet de sécurité de régression — si une modification future casse un chemin spécifique, vous le détecterez immédiatement.

  • Couvrez à la fois les chemins de réussite et d'échec pour les Data Connectors. Exécutez une simulation où votre connector renvoie des données valides, et une autre où il ne renvoie rien ou échoue. Cela vérifie que votre logique de secours (par ex., une étape @Condition gérant une réponse vide) fonctionne correctement.

  • Exécutez toutes les simulations avant de publier les modifications. Après avoir modifié une Procedure, cliquez sur Run all pour ré-exécuter l'ensemble de votre suite avant la mise en production. Toute simulation qui échoue nouvellement signale une régression introduite par votre modification.

  • Utilisez des noms de simulation descriptifs. Nommez chaque simulation d'après le scénario qu'elle représente (par ex. « Full refund — within 30 days » ou « Cancellation — no order found »). Cela facilite l'identification du test correspondant à chaque chemin lors de l'examen des résultats.

Stratégie de test : happy path, risk path et cas limites

Une suite de simulations équilibrée couvre trois types de scénarios. Ensemble, ils vous donnent la confiance que votre Procedure fonctionne correctement dans des conditions normales, gère les échecs avec grâce, et ne casse pas lorsque les clients se comportent de manière inattendue.

  • Happy path

    Le happy path représente le flux idéal et ininterrompu — un client qui fournit exactement les bonnes informations et remplit toutes les conditions pour que Fin complète la Procedure avec succès. Commencez toujours par là. Si le happy path échoue, déboguer des chemins plus complexes devient beaucoup plus difficile.

    Exemple : Un client demande un remboursement dans la fenêtre de 30 jours, dispose d'un ID de commande valide, et le Data Connector renvoie les détails de sa commande. Fin traite le remboursement et le confirme en une seule fois.

  • Risk path

    Les risk paths testent les scénarios les plus susceptibles d'échouer en production — généralement lorsque des données externes sont manquantes, que des conditions ne sont pas remplies, ou qu'une branche de secours doit se déclencher. Ce sont les tests qui protègent vos clients contre des réponses incorrectes ou incomplètes.

    Examples: Le Data Connector ne renvoie aucune commande (testez que Fin demande au client son ID de commande). Le client est hors de la fenêtre de remboursement (testez que Fin communique la bonne politique et propose le bon transfert). Un attribute est vide lorsqu'une étape Condition l'évalue (testez que le chemin de secours de Fin se déclenche correctement).

  • Edge cases

    Les cas limites couvrent des entrées inhabituelles ou en condition limite qui sont techniquement valides mais peu fréquentes. Ces tests sont particulièrement importants pour les Procedures avec une logique sensible au temps, des seuils numériques, ou des saisies libres des clients.

    Examples: Un client demande un remboursement exactement le jour 30 (la limite de la fenêtre). Un client envoie un message d'ouverture ambigu qui pourrait correspondre à plusieurs intentions. Un client fournit son ID de commande dans un format inattendu ou inclut du texte supplémentaire avec celui-ci.

Tip: Utilisez des noms de simulation descriptifs pour indiquer à quelle catégorie appartient chaque test — par exemple, « Refund — happy path », « Refund — no order found (risk) », ou « Refund — boundary day 30 (edge) ». Cela facilite la sélection des lacunes de votre couverture en un coup d'œil.


Exécution et examen des résultats

Une fois que vous exécutez un test, il apparaît dans le panneau Tests à droite avec un indicateur d'état :

  • Running: Le test est en cours d'exécution.

  • Passed: Le test a été exécuté et a satisfait tous les critères de réussite définis.

  • Failed: Le test a été exécuté mais n'a pas satisfait les critères de réussite définis.

  • Queued: Le test a été initié mais attend que la simulation précédente se termine avant de s'exécuter.

Pour enquêter sur un résultat, cliquez sur See conversation. Cela ouvre la transcription complète des échanges entre le client simulé et Fin, ce qui permet de voir exactement comment le flux s'est déroulé et pourquoi un test a réussi ou échoué.


Débogage d'une Simulation échouée

Lorsqu'une simulation est marquée Failed, la transcription disponible via See conversation contient tout ce dont vous avez besoin pour identifier la cause première. Voici comment la lire efficacement :

  • Fin's thoughts

    À chaque étape de la conversation, développez le raisonnement de Fin pour voir comment il a interprété le message du client, quelle étape de la Procedure il exécutait, et quelle décision il a prise. Si Fin a pris un chemin inattendu, Fin's thoughts vous montrera généralement exactement où son interprétation a divergé de votre intention. Recherchez des étapes où l'interprétation par Fin d'un attribute ou d'une condition ne correspond pas à ce que vous attendiez.

  • Conversation events

    Les conversation events apparaissent en ligne dans la transcription et montrent des actions de bas niveau telles que les mises à jour d'attributs, les appels de Data Connector, et les déclencheurs de transfert. Utilisez-les pour vérifier que les bons connectors se sont déclenchés au bon moment et que les attributs ont été définis aux valeurs attendues avant chaque étape de branchement.

  • Pinpointing the failure

    Recoupez ce que vous voyez dans Fin's thoughts et les conversation events avec vos critères de réussite définis. Un schéma courant est une étape Condition évaluée sur la mauvaise branche — généralement parce qu'un attribute était vide ou avait une valeur inattendue. Vérifiez votre configuration Customer data available to Fin pour vous assurer que tous les attributs requis ont été renseignés avant l'exécution de la simulation.

Tip: Après avoir identifié la cause, ajustez votre Procedure ou la configuration de la simulation et cliquez sur Run sur la même simulation pour la retester immédiatement. Vous n'avez pas besoin de créer une nouvelle simulation — celle existante conserve sa configuration.


Limites d'utilisation des simulations

Il existe une limite du nombre de simulations que vous pouvez exécuter chaque mois. Cette limite s'applique au niveau de l'espace de travail et se réinitialise le premier jour de chaque mois civil.

Chaque espace de travail reçoit un quota mensuel de simulations. Le quota est basé sur le segment de volume de conversation de votre espace de travail, les clients plus importants recevant des quotas plus élevés.

Le quota de simulations est basé sur le volume de conversations de votre espace de travail dans Intercom.

  • Nous attribuons votre espace de travail à un segment en utilisant le nombre de conversations du dernier mois civil.

  • Votre segment est réévalué chaque mois et votre quota reflétera le volume de conversations du mois le plus récent.

  • Si votre volume de conversations augmente ou diminue, votre quota de simulations peut changer lors du prochain cycle mensuel.

Conversation Volume Segment

Limite de simulations par mois

Under 1K

250

1K–15K

1 000

15K–100K

1 750

100K–1M

5 000

1M+

12 500

Surveillance de votre utilisation

Pour vous aider à gérer vos tests, Fin fournit des indicateurs visuels dans l'onglet Simulations :

Avertissement d'utilisation

Lorsque votre espace de travail atteint 80% de son quota mensuel, une bannière d'avertissement jaune apparaît. Elle affiche votre utilisation actuelle (par ex. « 85/100 ») et vous rappelle quand le quota sera réinitialisé.

Quota atteint

Une fois que vous atteignez 100% de votre quota mensuel, un message d'erreur rouge s'affiche. Vous ne pourrez pas lancer d'autres simulations avant le début du mois suivant.

Remarque : si vous atteignez votre quota, vous pouvez toujours consulter les résultats et les transcriptions des simulations précédentes en cliquant sur Voir la conversation, mais les boutons Exécuter et Tout exécuter seront désactivés.


FAQ

Les simulations interagissent-elles avec mes API en direct ou des données externes ?

Non. Contrairement à l'outil Aperçu, les simulations n'appellent pas de véritables API ni de systèmes externes (comme Shopify ou Stripe). Il n'est pas possible de lire ou de modifier des données dans une API externe pendant une simulation. Cela vous permet de tester la logique en toute sécurité sans impacter les données réelles.

Pourquoi utiliser les Simulations plutôt que des tests manuels ?

Les simulations vous permettent de valider les Procedures à grande échelle et d'assurer que Fin fonctionne de manière fiable dans des scénarios complexes et à haut risque — contrairement aux tests manuels, mieux adaptés aux vérifications ponctuelles ou aux revues de configuration. Lancer des Simulations avant chaque lancement vous aide à détecter tôt les comportements inattendus.

Que se passe-t-il si une Simulation échoue ?

Une Simulation échouée peut être examinée en détail : ouvrez la conversation simulée pour comprendre pourquoi Fin n'a pas agi comme prévu, ajustez votre Procedure et relancez la Simulation sans impact sur les clients.

Pourquoi ma simulation est-elle marquée « Échouée » alors que Fin a résolu le problème ?

Qu'une Simulation soit marquée « Échouée » alors que Fin a résolu le problème signifie généralement que vos Critères de réussite sont trop stricts. Par exemple, si vous exigez que Fin « Demande un ID de commande », mais que Fin est capable de trouver l'ID automatiquement, le test échouera parce que Fin a évité la question. Actualisez vos critères pour vous concentrer sur le résultat final (par ex. « Procedure terminée ») plutôt que d'imposer des étapes intermédiaires spécifiques.

Fin s'arrête en cours de simulation. Pourquoi se bloque-t-il ?

Fin s'arrête souvent s'il rencontre une impasse dans vos instructions, comme la vérification d'une variable vide (par ex. People.signed_up). Si vous n'avez pas indiqué à Fin quoi faire lorsque des données sont manquantes, il s'arrêtera. Assurez-vous que vos instructions incluent un plan de secours, par exemple : « Vérifier si la variable contient une valeur. Si elle est vide, demander la date au client. »

Où dois-je saisir des données de test comme « dates d'inscription » ou « historique des commandes » ?

Les données de test comme les dates d'inscription ou l'historique des commandes doivent être saisies dans la section Customer data available to Fin de la configuration de la simulation — pas dans le message d'ouverture du Customer ou les champs Détails supplémentaires, car Fin pourrait les manquer. Saisissez des valeurs exactes (par ex. 2024-06-01) dans les Attributs ou Variables spécifiques que vous testez.

Mon outil fonctionne en conditions réelles, mais échoue dans la simulation. Pourquoi ?

Les simulations ne récupèrent pas de données réelles depuis des systèmes externes, donc votre Data Connector ne renverra pas de résultats en direct comme dans une conversation réelle. Si votre connecteur fonctionne en production mais échoue en simulation, c'est probablement parce que les valeurs de retour attendues n'ont pas été définies dans la section Customer data available to Fin. Ajoutez les données que votre connecteur renverrait normalement comme valeurs de test, puis relancez la simulation.

Les Simulations sont-elles facturées séparément des Procedures ?

Les Simulations sont incluses avec Procedures et ne font pas l'objet d'une ligne de facturation distincte. Vous n'encourrez pas de frais supplémentaires pour l'exécution de simulations.

Pourquoi devrais-je tester ma Procedure par Email ?

Tester votre Procedure par Email valide les comportements spécifiques au canal qui diffèrent de Messenger. Sur Email, Fin regroupe plusieurs informations dans un seul courriel au lieu d'envoyer plusieurs messages. Les Guidance et Content peuvent également être ciblés selon les canaux : par exemple, les réponses Email peuvent être configurées pour adopter un ton plus formel ou inclure une introduction spécifique. Simuler des conversations par Email vous permet de valider ce comportement et de déployer en toute confiance.

Pourquoi y a-t-il une limite sur le nombre d'exécutions de Simulation ?

Chaque exécution de simulation nécessite des ressources pour générer des prédictions IA précises. Nous fournissons une allocation mensuelle afin que vous puissiez tester vos Procedures librement pour les cas d'utilisation standards tout en évitant que des usages extrêmes n'engendrent des coûts incontrôlables.

Puis-je simuler une sous-procedure indépendamment ?

Non. Les sous-procedures n'ont pas leur propre panneau de simulation et ne peuvent pas être exécutées isolément. Pour tester une sous-procedure, lancez une simulation sur la Procedure parente et configurez le scénario pour que le chemin d'exécution atteigne la sous-procedure — définissez le message du client, les attributs et les détails supplémentaires pour déclencher la branche qui l'appelle.

Si vous avez plusieurs sous-procedures dans le même parent, créez une simulation distincte pour chacune, chaque simulation couvrant le scénario qui mène à l'appel de cette sous-procedure.

Mon Data Connector renvoie des résultats vides en simulation. Que dois-je faire ?

Des résultats vides du Data Connector dans une simulation sont généralement causés par des données de test manquantes. Les simulations ne récupèrent pas de données en direct depuis des systèmes externes : vous devez définir les valeurs que votre Data Connector doit renvoyer dans la section Customer data available to Fin de la configuration de la simulation. Vérifiez que vous avez rempli les champs Data Connector concernés avec les valeurs de test que vous voulez que Fin utilise.

Si vous testez intentionnellement le chemin « le connecteur ne renvoie rien », ce comportement est attendu — et c'est précisément ce que vous devez tester. Assurez-vous que votre Procedure comporte une étape @Condition de repli qui gère les réponses vides du connecteur :

Si le connecteur renvoie des résultats vides même pour un utilisateur ayant des données réelles, vérifiez que votre contact de test possède un external_id valide correspondant à l'identifiant client de votre système externe.

Combien de simulations puis-je exécuter par mois ?

L'allocation mensuelle d'exécutions de Simulation dépend du volume de conversations de votre espace de travail dans Intercom au cours du mois civil précédent. La limite s'applique au niveau de l'espace de travail et est réinitialisée le premier jour de chaque mois :

Segment de volume de conversation

Limite de simulations par mois

Moins de 1K

250

1K–15K

1 000

15K–100K

1 750

100K–1M

5 000

1M+

12 500

Quand mon quota de simulations est-il réinitialisé ?

Votre quota de simulations est réinitialisé le premier jour de chaque mois calendaire, quel que soit le moment où vous avez rejoint ou le nombre de simulations utilisées. Les runs non utilisés ne sont pas reportés : votre quota repart à zéro chaque mois.

Puis-je augmenter mon quota de simulations ?

Les quotas de simulations sont définis automatiquement en fonction du volume de conversations de votre espace de travail et réévalués au début de chaque mois calendaire. Si le volume de conversations augmente, votre quota augmentera lors du cycle mensuel suivant : il n'y a pas d'option pour acheter manuellement des runs supplémentaires ou augmenter votre quota en dehors de ce système de niveaux. Si vous atteignez votre quota mensuel avant la date de réinitialisation, vous pouvez toujours consulter les résultats et transcriptions des simulations précédentes, mais les boutons Exécuter et Tout exécuter seront désactivés jusqu'à la réinitialisation de votre quota.

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