Wenn eine Fin Procedure eine Konversation nicht wie erwartet abschließt, können Sie integrierte Inspektionstools verwenden, um Fins Entscheidungslogik zu untersuchen. Nutzen Sie diese Anleitung, um zu erkennen, wo ein Ablauf fehlgelaufen ist und wie Sie Ihre Anweisungen verfeinern.

Was Sie lernen werden

Fehler von Procedures mithilfe von Fin’s Gedanken und Konversationsereignissen debuggen.
Häufige Probleme diagnostizieren, z. B. falsche Procedure-Trigger, Schritte in falscher Reihenfolge und Verzweigungsfehler.
Fehler von Data connectoren beheben, einschließlich Authentifizierungsfehler und fehlender Daten.
Korrekturen vor dem Livegang mit Simulationen validieren.

Auf den Konversationsdebugger zugreifen

Um zu verstehen, warum Fin eine bestimmte Aktion ausgeführt hat, müssen Sie zuerst technische Sichtbarkeit im Konversationsthread aktivieren.

Öffnen Sie die betreffende Konversation im Inbox.
Klicken Sie auf das Drei-Punkte-Symbol oben rechts in der Konversationsüberschrift.
Wählen Sie Show conversation events.

Tipp: Verwenden Sie die Tastenkombination ⌘ + E (Mac) oder Strg + Umschalt + E (Windows), um diese Ansicht umzuschalten.

Inspektion von "Fin’s thoughts"

Sobald Konversationsereignisse sichtbar sind, können Sie die Gründe für jeden Schritt sehen, den Fin während einer Procedure unternommen hat. Um Fins Entscheidungsprozess nachzuverfolgen, suchen Sie die Fin’s thoughts-Ereignisse in der Konversationstimeline. Diese Ereignisse fassen Fins Überlegungen zusammen, bevor er eine Nachricht sendet oder eine Aktion ausführt.

Für detailliertere Informationen klicken Sie auf Fin Thoughts und dann auf See more. Dies zeigt:

Der aktuelle Schritt: Der spezifische Procedure-Schritt, den Fin ausführte.
Absichtsauslegung: Wie Fin die Anfrage des Kunden verstanden hat.
Logikpfad: Warum Fin beschlossen hat, einen Schritt zu überspringen, einen vorherigen zu wiederholen oder zu einem bestimmten Zweig zu wechseln.

Hinweis: Dieser Artikel behandelt nur die Fehlerbehebung für Fin Procedures. Die "Fin’s thoughts"-Timeline und der Debugger sind nur verfügbar, wenn eine Procedure ausgelöst wurde. Wenn Fin in einer Standardkonversation eine unerwartete Antwort gab, sind diese Tools nicht in den Konversationsereignissen vorhanden.

Häufige Procedure-Fehler

Wenn Fin nicht wie erwartet funktioniert, liegt es meist an der Formulierung der Anweisungen oder an der Verzweigungslogik.

Procedure löst überhaupt nicht aus

Bevor Sie die unten nummerierten Fehler überprüfen, gehen Sie zunächst diese Grundlagen durch:

Überprüfen Sie, ob die Procedure veröffentlicht ist: Entwürfe werden für Kunden nicht ausgelöst. Bestätigen Sie, dass der Status im Editor auf Published gesetzt ist.
Überprüfen Sie, ob Fin bereitgestellt ist: Wenn Fin nicht über den Simply Deploy-Bereich aktiviert ist oder der Schritt "Let Fin handle" in Ihrem workflow nicht live ist, führt Fin keine Procedures aus.
Überprüfen Sie die Zielgruppe: Ein häufiger Fehler ist, Users anzusprechen, wenn der Kunde ein Lead ist (oder umgekehrt). Im Abschnitt "When to use this procedure" klicken Sie auf die Audience-Schaltfläche und vergewissern Sie sich, dass der richtige Publikumstyp und Kanal ausgewählt sind.
Überprüfen Sie auf Workflows mit höherer Priorität: Aktive workflows laufen, bevor Fin die Procedure-Absicht bewertet. Überprüfen Sie Ihre workflows, um sicherzustellen, dass keine die Konversation abfängt, bevor Fin die Procedure auslösen kann.
Überprüfen Sie den Umfang der Auslösebedingungen: Zu enge Kriterien hindern Fin daran, gültige Kundenmeldungen zuzuordnen. Prüfen Sie die Beschreibung "When to use this procedure" und fügen Sie positive Beispiele (Nachrichten, die sie auslösen sollten) und negative Beispiele (Nachrichten, die sie nicht auslösen sollten) hinzu.

