Simulationen ermöglichen es Ihnen, Fin-Prozeduren zu validieren, Vertrauen in Ihre Automatisierung aufzubauen und Probleme zu erkennen, bevor sie Ihre Nutzer betreffen. Durch die Modellierung vollständiger Gespräche helfen Simulationen Ihrem Team, auch bei hohem Volumen oder komplexen Szenarien wie Stornierungen und Rückerstattungen sicher zu agieren.

Simulationen wurden entwickelt, um zeitaufwändige manuelle Prüfungen zu ersetzen und helfen Ihnen, Probleme oder schrittweise Änderungen im Verhalten von Fin zu erkennen, während sich Ihre Geschäftslogik weiterentwickelt.

Zugriff auf Simulationen

Simulationen befinden sich im Testbereich einer Prozedur. So greifen Sie darauf zu:

Öffnen Sie die Prozedur, die Sie testen möchten.
Klicken Sie oben rechts auf der Arbeitsfläche auf Test.
Wählen Sie den Tab Simulationen im rechten Bereich aus.

Hinweis: Für den Zugriff auf Simulationen sind folgende Berechtigungen erforderlich:

„Can manage workspace data“,
„Can access lead and user profile pages“ und
„Can access lists of people, companies, and accounts“.

Wenn die Schaltfläche Simulationen nicht reagiert, prüfen Sie mit Ihrem Workspace-Administrator, ob diese Berechtigungen für Sie unter Einstellungen > Workspace > Teammates aktiviert sind.

Simulationen umgehen die Intent-Erkennung. Im Gegensatz zu Vorschau- oder Live-Gesprächen prüfen Simulationen nicht Ihre Anweisungen „Wann diese Prozedur verwenden“, sondern gehen davon aus, dass die Prozedur bereits ausgelöst wurde und führen sie direkt aus. Das macht Simulationen ideal, um die Ausführungslogik isoliert zu testen.

Wichtig:

Vorschau führt ein Testgespräch, das nie einen echten Nutzer erreicht, mit Ihren echten Inhalten. Standardmäßig liefern Daten-Connectoren Beispieldaten. Wenn Sie als bestimmter Nutzer testen und in den Vorschau-Einstellungen (Zahnradsymbol im Testbereich) „Zugriff auf echte Nutzerdaten bei Auslösung“ auswählen, rufen Daten-Connectoren Ihre echten Systeme auf, sodass alle Aktionen Ihrer Prozedur (z. B. Rückerstattungen oder Datensatzaktualisierungen) für diesen Nutzer ausgeführt werden. Verwenden Sie ein Testnutzerkonto, niemals einen echten Nutzer.
Simulationen rufen niemals externe Systeme auf. Fin verwendet die von Ihnen definierten Testwerte, was sie zur sichersten Methode macht, Logik vor dem Livegang zu validieren.

Verwenden Sie Vorschau für schnelle Stichproben; führen Sie Simulationen vor jeder Veröffentlichung durch.

Simulation erstellen

Sie können eine Simulation auf zwei Arten erstellen: mit KI-generierten Vorschlägen für einen schnellen Start oder durch manuelle Definition des Szenarios für volle Kontrolle.

KI-generierte Simulationen: Verwenden Sie diese, um häufige oder erwartete Nutzerszenarien basierend auf Ihren Anweisungen schnell abzudecken. Fin AI generiert „fertige“ Starttests, die Ihnen Zeit sparen.

Manuelle Simulationen: Verwenden Sie diese, wenn Sie präzise Kontrolle über Daten, spezielle Randfälle oder bestimmte Verzweigungen in Ihrer Logik benötigen.

KI-generierte Simulationen

Basierend auf Ihren Anweisungen generiert Fin AI Starttests, die Ihnen helfen, „fertige“ Simulationen schnell zu erstellen.

