Zum Hauptinhalt springen

Run Simulations for Fin Procedures

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

Verfasst von 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: Geben Sie an, was Fin während des Gesprächs sagen darf (oder nicht).

  • Attributes: Überprüfen Sie, ob ein Attribut gesetzt wurde, nicht gesetzt wurde, einem bestimmten Wert entsprach oder nicht entsprach.

  • Data connector: Überprüfen Sie, ob ein Connector ausgelöst wurde, nicht ausgelöst wurde oder genau X Mal ausgelöst wurde.

  • Instruction outcome: Prüfen Sie, ob das Gespräch ein bestimmtes Ergebnis erreicht hat, z. B. Abschluss, Übergabe an einen Kollegen oder andere Ergebnisse wie der Wechsel zu einer anderen Procedure.

Sobald konfiguriert, klicken Sie auf Save.

Note: Wenn Sie auf Save klicken, verwendet Fin AI, um Ihr Simulationsformular zu prüfen. Wenn die Anweisungen unklar sind oder die Erfolgskriterien inkonsistent sind, erhalten Sie Empfehlungen zur Verbesserung des Tests für genauere Ergebnisse.


Beste Praktiken für Simulationsabdeckung

Um das Beste aus Simulationen herauszuholen, strukturieren Sie Ihre Test-Suite nach folgenden Grundsätzen:

  • Testen Sie pro Simulation einen Zweig. Wenn Ihre Procedure Bedingungen oder Unterprozeduren mit mehreren Pfaden hat, erstellen Sie für jeden Zweig eine separate Simulation. So entsteht ein Rückversicherungsschutz für Regressionen — wenn eine zukünftige Änderung einen bestimmten Pfad bricht, merken Sie es sofort.

  • Decken Sie sowohl Erfolgs- als auch Fehlerpfade für Data Connectors ab. Führen Sie eine Simulation aus, bei der Ihr Connector gültige Daten zurückgibt, und eine weitere, bei der er nichts zurückgibt oder fehlschlägt. So stellen Sie sicher, dass Ihre Fallback-Logik (z. B. ein @Condition-Schritt, der auf eine leere Antwort reagiert) korrekt funktioniert.

  • Führen Sie alle Simulationen aus, bevor Sie Änderungen veröffentlichen. Nachdem Sie eine Procedure bearbeitet haben, klicken Sie auf Run all, um Ihre gesamte Suite erneut auszuführen, bevor Sie live gehen. Jede Simulation, die neu fehlschlägt, weist auf eine durch Ihre Änderung eingeführte Regression hin.

  • Verwenden Sie beschreibende Simulationsnamen. Benennen Sie jede Simulation nach dem Szenario, das sie darstellt (z. B. „Full refund — within 30 days“ oder „Cancellation — no order found“). So erkennen Sie beim Überprüfen der Ergebnisse leicht, welcher Test welchen Pfad abdeckt.

Teststrategie: Happy Path, Risk Path und Edge Cases