Hinweis: Obwohl Slack als auswählbarer Kanal erscheinen kann, werden Procedure-Auslöser für Slack-Konversationen derzeit nicht unterstützt.

Fin löst die falsche Procedure aus

Problem: Fin startet eine Procedure, die nicht zur Anfrage des Kunden passt.

Lösung: Überprüfen Sie Ihre "When to use this procedure"-Anweisungen. Verwenden Sie positive und negative Beispiele, um Fin bei der Unterscheidung ähnlicher Intentionen zu helfen. Wenn eine neue Procedure ähnliche Auslösebedingungen wie eine bestehende veröffentlichte Procedure teilt, kann die veröffentlichte Vorrang haben. Um die neue Procedure während Tests zu isolieren: schließen Sie vorübergehend Ihren Testuser aus der bestehenden Procedure aus, indem Sie dessen Audience-Kriterien anpassen, oder verengen Sie den Auslöser der neuen Procedure auf eine eindeutige Phrase, die nur Sie senden würden. Verwenden Sie Fin's thoughts > Expand thoughts im Konversationsdebugger, um zu bestätigen, welche Procedure tatsächlich ausgelöst wurde.

Schritte außerhalb der Reihenfolge

Problem: Fin überspringt einen Voraussetzungsschritt oder geht zu früh zu einer Lösung über.

Lösung: Prüfen Sie auf Mehrdeutigkeiten in Ihren natürlichsprachlichen Anweisungen. Wenn ein Schritt von einem bestimmten Datenelement abhängt, stellen Sie sicher, dass die Anweisung ausdrücklich sagt: "Nur fortfahren, wenn [data] bereitgestellt wird."

Verzweigungslogik-Fehler

Problem: Fin folgt dem "Else"-Pfad, obwohl es dem "If"-Pfad folgen sollte.

Lösung: Überprüfen Sie die Conditions. Wenn Sie natürliche Sprache für Verzweigungen verwenden, versuchen Sie, die Formulierung zur Klarheit zu überarbeiten. Für komplexe Logik (z. B. Datumsberechnungen) sollten Sie Python-Codeblöcke in Betracht ziehen, um strikt deterministische Regeln durchzusetzen.

Help Center-Inhalte haben Vorrang

Problem: Fin antwortet aus dem Help Center, anstatt die Procedure auszuführen, selbst wenn die Absicht des Kunden eindeutig mit den Auslösebedingungen der Procedure übereinstimmt.

Lösung: Wenn Fin standardmäßig eine Help Center-Antwort gibt, anstatt die Procedure auszuführen, gibt es zwei Vorgehensweisen, je nach Ihrer Einrichtung. Versuchen Sie zuerst Option 1 — wenn das Problem weiterhin besteht, wechseln Sie zu Option 2.

Option 1: Procedure Switching aktivieren
Agentic Switch ist eine prozedurbezogene Einstellung, die Fin erlaubt, automatisch von der aktuellen Procedure zu einer anderen live Procedure zu wechseln, wenn festgestellt wird, dass sich die Absicht des Kunden mitten in der Konversation geändert hat — anstatt an der ursprünglichen Procedure festzuhalten oder auf eine Help Center-Antwort zurückzufallen. Wenn aktiviert:
- Fin überprüft die Konversation und alle live Procedure-Auslösebeschreibungen, um zu entscheiden, wann ein Wechsel dem Kunden besser dienen würde
- Wenn mehrere Procedures zutreffen könnten, kann Fin eine klärende Frage stellen, um die beste auszuwählen
- Nur die Quell-Procedure (diejenige, aus der Fin wechselt) benötigt die Einstellung aktiviert
- Der @Switch-Befehl kann weiterhin verwendet werden, um manuell zu wechseln
Um es zu aktivieren: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Option 2: Entfernen oder aktualisieren Sie widersprüchliche Help Center-Inhalte
Wenn das Aktivieren von Agentic Switch das Problem nicht löst, ist die zuverlässigste Lösung, die Help Center-Inhalte zu entfernen oder zu aktualisieren, die Fin anstelle des Ablaufs verwendet. Fin greift standardmäßig auf Help Center-Antworten zurück, wenn für ein Thema relevanter Inhalt vorhanden ist — wenn also ein Artikel dieselbe Absicht wie Ihr Ablauf abdeckt, antwortet Fin möglicherweise direkt daraus, anstatt den Ablauf auszulösen.

Um die widersprüchlichen Inhalte zu identifizieren:
- Finden Sie die Unterhaltung in Ihrem Inbox und öffnen Sie Fin's thoughts.
- Suchen Sie nach Verweisen auf Help Center-Artikel im Antwortpfad.
- Entfernen Sie entweder den widersprüchlichen Artikel oder aktualisieren Sie ihn mit der Aufforderung, sich an den Support zu wenden, damit Fin zum Ablauf routed.