Öffnen Sie den Tab Simulationen im rechten Bereich Ihrer Prozedur.
Überprüfen Sie unter Vorgeschlagen für diese Anweisungen die Liste der vorgeschlagenen Szenarien (z. B. „Vollständige Stornierungsanfrage“).
Klicken Sie auf das Abspiel-Symbol neben einem Vorschlag, um ihn sofort auszuführen.
Sobald eine Simulation erstellt oder aus den Vorschlägen akzeptiert wurde, erscheint sie in Ihrer Liste. Sie können dann auf Alle ausführen klicken, um alle gespeicherten Simulationen gleichzeitig auszuführen.

Manuell erstellte Simulationen

Sie können auch eine Simulation von Grund auf neu erstellen, um spezifische Randfälle basierend auf den Prozeduranweisungen zu testen.

Klicken Sie im Tab Simulationen auf + Neu.
Simulationsname: Geben Sie Ihrer Simulation einen klaren Titel.
Simulieren als: Wählen Sie einen bestimmten Nutzer oder eine Marke, um die Personalisierung zu testen. Sie können aus einer Dropdown-Liste realer Nutzer in Ihrem Workspace auswählen.
Eröffnungsnachricht des Nutzers: Geben Sie die erste Nachricht ein, die der Nutzer sendet (z. B. „Ich brauche Hilfe mit meiner Bestellung“). Sie können auch ein Bild anhängen, z. B. einen Screenshot eines Fehlers, um zu testen, wie Fin visuelle Kontexte verarbeitet.
Zusätzliche Details: Geben Sie Hinweise zur Situation des Nutzers oder zu spezifischen Aktionen, die er unternommen hat.

Kanal auswählen

Simulationen ermöglichen es Ihnen, den Kanal auszuwählen, den Fin für diese Simulation verwendet, damit Sie testen können, wie Fin sich verhält. Verwenden Sie das Dropdown-Menü, um vor der Ausführung zwischen Messenger und Email zu wechseln.

Hinweis: Fin verhält sich je nach Kanal unterschiedlich. Im Email fasst Fin mehrere Informationen in einer einzigen Antwort zusammen, anstatt mehrere Nachrichten zu senden. Anleitung und Content-Targeting können ebenfalls pro Kanal konfiguriert werden – zum Beispiel können Email-Antworten einen formelleren Ton oder eine spezifische Einleitung enthalten.

Verfügbare Daten definieren

Der Abschnitt Dem Fin verfügbare Nutzerdaten ermöglicht es Ihnen, die Daten zu definieren, auf die Fin während des Tests zugreifen kann. So stellen Sie sicher, dass Sie mit präzisen Datenwerten testen und nicht mit vagen Beschreibungen.

Simulationszeit: Verwenden Sie diese, um zu definieren, „wann“ das Szenario stattfindet. Die Angabe eines bestimmten Datums und einer Uhrzeit ermöglicht es Ihnen, zeitkritische Logik zu testen, z. B. ob ein Nutzer innerhalb eines 30-tägigen Rückerstattungszeitraums liegt.
Attribute und Daten-Connectoren: Dieser Abschnitt wird mit den in Ihrer Prozedur referenzierten Attributen vorausgefüllt. Aktualisieren Sie diese Werte (z. B. setzen Sie People.Plan auf „Pro“), um unterschiedliche Verzweigungsergebnisse zu testen.

Hinweis: Um sicherzustellen, dass Ihre Simulation genau läuft, platzieren Sie Daten basierend darauf, wann Fin sie „kennen“ soll:

Attribute verwenden: Wenn Fin die Informationen bereits zu Beginn des Gesprächs kennen soll (z. B. den aktuellen Plan oder das Anmeldedatum des Nutzers).
Zusätzliche Details verwenden: Wenn die Informationen vom Nutzer während des Gesprächs bereitgestellt werden sollen (z. B. wenn der Nutzer seine „Bestell-ID“ in einer Folgeantwort angibt). So können Sie testen, ob Fin diese Daten korrekt erfasst und in einem Attribut speichert.

Hinweis:

Daten-Connectoren verwenden in Simulationen keine Live-Nutzerdaten. Statt Ihr externes System aufzurufen, verwendet Fin die Testwerte, die Sie im Abschnitt Dem Fin verfügbare Nutzerdaten definieren. Stellen Sie sicher, dass Sie Ihre Daten-Connector-Felder mit den Werten gefüllt haben, die Fin während des Tests verwenden soll – andernfalls liefert der Connector keine Ergebnisse.
Der Abschnitt Dem Fin verfügbare Nutzerdaten zeigt und speichert nur Attribute, die explizit in den Anweisungen Ihrer Prozedur oder einem Codeblock referenziert werden. Wenn Sie manuell ein Attribut über die Schaltfläche + Attribut hinzufügen hinzufügen, das Attribut aber nirgendwo in der Prozedur referenziert wird, speichert das System es nicht – es verschwindet nach dem Speichern, da es keinen Einfluss auf die Simulation hat. Um einen benutzerdefinierten Wert dauerhaft hinzuzufügen, stellen Sie sicher, dass das Attribut zuerst in der Prozedur verwendet wird.

Fin-Verhalten bewerten

Definieren Sie die Kriterien, die erfüllt sein müssen, damit der Test besteht. Klicken Sie auf + Kriterien hinzufügen und wählen Sie aus:

Fin reply: Geben Sie an, was Fin während des Gesprächs sagen (oder nicht sagen) soll.
Attribute: Überprüfen Sie, ob ein Attribut gesetzt, nicht gesetzt, gleich oder ungleich einem bestimmten Wert war.
Datenconnector: Überprüfen Sie, ob ein Connector ausgelöst wurde, nicht ausgelöst wurde oder genau X Mal ausgelöst wurde.
Ergebnis der Anweisung: Prüfen Sie, ob das Gespräch zu einem bestimmten Ergebnis geführt hat, z. B. Abschluss, Übergabe an einen Kollegen oder andere Ergebnisse wie der Wechsel zu einer anderen Prozedur.

Nach der Konfiguration klicken Sie auf Speichern.

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

Best Practices für Simulationsabdeckung

Um das Beste aus Simulationen herauszuholen, strukturieren Sie Ihre Testsuite nach diesen Prinzipien:

Testen Sie pro Simulation einen Pfad. Wenn Ihre Prozedur Bedingungen oder Unterprozeduren mit mehreren Pfaden hat, erstellen Sie für jeden Pfad eine separate Simulation. So entsteht ein Regression-Sicherheitsnetz – wenn eine zukünftige Änderung einen bestimmten Pfad bricht, erkennen Sie es sofort.
Decken Sie sowohl Erfolgs- als auch Fehlerpfade für Datenconnectoren ab. Führen Sie eine Simulation durch, bei der Ihr Connector gültige Daten zurückgibt, und eine weitere, bei der er nichts zurückgibt oder fehlschlägt. So wird überprüft, ob Ihre Fallback-Logik (z. B. ein @Condition-Schritt, der eine leere Antwort behandelt) korrekt funktioniert.
Führen Sie alle Simulationen vor der Veröffentlichung von Änderungen aus. Klicken Sie nach der Bearbeitung einer Prozedur auf Alle ausführen, um Ihre gesamte Suite erneut auszuführen, bevor Sie live gehen. Jede Simulation, die neu fehlschlägt, signalisiert eine durch Ihre Änderung eingeführte Regression.
Verwenden Sie beschreibende Simulationsnamen. Benennen Sie jede Simulation nach dem Szenario, das sie darstellt (z. B. „Vollständige Rückerstattung – innerhalb von 30 Tagen“ oder „Stornierung – keine Bestellung gefunden“). So erkennen Sie beim Überprüfen der Ergebnisse leicht, welcher Test welchen Pfad abdeckt.

Teststrategie: Happy Path, Risk Path und Edge Cases

Eine ausgewogene Simulationssuite deckt drei Arten von Szenarien ab. Zusammen geben sie Ihnen die Sicherheit, dass Ihre Prozedur unter normalen Bedingungen korrekt funktioniert, Fehler elegant behandelt und nicht bricht, wenn Kunden sich unerwartet verhalten.