Ein ausgewogenes Simulationspaket deckt drei Szenariotypen ab. Zusammen geben sie Ihnen das Vertrauen, dass Ihre Procedure unter normalen Bedingungen korrekt funktioniert, Fehler elegant handhabt und nicht zusammenbricht, wenn Kunden unerwartet reagieren.

  • Happy path

    Der Happy Path steht für den idealen, unterbrechungsfreien Ablauf — ein Kunde, der genau die richtigen Informationen liefert und alle Bedingungen erfüllt, damit Fin die Procedure erfolgreich abschließt. Beginnen Sie immer hier. Scheitert der Happy Path, wird das Debuggen komplexerer Pfade deutlich schwieriger.

    Beispiel: Ein Kunde beantragt eine Rückerstattung innerhalb des 30-Tage-Fensters, hat eine gültige Bestell-ID und der Data Connector liefert seine Bestelldaten. Fin bearbeitet die Rückerstattung und bestätigt sie in einem Durchgang.

  • Risk path

    Risk Paths testen die Szenarien, die in der Produktion am ehesten schiefgehen — typischerweise dort, wo externe Daten fehlen, Bedingungen nicht erfüllt sind oder ein Fallback-Zweig greifen muss. Diese Tests schützen Ihre Kunden davor, falsche oder unvollständige Antworten zu erhalten.

    Beispiele: Der Data Connector liefert keine Bestellung (testen Sie, dass Fin den Kunden nach der Bestell-ID fragt). Der Kunde liegt außerhalb des Rückerstattungszeitraums (testen Sie, dass Fin die richtige Richtlinie kommuniziert und die passende Übergabe anbietet). Ein Attribut ist leer, wenn ein Condition-Schritt es auswertet (testen Sie, dass Fins Fallback-Zweig korrekt ausgelöst wird).

  • Edge cases

    Edge Cases umfassen ungewöhnliche oder Grenzfall-Eingaben, die technisch gültig, aber selten sind. Diese Tests sind besonders wichtig für Procedures mit zeitkritischer Logik, numerischen Schwellenwerten oder frei-textlichen Kundeneingaben.

    Beispiele: Ein Kunde beantragt eine Rückerstattung genau am 30. Tag (Grenze des Fensters). Ein Kunde sendet eine mehrdeutige Anfangsnachricht, die mehrere Intents treffen könnte. Ein Kunde gibt seine Bestell-ID in einem unerwarteten Format an oder fügt zusätzlichen Text hinzu.

Tipp: Verwenden Sie beschreibende Simulationsnamen, um zu kennzeichnen, zu welcher Kategorie jeder Test gehört — zum Beispiel „Refund — happy path“, „Refund — no order found (risk)“ oder „Refund — boundary day 30 (edge)“. So finden Sie Lücken in Ihrer Abdeckung auf einen Blick leichter.


Ausführen und Überprüfen von Ergebnissen

Sobald Sie einen Test ausführen, erscheint er im Tests-Panel auf der rechten Seite mit einer Statusanzeige:

  • Running: Der Test wird gerade ausgeführt.

  • Passed: Der Test wurde ausgeführt und hat alle definierten Erfolgskriterien erfüllt.

  • Failed: Der Test wurde ausgeführt, hat die definierten Erfolgskriterien jedoch nicht erfüllt.

  • Queued: Der Test wurde gestartet, wartet jedoch darauf, dass die vorherige Simulation abgeschlossen ist, bevor er ausgeführt wird.

Um ein Ergebnis zu untersuchen, klicken Sie auf See conversation. Dadurch wird das vollständige Hin und Her-Transkript zwischen dem simulierten Kunden und Fin geöffnet, sodass Sie genau sehen können, wie der Ablauf verlief und warum ein Test bestanden oder fehlgeschlagen ist.


Debugging einer fehlgeschlagenen Simulation

Wenn eine Simulation als Failed markiert ist, enthält das Transkript, das über See conversation verfügbar ist, alles, was Sie zur Identifizierung der Ursache benötigen. So lesen Sie es effektiv:

  • Fin's thoughts

    Erweitern Sie bei jedem Schritt des Gesprächs Fins Begründung, um zu sehen, wie es die Nachricht des Kunden interpretiert hat, welchen Procedure-Schritt es ausgeführt hat und welche Entscheidung es getroffen hat. Wenn Fin einen unerwarteten Pfad genommen hat, zeigt Ihnen Fin's thoughts normalerweise genau, wo seine Interpretation von Ihrer Absicht abwich. Achten Sie auf Schritte, in denen Fins Interpretation eines Attributs oder einer Bedingung nicht mit Ihren Erwartungen übereinstimmt.

  • Conversation events

    Conversation Events erscheinen inline im Transkript und zeigen niedrigstufige Aktionen wie Attribut-Updates, Data Connector-Aufrufe und Handoff-Trigger. Verwenden Sie diese, um zu überprüfen, dass die richtigen Connectoren zur richtigen Zeit ausgelöst wurden und dass Attribute vor jedem Verzweigungsschritt auf die erwarteten Werte gesetzt wurden.

  • Pinpointing the failure

    Vergleichen Sie, was Sie in Fin's thoughts und Conversation Events sehen, mit Ihren definierten Erfolgskriterien. Ein typisches Muster ist, dass ein Condition-Schritt auf den falschen Zweig auswertet — typischerweise weil ein Attribut leer war oder einen unerwarteten Wert hatte. Überprüfen Sie Ihre Customer data available to Fin-Einstellungen, um sicherzustellen, dass alle erforderlichen Attribute vor dem Start der Simulation gefüllt waren.