Beispiel: Ein Unternehmen hat einen Ablauf, der Rückerstattungsanfragen bearbeitet – er erfasst die Bestellnummer, prüft die Berechtigung und bearbeitet die Rückerstattung automatisch. Sie haben auch einen Help Center-Artikel mit dem Titel „How do I get a refund?“ der die Rückerstattungsrichtlinie erklärt. Wenn ein Kunde „I'd like a refund“ schreibt, findet Fin den Help Center-Artikel und antwortet mit der Richtlinie, anstatt den Ablauf auszulösen. In diesem Fall entfernt das Aktualisieren des Artikels mit einer Aussage wie „To request a refund, start a chat and our assistant will walk you through it“ die widersprüchliche Antwort und leitet Kunden stattdessen zum Ablauf weiter.

Ablauf stockt oder beendet sich, bevor er abgeschlossen ist

Problem: Der Ablauf erreicht einen bestimmten Schritt und stoppt oder endet in einem Endzustand, ohne alle erwarteten Schritte abzuschließen.

Lösung: Dies wird normalerweise durch Entwurfsmuster verursacht, die Fins Fähigkeit verwirren, seinen aktuellen Standort im Ablauf zu verfolgen. Prüfen Sie Folgendes:

Redundante „Immediately proceed“-Anweisungen: Wenn mehrere Schritte Anweisungen wie „immediately proceed to the next step“ enthalten, kann Fin bereits abgeschlossene Schritte erneut auswerten, anstatt vorwärts zu gehen. Entfernen Sie diese Anweisungen und lassen Sie Fin den Ablauf natürlich entsprechend dem Fluss durchlaufen.
Sprung-Anweisungen zwischen Schritten: Formulierungen wie „go back to step 2“ oder „repeat the verification step“ können dazu führen, dass Fin zwischen Schritten schleift, anstatt voranzukommen. Gestalten Sie jeden Schritt so, dass es einen klaren Vorwärtspfad gibt.
Überlappende Bedingungslogik: Wenn zwei Bedingungen gleichzeitig wahr sein können, kann Fin unvorhersehbar verzweigen oder stocken. Stellen Sie sicher, dass Ihre Bedingungen sich gegenseitig ausschließen — es sollte immer nur ein Zweig zu einem Zeitpunkt wahr sein.
Sub-Prozedur endet ohne Fortsetzung: Wenn eine Sub-Prozedur abgeschlossen ist, der Hauptablauf aber keine klare Anweisung für das weitere Vorgehen hat, kann Fin das Ende der Sub-Prozedur als Ende des gesamten Ablaufs behandeln. Fügen Sie in dem Schritt, der die Sub-Prozedur aufruft, eine explizite Anweisung hinzu: „Once the sub-procedure is complete, continue to [next step name]."

Verwenden Sie Fin's thoughts > See more im Konversations-Debugger, um genau zu identifizieren, bei welchem Schritt Fin war, als der Ablauf unerwartet beendet wurde.

Attributtypen-Mismatch verursacht Speicherfehler

Problem: Der Ablauf schlägt fehl, wenn eine Antwort in ein Konversationsattribut gespeichert werden soll.

Lösung: Überprüfen Sie, ob der Attributtyp mit dem Wert übereinstimmt, den der Ablauf zu speichern versucht. Wenn der Ablauf einen String speichert (z. B. eine während der Unterhaltung gesammelte Kundenantwort), muss das Zielattribut den Typ String haben. Die Verwendung eines Listentyp-Attributs mit demselben Namen führt zu Speicherfehlern. Um dies zu beheben, aktualisieren Sie entweder den Ablauf, damit er das richtige Attribut referenziert, oder gehen Sie zu Settings > Data > Conversations, um den Attributtyp zu ändern.

Mobile (iOS) Probleme mit Abläufen

Auf Mobilgeräten (iOS) haben Abläufe zusätzliche Anforderungen:

Users only: Abläufe werden auf Mobilgeräten nur für Users ausgelöst — sie laufen nicht für Leads oder Besucher, unabhängig davon, wie das Publikum im Ablauf konfiguriert ist.
iOS channel must be targeted: Im Abschnitt "When to use this procedure" muss iOS als Kanal ausgewählt sein. Der Ablauf wird auf Mobilgeräten nicht ausgelöst, wenn nur Web aktiviert ist.
Procedure must be Published: Entwürfe von Abläufen werden mobilen Kunden nicht bereitgestellt.
Check Fin is deployed for iOS: Abläufe benötigen Fin, um auf dem iOS-Kanal live zu sein. Bestätigen Sie, dass Simple Deploy unter Fin AI Agent > Deploy > Chat aktiviert ist, oder dass es einen aktiven Let Fin Handle-Block im relevanten Workflow gibt, der auf iOS abzielt.
Higher-priority workflows: Ein Workflow, der für denselben Gesprächsauslöser auf iOS läuft, kann das Gespräch abfangen, bevor Fin die Ablaufabsicht bewertet. Überprüfen Sie Ihre aktiven workflows auf iOS-Kanal-Überlappungen.