Happy Path
Der Happy Path repräsentiert den idealen, ununterbrochenen Ablauf – ein Kunde, der genau die richtigen Informationen liefert und alle Bedingungen erfüllt, damit Fin die Prozedur erfolgreich abschließen kann. Beginnen Sie immer hier. Wenn der Happy Path fehlschlägt, 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 Datenconnector liefert seine Bestelldetails. Fin bearbeitet die Rückerstattung und bestätigt sie in einem Durchgang.
Risk Path
Risk Paths testen die Szenarien, die in der Produktion am wahrscheinlichsten schiefgehen – typischerweise wenn externe Daten fehlen, Bedingungen nicht erfüllt sind oder ein Fallback-Pfad ausgelöst werden muss. Diese Tests schützen Ihre Kunden davor, falsche oder unvollständige Antworten zu erhalten.
Beispiele: Der Datenconnector liefert keine Bestellung (testen Sie, dass Fin den Kunden nach der Bestell-ID fragt). Der Kunde befindet sich außerhalb des Rückerstattungszeitraums (testen Sie, dass Fin die korrekte Richtlinie kommuniziert und die richtige Übergabe anbietet). Ein Attribut ist leer, wenn ein Condition-Schritt es auswertet (testen Sie, dass Fins Fallback-Pfad korrekt ausgelöst wird).
Edge Cases
Edge Cases decken ungewöhnliche oder Grenzfall-Eingaben ab, die technisch gültig, aber selten sind. Diese Tests sind besonders wichtig für Prozeduren mit zeitkritischer Logik, numerischen Schwellenwerten oder Freitext-Kundeneingaben.
Beispiele: Ein Kunde beantragt eine Rückerstattung genau am Tag 30 (Grenze des Fensters). Ein Kunde sendet eine mehrdeutige Eröffnungsnachricht, 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 anzuzeigen, zu welcher Kategorie jeder Test gehört – zum Beispiel „Rückerstattung – Happy Path“, „Rückerstattung – keine Bestellung gefunden (Risk)“ oder „Rückerstattung – Grenztag 30 (Edge)“. So erkennen Sie auf einen Blick Lücken in Ihrer Abdeckung.

Ausführen und Überprüfen von Ergebnissen

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

Wird ausgeführt: Der Test wird gerade aktiv ausgeführt.
Bestanden: Der Test wurde ausgeführt und hat alle definierten Erfolgskriterien erfüllt.
Fehlgeschlagen: Der Test wurde ausgeführt, hat aber die definierten Erfolgskriterien nicht erfüllt.
In Warteschlange: Der Test wurde gestartet, wartet aber darauf, dass die vorherige Simulation abgeschlossen wird, bevor er ausgeführt wird.

Um ein Ergebnis zu untersuchen, klicken Sie auf Gespräch anzeigen. Dies öffnet das vollständige Transkript des Austauschs zwischen dem simulierten Kunden und Fin, 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 Fehlgeschlagen markiert ist, enthält das über Gespräch anzeigen verfügbare Transkript alles, was Sie benötigen, um die Ursache zu identifizieren. So lesen Sie es effektiv:

Fins Gedanken
Erweitern Sie in jedem Schritt des Gesprächs Fins Überlegungen, um zu sehen, wie es die Nachricht des Kunden interpretiert hat, welchen Prozedurschritt es ausführte und welche Entscheidung es traf. Wenn Fin einen unerwarteten Pfad eingeschlagen hat, zeigen Fins Gedanken normalerweise genau, wo seine Interpretation von Ihrer Absicht abwich. Achten Sie auf Schritte, bei denen Fins Interpretation eines Attributs oder einer Bedingung nicht mit Ihren Erwartungen übereinstimmt.
Gesprächsereignisse
Gesprächsereignisse erscheinen inline im Transkript und zeigen Aktionen auf niedriger Ebene wie Attributaktualisierungen, Datenconnector-Aufrufe und Übergabeauslöser. Verwenden Sie diese, um zu überprüfen, ob die richtigen Connectoren zur richtigen Zeit ausgelöst wurden und ob Attribute vor jedem Verzweigungsschritt auf die erwarteten Werte gesetzt wurden.
Fehler eingrenzen
Vergleichen Sie, was Sie in Fins Gedanken und Gesprächsereignissen sehen, mit Ihren definierten Erfolgskriterien. Ein häufiges Muster ist, dass ein Condition-Schritt auf den falschen Pfad auswertet – typischerweise, weil ein Attribut leer war oder einen unerwarteten Wert hatte. Überprüfen Sie Ihre Für Fin verfügbare Kundendaten-Einstellungen, um sicherzustellen, dass alle erforderlichen Attribute vor der Simulation ausgefüllt waren.