Tip: Nachdem Sie die Ursache identifiziert haben, passen Sie Ihre Procedure oder Simulationseinstellungen an und klicken Sie auf Run für dieselbe Simulation, um sofort erneut zu testen. Sie müssen keine neue Simulation erstellen — die vorhandene behält ihre Konfiguration bei.


Beschränkungen der Simulationsnutzung

Es gibt eine Begrenzung der Anzahl von Simulationen, die Sie pro Monat ausführen können. Diese Begrenzung gilt auf Arbeitsbereichsebene und wird am ersten Tag jedes Kalendermonats zurückgesetzt.

Jeder Workspace erhält eine monatliche Zuteilung von Simulationsläufen. Die Zuteilung basiert auf dem Gesprächsvolumen-Segment Ihres Workspaces; größere Kunden erhalten höhere Zuteilungen.

Die Simulationszuteilung basiert auf dem Gesprächsvolumen Ihres Workspaces in Intercom.

  • Wir ordnen Ihren Workspace einem Segment anhand der Anzahl der Gespräche im letzten Kalendermonat zu.

  • Ihr Segment wird monatlich neu bewertet und Ihre Zuteilung spiegelt das Gesprächsvolumen des letzten Monats wider.

  • Wenn Ihr Gesprächsvolumen steigt oder sinkt, kann sich Ihre Simulationszuteilung im nächsten monatlichen Zyklus ändern.

Conversation Volume Segment

Simulationslimit pro Monat

Unter 1K

250

1K–15K

1.000

15K–100K

1.750

100K–1M

5.000

1M+

12.500

Überwachung Ihrer Nutzung

Um Ihnen bei der Verwaltung Ihrer Tests zu helfen, bietet Fin in der Registerkarte „Simulations" visuelle Hinweise:

Usage warning