Fehlerbehebung zu Daten-Connectors in Abläufen

Dieser Abschnitt behandelt Fehler, die spezifisch für Daten-Connectors sind, die innerhalb eines Ablaufs ausgeführt werden. Wenn Ihr Connector im Standalone-Test funktioniert, aber während eines Live-Ablaufs fehlschlägt, beginnen Sie hier.

Connector funktioniert im Test, aber schlägt im Live-Ablauf fehl

Problem: Der Connector besteht die Standalone-Tests, schlägt aber während eines Live-Laufs fehl.

Lösung: Dies wird normalerweise durch eine der folgenden Ursachen hervorgerufen:

Credentials: Speichern und veröffentlichen Sie erneut nach dem Rotieren eines Schlüssels. Prüfen Sie auf versteckte Zeichen wie nachgestellte Leerzeichen in Tokenwerten.
Permissions: Eine kürzliche Sicherheitsänderung in Ihrem externen System hat möglicherweise den Zugriff entfernt.
IP allowlisting: Bestätigen Sie, dass die ausgehenden IPs von Intercom enthalten sind. Kontaktieren Sie Ihren Account Manager für die aktuellen Bereiche.

Important: Wenn Ihr Connector ohne Änderungen Ihrerseits aufhört zu funktionieren, prüfen Sie, ob Ihr externer API-Anbieter (z. B. Shopify, Stripe) einen Endpunkt aktualisiert oder deprecated hat.

401- und 403-Autorisierungsfehler

401 Unauthorized: Das Token fehlt, ist abgelaufen oder fehlerhaft. Intercom versucht einmal automatisch erneut. Prüfen Sie die Logs-Registerkarte, um zu bestätigen, ob ein Refresh versucht wurde.
403 Forbidden: Das Token ist gültig, hat aber nicht die erforderliche Berechtigung. Überprüfen Sie die Berechtigungen in Ihrem externen System.
OAuth users: Verwenden Sie die Schaltfläche Reauthenticate anstelle des Löschens und Neuerstellens des Tokens.

Connector scheint nicht ausgelöst zu werden

Check the logs: Navigieren Sie zu Settings > Integrations > Data connectors > Logs. Wenn kein Protokolleintrag vorhanden ist, wurde der Schritt wahrscheinlich übersprungen; prüfen Sie die vorherige Branch-Logik.
Check conversation events: Wählen Sie Logs aus einem Fehlerereignis im Inbox für vollständige Details.

Connector liefert Daten, aber Fin verwendet sie nicht

Verwenden Sie Fin's thoughts, um zu sehen, wie Fin die Connector-Antwort interpretiert hat.
Machen Sie die Schrittanweisung expliziter: „Use @connector_name to answer this—do not use knowledge base content.“
Prüfen Sie, ob die Antwort leer oder null ist; Fin kann auf andere Quellen zurückfallen, wenn keine verwertbaren Daten gefunden werden.
Fin calls one connector per turn: Wenn Ihr Ablauf mehrere Connector-Aufrufe in Folge durchführen muss, muss jeder Aufruf sein eigener Schritt sein. Fin verarbeitet einen Tool-Aufruf pro Gesprächs-Durchgang — es kann nicht mehrere Connector-Aufrufe innerhalb einer einzelnen Schrittanweisung verketten.

Important: Fin kann nur einen Connector-Aufruf pro Turn verarbeiten. Wenn Ihr MCP-Server zwei separate Antworten im selben SSE-Stream zurücksendet, wird Fin nicht zuverlässig in der Lage sein, die erste Antwort zur Erstellung seiner Antwort zu verwenden.

Connector erscheint nicht im Ablauf-Editor

Problem: Ihr Daten-Connector ist veröffentlicht und konfiguriert, aber er wird nicht angezeigt, wenn Sie versuchen, ihn in einem Schritt im Ablauf-Editor hinzuzufügen.

Lösung: Arbeiten Sie diese Prüfungen der Reihe nach durch:

Stellen Sie sicher, dass der Connector auf Live eingestellt ist: Gehen Sie zu Settings > Integrations > Data connectors und prüfen Sie den Status des Connectors. Ein Connector im Draft erscheint nicht im Procedure Editor.
Verifizieren Sie, dass mindestens eine Aktion konfiguriert ist: Ein Connector ohne definierte Aktionen wird im Procedure Editor nicht als Option angezeigt, selbst wenn er Live ist.
Überprüfen Sie Ihre Rollenberechtigungen: Einige Rollen können Connectoren in Settings sehen, aber nicht im Procedure Editor darauf zugreifen. Bestätigen Sie, dass Ihre Rolle Zugang zu beiden Bereichen hat.
Seite aktualisieren: Der Procedure Editor benötigt gelegentlich ein hartes Neuladen, damit kürzlich veröffentlichte Connectoren angezeigt werden. Verwenden Sie ⌘ + Shift + R (Mac) oder Ctrl + Shift + R (Windows).
Kontaktieren Sie Fin Support: Wenn keines der oben genannten Probleme hilft, wenden Sie sich mit dem Connector-Namen und Ihren Workspace-Details an Fin Support. Einige Workspace-Konfigurationen erfordern einen manuellen Schritt, damit ein Connector im Procedure Editor verfügbar wird.

Connector schlägt im Auto-Execute-Modus fehl

Problem: Der Data Connector ist so konfiguriert, dass er automatisch ausgeführt wird — ohne den Kunden zu fragen — schlägt aber still während einer Live-Unterhaltung fehl. Fin eskaliert oder gibt eine unerwartete Antwort, und es gibt keinen sichtbaren Fehler in der Unterhaltung.

Lösung: Im Auto-Execute-Modus kann Fin nicht über einen fehlgeschlagenen Connector-Schritt hinweg springen und die Procedure fortsetzen. Wenn der Connector einen Fehler zurückgibt, betrachtet Fin den gesamten Schritt als nicht lösbar und eskaliert entweder an einen Menschen oder fällt auf sein Standardverhalten zurück.

Es gibt zwei Möglichkeiten, dies zu behandeln:

Passen Sie Ihre externe API an, damit ein Fallback-Wert zurückgegeben wird: Statt einen Fehler zurückzugeben, wenn Daten nicht verfügbar sind (z. B. ein 404, wenn eine Bestellung nicht gefunden wird), konfigurieren Sie Ihre API so, dass ein leeres oder Standardergebnis zurückgegeben wird, auf das Fin reagieren kann. Dies ist die zuverlässigste Lösung, weil Fin immer etwas erhält, mit dem es arbeiten kann.
Fügen Sie nach dem Connector-Aufruf einen Condition-Schritt hinzu: Verwenden Sie die status_code-Ausgabe des Connectors, um bei einem Fehlschlag zu einer höflichen Nachricht oder einem kontrollierten Eskalationspfad zu verzweigen. Siehe „Advanced failure handling with status_code“ in diesem Artikel, um das einzurichten.

Connector gibt 404 zurück oder Kontaktattribute werden nicht geschrieben, obwohl die Ausführung scheinbar stattfindet

Problem: Der Connector scheint ausgelöst zu werden — Logs zeigen, dass er ausgeführt wurde — gibt aber einen 404-Fehler zurück und Kontaktattribute werden nicht geschrieben, obwohl alle Connectoren korrekt konfiguriert aussehen.

Lösung: Dies wird fast immer durch eine ungültige Attribut-Pille in der Request-URL verursacht. Einer der URL-Parameter löst zur Laufzeit einen leeren Wert aus, wodurch die URL fehlerhaft wird.

Die häufigste Ursache: Ein Attribut wurde manuell als {{Attribute Name}} eingetippt, anstatt es aus dem Attribute Inserter auszuwählen. Der Editor konvertiert jeden {{...}}-Text in eine Pille, die identisch aussieht wie ein gültiges Attribut – aber wenn der Bezeichner keinem echten Attribut entspricht, ergibt er zur Laufzeit keinen Wert und die Request-URL wird ungültig.

So beheben Sie das:

Öffnen Sie den Connector und prüfen Sie die Request-URL und den Body auf Attribut-Pillen.
Löschen Sie alle Pillen, die manuell eingegeben wurden, und ersetzen Sie sie, indem Sie das korrekte Attribut aus dem Attribute Inserter auswählen.
Wenn Ihre URL die Intercom Contact ID benötigt, wählen Sie Contact ID (user.id) aus dem Picker — nicht User ID (user_id). Die Contacts API erwartet die von Intercom erzeugte Contact ID (user.id), nicht die extern gesetzte User ID (user_id).

Connector-Ausgabe füllt Unterhaltung-Attribute nicht