Tipp: Nachdem Sie die Ursache identifiziert haben, passen Sie Ihre Prozedur oder Simulationseinstellungen an und klicken Sie auf Ausführen bei derselben Simulation, um sofort erneut zu testen. Sie müssen keine neue Simulation erstellen – die bestehende behält ihre Konfiguration.

Simulationsnutzungsgrenzen

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

Jeder Workspace erhält eine monatliche Anzahl an Simulationsläufen. Die Anzahl basiert auf dem Gesprächsvolumen-Segment Ihres Workspaces, wobei größere Kunden höhere Kontingente erhalten.

Das Simulationskontingent basiert auf dem Gesprächsvolumen Ihres Workspaces in Intercom.

Wir ordnen Ihren Workspace einem Segment zu, basierend auf der Anzahl der Gespräche im letzten Kalendermonat.
Ihr Segment wird monatlich neu bewertet und Ihr Kontingent spiegelt das Gesprächsvolumen des letzten Monats wider.
Wenn Ihr Gesprächsvolumen steigt oder sinkt, kann sich Ihr Simulationskontingent im nächsten Monatszyklus ändern.

Gesprächsvolumen-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 visuelle Indikatoren im Tab Simulations:

Nutzungswarnung

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

Limit erreicht

Sobald Sie 100 % Ihres monatlichen Limits erreicht haben, erscheint eine rote Fehlermeldung. Sie können keine weiteren Simulationen ausführen, bis der nächste Monat beginnt.

Hinweis: Wenn Sie Ihr Limit erreicht haben, können Sie weiterhin frühere Simulationsergebnisse und Transkripte durch Klicken auf „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 greifen Simulationen nicht auf tatsächliche APIs oder externe Systeme (wie Shopify oder Stripe) zu. Es ist nicht möglich, während einer Simulation Daten in einer externen API zu lesen oder zu ändern. So können Sie die Logik sicher testen, ohne reale Daten zu beeinflussen.

Warum 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 funktioniert – im Gegensatz zu manuellen Tests, die sich besser für schnelle Stichproben oder Konfigurationsüberprüfungen eignen. Simulationen vor jedem Launch helfen, unerwartetes Verhalten frühzeitig zu erkennen.

Was passiert, wenn eine Simulation fehlschlägt?

Eine fehlgeschlagene Simulation kann vollständig überprüft werden – öffnen Sie das simulierte Gespräch, 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 meist, dass Ihre Erfolgskriterien zu streng sind. Wenn Sie beispielsweise verlangen, dass Fin „nach einer Bestell-ID fragt“, Fin aber intelligent genug ist, die ID automatisch zu finden, schlägt der Test fehl, weil Fin die Frage übersprungen hat. Aktualisieren Sie Ihre Kriterien, um sich auf das Endergebnis (z. B. „Procedure abgeschlossen“) zu konzentrieren, statt bestimmte Zwischenschritte vorzuschreiben.

Fin stoppt mitten in der Simulation. Warum bleibt es hängen?

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

Wo soll ich Testdaten wie „Anmeldedaten“ oder „Bestellhistorie“ eingeben?

