Simulationen ermöglichen es Ihnen, Fin-Verfahren zu validieren, Vertrauen in Ihre Automatisierung aufzubauen und Probleme zu erkennen, bevor sie Ihre Kunden 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.

Verfahrenssimulationen vs. Evals

Fin verfügt über zwei Arten von Simulationen, die unterschiedliche Dinge testen:

Verfahrenssimulationen testen ein einzelnes Verfahren. Jede Simulation läuft innerhalb der Grenzen dieses Verfahrens, daher ist sie das richtige Werkzeug, um zu überprüfen, ob die Logik, Verzweigungen und Datenverarbeitung des Verfahrens während des Aufbaus funktionieren und auch nach dem Livegang weiterhin funktionieren. Sie können und sollten mehrere Simulationen für ein Verfahren erstellen, jeweils eine für jeden Pfad.
Eval-Simulationen testen die Fin-Konfiguration von Anfang bis Ende. Eine Eval-Simulation führt ein vollständiges Gespräch über alle Elemente aus, die Fin zur Beantwortung nutzt, einschließlich Inhalt, Anleitung, Eskalationsanleitung, Skills und Verfahren. Sie deckt somit ab, was passiert, bevor ein Verfahren ausgelöst wird und nachdem es übergeben wurde.

Verwenden Sie Verfahrenssimulationen, wenn Sie ein Verfahren einrichten, um zu bestätigen, dass jeder Pfad wie erwartet funktioniert, und führen Sie sie bei jeder Änderung des Verfahrens erneut aus. Um ein vollständiges Gespräch einschließlich der Übergabe zu testen, verwenden Sie stattdessen eine Eval-Simulation. Weitere Informationen finden Sie unter Evals für Fin.

Tipp: Führen Sie Verfahrenssimulationen während des Aufbaus eines Verfahrens durch und fügen Sie dann eine Eval-Simulation hinzu, um die gesamte Kundenreise abzudecken, sobald das Verfahren live ist.

Zugriff auf Simulationen

Simulationen befinden sich im Testbereich eines Verfahrens. So greifen Sie darauf zu:

Öffnen Sie das Verfahren, das Sie testen möchten.
Klicken Sie oben rechts auf der Arbeitsfläche auf Test.
Wählen Sie im rechten Bereich die Registerkarte Simulationen 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 dieses Verfahren verwenden“, sondern gehen davon aus, dass das Verfahren bereits ausgelöst wurde, und führen es direkt aus. Das macht Simulationen ideal, um die Ausführungslogik isoliert zu testen.

Wichtig:

Vorschau führt ein Testgespräch, das niemals einen echten Kunden erreicht, unter Verwendung Ihrer echten Inhalte. 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, die Ihr Verfahren ausführt (z. B. Rückerstattungen oder Datensatzaktualisierungen), für diesen Nutzer ausgeführt werden. Verwenden Sie ein Testnutzerkonto, niemals einen echten Kunden.
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.

Erstellen einer Simulation

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 Kundenszenarien 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, schnell „fertige“ Simulationen zu erstellen.

Öffnen Sie die Registerkarte Simulationen im rechten Bereich Ihres Verfahrens.
Ü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 bestimmte Randfälle basierend auf den Verfahrensanweisungen zu testen.