Problem: Ein Data Connector-Schritt läuft und liefert die erwarteten Daten, aber der Wert erscheint nicht als Unterhaltungsattribut — und spätere Schritte in der Procedure können nicht darauf zugreifen.

Lösung: Unterhaltungsattribute werden zu Beginn einer Unterhaltung gesetzt und können während einer laufenden Procedure nicht in Echtzeit aktualisiert werden. Ein Connector, der innerhalb einer Procedure ausgeführt wird, kann während der Unterhaltung keinen neuen Wert in ein Conversation-Attribut schreiben.

Was das in der Praxis bedeutet:

Verwenden Sie Connector-Ausgaben direkt in späteren Schritten: Die Daten, die Ihr Connector zurückgibt, sind als Step-Output innerhalb der Procedure verfügbar. Referenzieren Sie sie in nachfolgenden Schrittanweisungen mit der @connector_name-Output-Syntax. Der Wert ist innerhalb der Procedure zugänglich — er erscheint nur nicht als Unterhaltungsattribut im Inbox.
Um Daten in einem Unterhaltungsattribut zu persistieren: Verwenden Sie einen Handoff to workflow-Schritt und setzen Sie den Attributwert innerhalb des Workflows. Beachten Sie, dass die Procedure nach dem Handoff nicht fortgesetzt wird, planen Sie also Ihren Ablauf so, dass alles vor dem Handoff abgeschlossen ist.

Data Connector ist auf READ statt UPDATE gesetzt

Problem: Die Procedure läuft, sammelt oder speichert aber keine Kundeneingaben, obwohl der Data Connector-Schritt ausgeführt zu sein scheint.

Lösung: Prüfen Sie den Action-Typ des Data Connector-Schritts im betreffenden Schritt. READ prüft nur auf einen vorhandenen gespeicherten Wert — es wird den Kunden nicht zur Eingabe auffordern oder neue Daten speichern. UPDATE sammelt Eingaben vom Kunden und speichert sie im Attribut. Wenn Ihre Procedure Informationen vom Kunden erfassen soll (z. B. eine E-Mail-Adresse, Bestellnummer oder Kontaktgrund), wechseln Sie den Action-Typ zu UPDATE.

Erweiterte Fehlerbehandlung mit status_code

Der status_code, der von einem Data Connector-Aufruf zurückgegeben wird, ist als Output-Attribut verfügbar. Sie können diesen in einem Condition-Schritt referenzieren, um anhand bestimmter HTTP-Response-Codes zu verzweigen und so präzise zu steuern, wie Fin verschiedene Fehlerfälle behandelt, anstatt sich auf einen einfachen Bestehen/Nichtbestehen-Zweig zu verlassen.

Zum Beispiel können Sie eine 404 (Ressource nicht gefunden) an eine andere Nachricht senden als eine 500 (Serverfehler) oder nur bei einem bestimmten Fehlercode an einen menschlichen Agenten eskalieren.

Tipp: Siehe How to write code conditions for Fin Procedures für Codebeispiele zur Verwendung von status_code in einem Condition-Schritt.

Fixes mit Simulationen validieren

Bevor Sie Ihre Procedure live schalten, verwenden Sie Simulations, um die Behebung zu verifizieren:

Preview vs. Simulations — welches sollte ich verwenden? Preview zeigt die vollständige, kundenorientierte Erfahrung. Die Verwendung von Preview, während Ihre Procedure live ist, kann Schritt-Nachrichten an echte Kunden ausliefern. Simulations führen die Procedure im Hintergrund ohne kundenseitige Ausgabe aus — sie sind die sicherste Methode, Logik und Trigger-Matching zu überprüfen, bevor Sie live gehen.

Navigieren Sie zum Procedure Editor und klicken Sie auf Test.
Führen Sie eine Simulation aus, bei der die KI als Kunde im fehlerhaften Szenario agiert.
Überprüfen Sie das Bestehen/Nichtbestehen-Ergebnis und das KI-Urteil, um die Zuverlässigkeit der Logik zu bestätigen.

FAQs

Funktioniert der Conversation Debugger für Standard-Fin-Unterhaltungen?

Nein, die „Fin's thoughts“-Timeline und der Debugger sind nur verfügbar, wenn eine Procedure ausgelöst wurde. Wenn Fin in einer Standardunterhaltung eine unerwartete Antwort gab, sind diese Tools nicht vorhanden — prüfen Sie stattdessen die Inbox-Unterhaltungsereignisse.

Wie lange werden Data Connector-Logs gespeichert?