Testdaten wie Anmeldedaten oder Bestellhistorie sollten im Abschnitt Customer data available to Fin der Simulationseinstellungen eingegeben werden – nicht in der Eröffnungsnachricht des Kunden oder im Feld Additional details, da Fin diese sonst möglicherweise übersieht. Geben Sie genaue Werte (z. B. 2024-06-01) in die spezifischen Attribute oder Variablen ein, die Sie testen.

Mein Tool funktioniert im echten Leben, aber in der Simulation nicht. Warum?

Simulationen holen keine echten Daten aus externen Systemen, daher liefert Ihr Data Connector in der Simulation keine Live-Ergebnisse wie im echten Gespräch. Wenn Ihr Connector in Live-Gesprächen funktioniert, aber in der Simulation fehlschlägt, liegt das wahrscheinlich daran, dass die erwarteten Rückgabewerte im Abschnitt Customer data available to Fin nicht definiert sind. Fügen Sie dort die Daten hinzu, die Ihr Connector normalerweise zurückgeben würde, und führen Sie die Simulation erneut aus.

Werden Simulationen separat von Procedures abgerechnet?

Simulationen sind in Procedures enthalten und werden nicht als separate Position berechnet. Für das Ausführen von Simulationen fallen keine zusätzlichen Kosten 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 Nachricht zusammen, anstatt mehrere Nachrichten zu senden. Anleitung und Inhalte können auch auf bestimmte Kanäle zugeschnitten werden – z. B. können E-Mail-Antworten formeller sein oder eine spezielle Einleitung enthalten. Das Simulieren von E-Mail-Gesprächen ermöglicht es Ihnen, dieses Verhalten zu überprüfen und mit Vertrauen auf E-Mail zu veröffentlichen.

Warum gibt es ein Limit für Simulationsläufe?

Jeder Simulationslauf benötigt Ressourcen, um genaue KI-Vorhersagen zu erzeugen. Wir stellen ein monatliches Kontingent bereit, damit Sie Ihre Procedures für Standardanwendungen frei testen können und extreme Nutzung keine unkontrollierten Kosten verursacht.

Kann ich eine Unter-Prozedur unabhängig simulieren?

Nein. Unter-Prozeduren haben kein eigenes Simulationsfenster und können nicht isoliert ausgeführt werden. Um eine Unter-Prozedur zu testen, führen Sie eine Simulation der übergeordneten Procedure durch und konfigurieren das Szenario so, dass der Ausführungspfad die Unter-Prozedur erreicht – indem Sie die Kunden-Nachricht, Attribute und zusätzliche Details so einstellen, dass der spezifische Zweig ausgelöst wird.

Wenn Sie mehrere Unter-Prozeduren innerhalb derselben übergeordneten Procedure haben, erstellen Sie für jede eine separate Simulation, die das Szenario abdeckt, das zum Aufruf dieser Unter-Prozedur führt.

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

Leere Data Connector-Ergebnisse in einer Simulation werden meist durch fehlende Testdaten verursacht. Simulationen holen keine Live-Daten aus externen Systemen – Sie müssen die Werte, die Ihr Data Connector zurückgeben soll, im Abschnitt Customer data available to Fin der Simulationseinstellungen definieren. Prüfen Sie, ob Sie die relevanten Data Connector-Felder mit den Testwerten gefüllt haben, die Fin verwenden soll.

Wenn Sie absichtlich den Pfad „Connector gibt nichts zurück“ 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 auch bei einem Nutzer mit echten Daten leer zurückgibt, prüfen Sie, ob Ihr Testkontakt eine gültige external_id hat, die mit der Kundenkennung Ihres externen Systems übereinstimmt.

Wie viele Simulationen kann ich pro Monat ausfü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:

Gesprächsvolumen-Segment	Simulationslimit pro Monat
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 verwendet 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 Gesprächsvolumen Ihres Workspaces festgelegt und zu Beginn jedes Kalendermonats neu bewertet. Wenn Ihr Gesprächsvolumen wächst, 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 überprüfen, aber die Schaltflächen "Run" und "Run all" werden deaktiviert, bis Ihr Kontingent zurückgesetzt wird.

Simulationen für Fin-Prozeduren durchführen