Klicken Sie in der Registerkarte 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 users in Ihrem Workspace auswählen.
Eröffnungsnachricht des Kunden: Geben Sie die erste Nachricht ein, die der Kunde sendet (z. B. „Ich brauche Hilfe bei 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 Kunden oder zu spezifischen Aktionen, die er unternommen hat.

Wählen Sie einen Kanal

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 Ihrer Simulation 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 Kundendaten, die Fin zur Verfügung stehen ermöglicht es Ihnen, die Daten zu definieren, auf die Fin während des Tests zugreifen kann. So stellen Sie sicher, dass Sie gegen präzise Datenwerte testen und nicht auf vage Beschreibungen angewiesen sind.

Simulationszeit: Verwenden Sie diese, um zu definieren, „wann“ das Szenario stattfindet. Die Festlegung eines bestimmten Datums und einer Uhrzeit ermöglicht es Ihnen, zeitkritische Logik zu testen, wie z. B. die Prüfung, ob ein Kunde innerhalb eines 30-Tage-Rückerstattungszeitraums liegt.
Attribute und Data Connectors: Dieser Abschnitt wird mit den Attributen vorausgefüllt, die in Ihrem Verfahren referenziert werden. 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 zu Beginn des Gesprächs bereits kennen soll (z. B. den aktuellen Plan oder das Anmeldedatum des Kunden).
Zusätzliche Details verwenden: Wenn die Informationen vom Kunden während des Gesprächs bereitgestellt werden sollen (z. B. wenn der Kunde seine „Order ID“ in einer Folgeantwort angibt). So können Sie testen, ob Fin diese Daten korrekt erfasst und in einem Attribut speichert.

Hinweis:

Data Connectors verwenden in Simulationen keine Live-Benutzerdaten. Statt Ihr externes System aufzurufen, nutzt Fin die Testwerte, die Sie im Abschnitt Kundendaten, die Fin zur Verfügung stehen definieren. Stellen Sie sicher, dass Sie Ihre Data Connector-Felder mit den Werten gefüllt haben, die Fin während des Tests verwenden soll – andernfalls liefert der Connector leere Ergebnisse zurück.
Der Abschnitt Kundendaten, die Fin zur Verfügung stehen zeigt und speichert nur Attribute, die explizit in den Anweisungen Ihrer Prozedur oder in einem Codeblock referenziert werden. Wenn Sie manuell ein Attribut über die Schaltfläche + Attribut hinzufügen hinzufügen, dieses Attribut aber in der Prozedur nicht verwendet 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’s 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:

Fin-Antwort: Geben Sie an, was Fin während des Gesprächs sagen soll (oder nicht sagen soll).
Attribute: Überprüfen Sie, ob ein Attribut gesetzt, nicht gesetzt, gleich oder ungleich einem bestimmten Wert war.
Data Connector: Überprüfen Sie, ob ein Connector ausgelöst, nicht ausgelöst oder genau X-mal ausgelöst wurde.
Ergebnis der Anweisung: Prüfen Sie, ob das Gespräch zu einem bestimmten Abschluss kam, z. B. Beendigung, Ü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 KI, 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 nur einen Pfad. Wenn Ihre Prozedur Bedingungen oder Unterprozeduren mit mehreren Pfaden enthält, 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 das sofort.
Decken Sie sowohl Erfolgs- als auch Fehlerpfade für Data Connectors 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. Nach der Bearbeitung einer Prozedur klicken Sie 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. „Volle 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 Szenariotypen 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 steht für 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 Order 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 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 Data Connector liefert keine Bestellung (testen, ob Fin den Kunden nach der Order ID fragt). Der Kunde befindet sich außerhalb des Rückerstattungszeitraums (testen, ob Fin die korrekte Richtlinie kommuniziert und die richtige Übergabe anbietet). Ein Attribut ist leer, wenn ein Condition-Schritt es auswertet (testen, ob 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 Order 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.

Tests ausführen und Ergebnisse überprüfen

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 ansehen. 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.

Fehlerbehebung bei einer fehlgeschlagenen Simulation

Wenn eine Simulation als Fehlgeschlagen markiert ist, enthält das über Gespräch ansehen verfügbare Transkript alles, was Sie zur Ursachenfindung benötigen. 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 meist 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, Data Connector-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.
Fehlerursache 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 Einrichtung der Kundendaten, die Fin zur Verfügung stehen, um sicherzustellen, dass alle erforderlichen Attribute vor der Simulation gefüllt waren.

Tipp: Nachdem Sie die Ursache identifiziert haben, passen Sie Ihre Prozedur oder Simulationseinrichtung 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 ein monatliches Kontingent an Simulationsläufen. Das Kontingent basiert auf dem Gesprächsvolumen-Segment Ihres Workspaces, wobei größere Kunden höhere Kontingente erhalten.

Die Simulationszulage 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 Ihre Zulage spiegelt das Gesprächsvolumen des letzten Monats wider.
Wenn Ihr Gesprächsvolumen steigt oder sinkt, kann sich Ihre Simulationszulage 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 Workspace 80 % seines monatlichen Limits erreicht, erscheint ein gelbes Warnbanner. Es zeigt Ihre aktuelle Nutzung an (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 vorherige Simulationsergebnisse und Transkripte durch Klicken auf "Gespräch ansehen" überprüfen, aber die Schaltflächen "Ausführen" und "Alle ausführen" sind deaktiviert.

FAQs

Interagieren Simulationen mit meinen Live-APIs oder externen Daten?

Nein. Im Gegensatz zum Vorschau-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 aus 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 in großem Umfang 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 Konfigurationsprü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 wird meine Simulation als „Fehlgeschlagen“ markiert, obwohl Fin das Problem erfolgreich gelöst hat?

Eine Simulation, die als „Fehlgeschlagen“ markiert ist, obwohl Fin das Problem gelöst hat, bedeutet meist, dass Ihre Erfolgskriterien zu streng sind. Wenn Sie z. B. verlangen, dass Fin nach einer Bestell-ID fragt, Fin diese aber automatisch findet, schlägt der Test fehl, weil Fin die Frage übersprungen hat. Passen Sie Ihre Kriterien an, um sich auf das Endergebnis (z. B. „Procedure abgeschlossen“) zu konzentrieren, statt auf bestimmte Zwischenschritte.

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 „Zusätzliche 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 nicht, 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 als Testwerte hinzu und führen Sie die Simulation erneut aus.

Werden Simulationen separat von Procedures abgerechnet?

Simulationen sind in Procedures enthalten und werden nicht separat 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, statt mehrere Nachrichten zu senden. Anleitung und Inhalte können auch auf bestimmte Kanäle zugeschnitten werden – z. B. kann die E-Mail-Antwort 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 eine monatliche Zulage bereit, damit Sie Ihre Procedures für Standardanwendungen frei testen können und gleichzeitig extreme Nutzungskosten vermieden werden.

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 zu 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 liefert nichts zurück“ testen, ist das 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:

IF Get order > order_id is empty: ask the customer to confirm their order ID
ELSE: continue with the refund steps

Wenn der Connector auch für einen Benutzer mit echten Daten leer zurückgibt, überprü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 durchführen?

Ihr monatliches Simulationen-Kontingent hängt vom Gesprächsvolumen Ihres Workspaces in Intercom im vorherigen Kalendermonat ab. Das Limit gilt auf Workspace-Ebene 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 verfallen – 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 einsehen, aber die Schaltflächen "Run" und "Run all" sind deaktiviert, bis Ihr Kontingent zurückgesetzt wird.

Simulationen für Fin-Verfahren durchführen