Data Connector-Antwortlogs werden standardmäßig bis zu 14 days gespeichert. Wenn Ihr Workspace strengere Datenschutzanforderungen hat, kann Intercom dies auf 7 days auf Anfrage reduzieren — wenden Sie sich an unser Support-Team, um dies zu aktivieren. Greifen Sie auf Ihre Logs unter Settings > Integrations > Data connectors > Logs zu.

Kann ich Simulations verwenden, um Data Connector-Antworten zu testen?

Ja — Simulations führen die gesamte Procedure inkl. aller Data Connector-Schritte aus und sind damit die zuverlässigste Methode, das Verhalten von Connectoren vor dem Livegang zu überprüfen.

Warum wird meine Procedure von einem Workflow blockiert?

Workflows laufen, bevor Fin die Procedure-Intent-Analyse durchführt. Wenn ein Workflow für denselben Conversation-Trigger aktiv ist, kann er die Unterhaltung routen, bevor Fin eine Procedure zuordnen kann. Um dies zu beheben: Überprüfen Sie Ihre aktiven workflows auf überlappende Trigger und stellen Sie sicher, dass der Let Fin Handle-Block im Workflow-Pfad korrekt konfiguriert ist, in dem Sie Procedures verfügbar machen möchten.

Warum hat meine Procedure unerwartet an einen Menschen übergeben?

Es gibt zwei Wege, wie eine Procedure an einen Menschen übergeben werden kann:

Standard-Eskalationsverhalten — Fin eskaliert automatisch basierend auf seiner eingebauten Logik: wenn ein Kunde deutlich darum bittet, mit einem Menschen zu sprechen, wenn Fin starken Frust oder Ärger erkennt oder wenn der Kunde in einer sich wiederholenden Schleife feststeckt. Dies tritt immer ein, unabhängig davon, wie Ihre Procedure konfiguriert ist.
Konfigurierter Handover — Ein Handoff to team-Schritt, den Sie an einem bestimmten Punkt in der Prozedur hinzugefügt haben, oder prozedurspezifische Anweisungen, die Sie verfasst haben und die Fin anweisen, in einem bestimmten Szenario zu übergeben.

Wenn die Übergabe unerwartet war, verwenden Sie Fin's thoughts im Konversations-Debugger, um zu sehen, welcher Typ ausgelöst wurde und in welchem Schritt.

Warum wird meine Escalation Guidance innerhalb einer Prozedur nicht ausgelöst?

Escalation Guidance gilt standardmäßig nicht innerhalb einer Prozedur — Sie müssen sie explizit im Guidance-Bereich der Prozedur aktivieren:

Öffnen Sie Ihre Prozedur, klicken Sie im Editor Instructions oben rechts auf das Zahnrad und klicken Sie auf Guidance.
Wählen Sie die arbeitsbereichsweiten Guidance-Kategorien, die Sie anwenden möchten, einschließlich Handover and escalation.
Fin kombiniert die ausgewählte arbeitsbereichsweite Guidance mit allen prozedurspezifischen Anweisungen, die Sie verfasst haben.

Hinweis: Fins standardmäßiges Escalation-Verhalten (Kunde bittet um einen Menschen, Frustration erkannt, sich wiederholende Schleife) wird innerhalb einer Prozedur immer unabhängig von den Guidance-Einstellungen ausgelöst. Das Guidance-Feld steuert nur Ihre arbeitsbereichsweiten Escalation Guidance und Escalation Rules.

Was ist der Unterschied zwischen Handoff to team und Handoff to workflow?

Beide Schritte beenden die Prozedur, leiten die Konversation jedoch unterschiedlich weiter:

Handoff to team — Beendet die Prozedur und übergibt die Konversation an einen menschlichen Kollegen. Die Konversation folgt dann dem in Ihrem Deploy workflow konfigurierten Eskalationspfad nach dem Let Fin handle (Let Fin handle Block)-Schritt.
Handoff to workflow — Beendet die Prozedur und übergibt die Konversation an einen bestimmten wiederverwendbaren Workflow, den Sie bereits erstellt haben (z. B. eine Zufriedenheitsumfrage oder einen Weiterleitungsfluss zu Spezialisten). Die Prozedur wird nach Abschluss des Workflows nicht fortgesetzt.

Wird eine Prozedur-Übergabe als Fin Outcome berechnet?

Eine Fin Prozedur wird nur dann als Fin Outcome berechnet, wenn die Konversation auf eine von zwei Arten endet:

Resolution — der Kunde bestätigt, dass Fin sein Problem gelöst hat, oder fragt nach der Antwort von Fin nicht weiter.
Procedure Handoff — Fin übergibt an ein Team, einen Kollegen oder einen Workflow über einen konfigurierten Handoff-Schritt oder prozedurspezifische Anweisungen, die Sie eingerichtet haben.
In beiden Fällen werden Ihnen $0.99 berechnet — und nur einmal pro Konversation, unabhängig davon, wie viele Schritte Fin ausgeführt hat oder wie viele Fragen der Kunde gestellt hat.