Wenn Ihr Arbeitsbereich 80 % seines monatlichen Limits erreicht, erscheint ein gelbes Warnbanner. Es zeigt Ihre aktuelle Nutzung (z. B. „85/100") an und erinnert Sie daran, wann das Limit zurückgesetzt wird.

Limit reached

Sobald Sie 100 % Ihres monatlichen Limits erreicht haben, erscheint eine rote Fehlermeldung. Sie können bis zum Beginn des nächsten Monats keine weiteren Simulationen durchführen.

Hinweis: Wenn Sie Ihr Limit erreicht haben, können Sie weiterhin frühere Simulationsergebnisse und Transkripte über „See conversation" einsehen, aber die Schaltflächen „Run" und „Run all" sind deaktiviert.


FAQs

Interagieren Simulationen mit meinen Live-APIs oder externen Daten?

Nein. Im Gegensatz zum Preview-Tool rufen Simulationen keine tatsächlichen APIs oder externen Systeme (wie Shopify oder Stripe) auf. Es ist nicht möglich, während einer Simulation aus einer externen API zu lesen oder Daten darin zu ändern. So können Sie Logik sicher testen, ohne reale Daten zu beeinflussen.

Warum sollte ich Simulationen statt manueller Tests verwenden?

Simulationen ermöglichen es Ihnen, Procedures im großen Maßstab zu validieren und sicherzustellen, dass Fin in komplexen, risikoreichen Szenarien zuverlässig arbeitet — im Gegensatz zu manuellen Tests, die sich am besten für schnelle Stichproben oder Konfigurationsprüfungen eignen. Durch das Ausführen von Simulationen vor jedem Launch können Sie unerwartetes Verhalten frühzeitig erkennen.

Was passiert, wenn eine Simulation fehlschlägt?

Eine fehlgeschlagene Simulation kann vollständig überprüft werden — öffnen Sie die simulierte Konversation, um zu verstehen, warum Fin nicht wie erwartet reagiert hat, passen Sie Ihre Procedure an und führen Sie die Simulation erneut durch, ohne Kunden zu beeinträchtigen.

Warum ist meine Simulation als „Failed" markiert, obwohl Fin das Problem erfolgreich gelöst hat?

Eine Simulation, die als „Failed" markiert ist, obwohl Fin das Problem gelöst hat, bedeutet normalerweise, dass Ihre Success Criteria zu starr sind. Wenn Sie beispielsweise verlangen, dass Fin „Ask for an Order ID" muss, Fin die ID jedoch automatisch findet, wird der Test fehlschlagen, weil Fin die Frage übersprungen hat. Aktualisieren Sie Ihre Kriterien, um sich auf das Endergebnis (z. B. „Procedure finished") zu konzentrieren, anstatt bestimmte Zwischenschritte vorzuschreiben.

Fin bricht die Simulation mitten drin ab. Warum bleibt es hängen?

Fin stoppt oft, wenn es in Ihren Anweisungen auf eine „Sackgasse" stößt, z. B. wenn eine überprüfte Variable leer ist (z. B. People.signed_up). Wenn Sie Fin nicht gesagt haben, was zu tun ist, wenn Daten fehlen, wird es anhalten. Stellen Sie sicher, dass Ihre Anweisungen einen „Fallback"-Plan enthalten, z. B.: „Prüfen Sie, ob die Variable einen Wert hat. Wenn sie leer ist, fragen Sie den Kunden nach dem Datum."

Wo soll ich Testdaten wie „Sign up dates" oder „Order history" eingeben?

Testdaten wie Anmeldedaten oder Bestellverlauf sollten im Abschnitt „Customer data available to Fin" der Simulationskonfiguration eingegeben werden — nicht in der Eröffnungsnachricht des Kunden oder in den Feldern „Additional details", da Fin sie möglicherweise übersieht. Geben Sie genaue Werte (z. B. 2024-06-01) in die spezifischen Attributes oder Variables ein, die Sie testen.

Mein Tool funktioniert im echten Leben, schlägt aber in der Simulation fehl. Warum?

Simulationen rufen keine echten Daten aus externen Systemen ab, daher liefert Ihr Data Connector in der Simulation keine Live-Ergebnisse wie in einer echten Konversation. Wenn Ihr Connector in Live-Konversationen funktioniert, aber in der Simulation fehlschlägt, liegt das wahrscheinlich daran, dass die erwarteten Rückgabewerte nicht im Abschnitt „Customer data available to Fin" definiert wurden. Fügen Sie die Daten, die Ihr Connector normalerweise zurückgibt, als Testwerte dort hinzu und führen Sie die Simulation erneut aus.

Werden Simulationen separat von Procedures abgerechnet?

Simulationen sind in Procedures enthalten und werden nicht als separater Posten abgerechnet. Für das Ausführen von Simulationen fallen keine zusätzlichen Gebühren an.

Warum sollte ich meine Procedure per E-Mail testen?

Das Testen Ihrer Procedure per E-Mail validiert kanal-spezifisches Verhalten, das sich vom Messenger unterscheidet. In E-Mails fasst Fin mehrere Informationen in einer einzigen E-Mail zusammen, anstatt mehrere Nachrichten zu senden. Guidance und Content können ebenfalls auf bestimmte Kanäle zugeschnitten werden — z. B. können E-Mail-Antworten formeller sein oder eine spezifische Einleitung enthalten. Das Simulieren von E-Mail-Konversationen ermöglicht es Ihnen, dieses Verhalten zu überprüfen und mit Vertrauen in E-Mail zu veröffentlichen.

Warum gibt es eine Begrenzung für Simulationsdurchläufe?

Jeder Simulationsdurchlauf benötigt Ressourcen, um präzise KI-Vorhersagen zu erzeugen. Wir bieten ein monatliches Kontingent, damit Sie Ihre Procedures für Standardfälle frei testen können, während extreme Nutzung vor unkontrollierten Kosten geschützt wird.

Kann ich eine Unterprozedur unabhängig simulieren?

Nein. Unterprozeduren haben kein eigenes Simulationspanel und können nicht isoliert ausgeführt werden. Um eine Unterprozedur zu testen, führen Sie eine Simulation für die übergeordnete Procedure aus und konfigurieren Sie das Szenario so, dass der Ausführungspfad die Unterprozedur erreicht — legen Sie die Kundenmeldung, Attributes und Additional details so fest, dass der spezifische Zweig ausgelöst wird.

Wenn Sie mehrere Unterprozeduren innerhalb desselben Elternteils haben, erstellen Sie für jede eine separate Simulation, die das Szenario abdeckt, das zu diesem Aufruf der Unterprozedur führt.

Mein Data Connector liefert in der Simulation leere Ergebnisse. Was soll ich tun?

Leere Data Connector-Ergebnisse in einer Simulation werden in der Regel durch fehlende Testdaten verursacht. Simulationen rufen keine Live-Daten aus externen Systemen ab — Sie müssen die Werte definieren, die Ihr Data Connector im Abschnitt „Customer data available to Fin" der Simulationskonfiguration zurückgeben soll. Überprüfen Sie, ob Sie die relevanten Data Connector-Felder mit den gewünschten Testwerten gefüllt haben.

Wenn Sie beabsichtigen, den Pfad „Connector returns nothing" zu testen, ist dies erwartetes Verhalten — und genau das, was Sie testen sollten. Stellen Sie sicher, dass Ihre Procedure einen Fallback-@Condition-Schritt hat, der leere Connector-Antworten behandelt:

Wenn der Connector selbst für einen Nutzer mit echten Daten leer zurückgibt, prüfen Sie, ob Ihr Testkontakt eine gültige external_id hat, die mit dem Kundenkennzeichen Ihres externen Systems übereinstimmt.

Wie viele Simulationen kann ich pro Monat durchführen?

Ihr monatliches Simulationskontingent hängt vom Gesprächsvolumen Ihres Arbeitsbereichs in Intercom im vorherigen Kalendermonat ab. Das Limit gilt auf Arbeitsbereichsebene und wird am ersten Tag jedes Monats zurückgesetzt:

Conversation Volume Segment

Simulation Limit per month

Unter 1K

250

1K–15K

1.000

15K–100K

1.750

100K–1M

5.000

1M+

12.500

Wann wird mein Simulationslimit zurückgesetzt?

Ihr Simulationskontingent wird am ersten Tag jedes Kalendermonats zurückgesetzt, unabhängig davon, wann Sie beigetreten sind oder wie viele Simulationen Sie durchgeführt haben. Nicht genutzte Durchläufe werden nicht übertragen — Ihr Kontingent beginnt jeden Monat neu.

Kann ich mein Simulationslimit erhöhen?

Simulationslimits werden automatisch basierend auf dem Konversationsvolumen Ihres Workspaces festgelegt und zu Beginn jedes Kalendermonats neu bewertet. Wenn Ihr Konversationsvolumen steigt, erhöht sich Ihr Kontingent im nächsten Monatszyklus — es gibt keine Möglichkeit, zusätzliche Durchläufe manuell zu kaufen oder Ihr Limit außerhalb dieses Stufensystems zu erhöhen. Wenn Sie Ihr monatliches Limit vor dem Rücksetzdatum erreichen, können Sie weiterhin frühere Simulationsergebnisse und Transkripte einsehen, aber die Schaltflächen „Ausführen" und „Alle ausführen" werden deaktiviert, bis Ihr Kontingent zurückgesetzt ist.

Hat dies deine Frage beantwortet?