Hinweis: Ihnen werden keine Gebühren berechnet, wenn eine Prozedur nicht abgeschlossen wird, die Konversation endet, ohne eines dieser Ergebnisse zu erreichen, ein Kunde zu irgendeinem Zeitpunkt darum bittet, mit einem Menschen zu sprechen, oder die Konversation durch Fins standardmäßiges Escalation-Verhalten oder arbeitsbereichsweite Escalation Rules beendet wird.

Für vollständige Informationen siehe Understanding Fin Outcomes.

Meine Prozedur stoppt mitten in der Konversation — könnte sie wegen eines Timeouts abbrechen?

Ja. Prozeduren laufen innerhalb eines Let Fin Handle-Blocks in Ihrem Workflow, und dieser Block hat ein standardmäßiges Inaktivitäts-Timeout. Wenn ein Kunde länger als dieses Timeout für eine Antwort benötigt, kann der Block schließen, bevor die Prozedur abgeschlossen ist. Um dies zu beheben, öffnen Sie den Let Fin Handle-Block in Ihren Workflow-Einstellungen und erhöhen Sie das Inaktivitäts-Timeout, um besser zur erwarteten Gesprächsdauer zu passen.

Kann ich Guidance verwenden, um eine Prozedur auszulösen?

Nein. Guidance steuert, wie Fin antwortet und sich verhält — es kann eine Prozedur nicht starten oder eine Konversation in eine Prozedur leiten. Die beiden Systeme sind getrennt: Guidance formt Fins Ton und Eskalationsregeln; Prozeduren definieren Schritt-für-Schritt-Workflows, denen Fin folgt, wenn eine bestimmte Absicht erkannt wird.

Um während einer Konversation von einer Prozedur zu einer anderen zu wechseln, verwenden Sie den @Switch-Befehl innerhalb der Quellprozedur, oder aktivieren Sie Agentic Switch in den Prozedureinstellungen (siehe „4. Help Center content taking priority“ in diesem Artikel).

Wenn Sie möchten, dass Fin intelligent entscheidet, wann ein Datenconnector aufgerufen oder ein bestimmter Ablauf basierend auf dem, was der Kunde sagt, ausgeführt werden soll, bauen Sie diese Logik in eine Prozedur anstatt in Guidance ein.

Meine Code-Bedingung verzweigt nicht — wie debugge ich das?

Code-Bedingungen schlagen still fehl, wenn ein Syntaxfehler vorliegt oder wenn der Datenpfad, auf den Sie zugreifen möchten, im Konversationskontext nicht existiert. Fin meldet den Fehler nicht direkt — es folgt einfach dem Else-Zweig oder bleibt stehen. So diagnostizieren Sie es:

Öffnen Sie die Konversation im Inbox und aktivieren Sie Show conversation events (siehe „Accessing the conversation debugger“ oben).
In Fin's thoughts prüfen Sie, welchen Wert Fin als Eingabe für Ihre Bedingung erhalten hat. Wenn der Wert null oder undefined ist, ist der Datenpfad in Ihrem Code falsch.
Überprüfen Sie diese gängigen Datenzugriffsmuster: • E-Mail-Adresse: inputs["user"]["email"] — gibt die E-Mail-Adresse des Kunden zurück, falls vorhanden, ansonsten None • Connector-Ausgabe: Verwenden Sie den genauen Feldnamen aus dem Antwortschema Ihres Connectors • Gesprächsattribut: inputs["conversation"]["attribute_name"]
Testen Sie Ihr Code-Block in einem Python-Interpreter, bevor Sie ihn in die Prozedur einfügen. Das erkennt Syntaxfehler sofort, ohne ein Live-Gespräch ausführen zu müssen.
Wenn die Bedingung ausgewertet wird, aber zum falschen Zweig führt, fügen Sie eine print()-Anweisung in Ihren Code-Block ein, um den tatsächlichen Wert zu protokollieren, den Fin erhält. Die Ausgabe erscheint in den Konversationsereignissen.

Hinweis: Der Kundentyp (user vs. lead) ist derzeit nicht als Prozedurattribut verfügbar. Wenn Sie nach Kundentyp verzweigen müssen, verwenden Sie eine Type-Bedingung in Ihrem Workflow vor dem Fin-Schritt.

Verwandte Artikel

Fehlerbehebung bei Fin-Prozeduren und Datenconnectoren