Wenn eine Fin Procedure eine Konversation nicht wie erwartet löst, können Sie integrierte Inspektionswerkzeuge nutzen, um Fin's Entscheidungslogik zu untersuchen. Verwenden Sie diese Anleitung, um zu erkennen, wo ein Ablauf abgewichen ist und wie Sie Ihre Anweisungen verfeinern können.

Was Sie lernen werden

Fehler bei Procedures mit Fin's Gedanken und Konversationsereignissen debuggen.
Häufige Probleme diagnostizieren wie falsche Procedure-Auslöser, Schritte außerhalb der Reihenfolge und Fehler bei Verzweigungen.
Fehler bei Datenverbindungen beheben, einschließlich Authentifizierungsfehler und fehlender Daten.
Korrekturen vor dem Live-Gang mit Simulationen validieren.

Zugriff auf den Konversations-Debugger

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

Öffnen Sie die spezifische Konversation im Inbox.
Klicken Sie auf das Symbol mit den drei Punkten oben rechts im Konversationskopf.
Wählen Sie Konversationsereignisse anzeigen.

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

Inspektion von "Fin's Gedanken"

Sobald Konversationsereignisse sichtbar sind, können Sie die Begründung hinter jedem Schritt sehen, den Fin während einer Procedure unternommen hat. Um Fin’s Entscheidungsprozess nachzuvollziehen, suchen Sie die Fin's thoughts-Ereignisse in der Konversationszeitleiste. Diese Ereignisse fassen Fin’s Überlegungen zusammen, bevor eine Nachricht gesendet oder eine Aktion ausgeführt wird.

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

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

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

Häufige Fehler bei Procedures

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

Procedure wird überhaupt nicht ausgelöst

Bevor Sie die unten nummerierten Fehler überprüfen, gehen Sie zuerst diese Grundlagen durch:

Überprüfen Sie, ob die Procedure veröffentlicht ist: Entwurfs-Procedures werden für Kunden nicht ausgelöst. Stellen Sie sicher, dass der Status im Editor auf Published gesetzt ist.
Überprüfen Sie, ob Simple Deploy aktiv ist: Wenn Simple Deploy deaktiviert ist, führt Fin keine Procedures aus. Gehen Sie zu Fin AI Agent > Deploy > Chat und bestätigen Sie, dass Fin aktiviert ist.
Überprüfen Sie die Zielgruppenansprache: Ein häufiger Fehler ist, Users anzusprechen, wenn der Kunde ein Lead ist (oder umgekehrt). Im Abschnitt „Wann diese Procedure verwenden“ klicken Sie auf die Zielgruppenschaltfläche und prüfen Sie, ob der richtige Zielgruppentyp 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 abfangen, bevor Fin die Procedure auslösen kann.
Überprüfen Sie den Umfang der Auslösekriterien: Zu enge Kriterien verhindern, dass Fin gültige Kundenmeldungen erkennt. Prüfen Sie die Beschreibung „Wann diese Procedure verwenden“ und fügen Sie positive Beispiele (Meldungen, die sie auslösen sollten) und negative Beispiele (Meldungen, die sie nicht auslösen sollten) hinzu.

1. 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 "Wann diese Procedure verwenden"-Anweisungen. Verwenden Sie positive und negative Beispiele, um Fin bei der Unterscheidung ähnlicher Absichten zu helfen. Wenn eine neue Procedure ähnliche Auslösekriterien wie eine bestehende veröffentlichte Procedure hat, kann die veröffentlichte Vorrang haben. Um die neue Procedure während des Tests zu isolieren: schließen Sie Ihren Testnutzer vorübergehend von der bestehenden Procedure aus, indem Sie deren Zielgruppenkriterien 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 > Gedanken erweitern im Konversations-Debugger, um zu bestätigen, welche Procedure tatsächlich ausgelöst wurde.

2. Schritte außerhalb der Reihenfolge

Problem: Fin überspringt einen erforderlichen Schritt oder geht zu früh zur Lösung über.

Lösung: Prüfen Sie Ihre Anweisungen in natürlicher Sprache auf Mehrdeutigkeiten. Wenn ein Schritt von einem bestimmten Datenelement abhängt, stellen Sie sicher, dass die Anweisung ausdrücklich lautet: „Nur fortfahren, wenn [Daten] bereitgestellt werden.“

3. Fehler bei Verzweigungslogik

Problem: Fin folgt dem „Else“-Pfad, obwohl er dem „If“-Pfad hätte folgen sollen.

Lösung: Überprüfen Sie die Bedingungen. Wenn Sie natürliche Sprache für Verzweigungen verwenden, versuchen Sie, die Formulierung zur Klarstellung zu ändern. Bei komplexer Logik (z. B. Datumsberechnungen) sollten Sie Python-Codeblöcke verwenden, um strenge deterministische Regeln durchzusetzen.

4. Help Center-Inhalte haben Vorrang

Problem: Fin antwortet aus dem Help Center, anstatt die Procedure auszuführen, obwohl die Absicht des Kunden eindeutig den Auslösekriterien der Procedure entspricht.

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

Option 1: Procedure Switching aktivieren
Agentic Switch ist eine pro-Procedure-Einstellung, die es Fin ermöglicht, automatisch von der aktuellen Procedure zu einer anderen aktiven Procedure zu wechseln, wenn erkannt 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 aktiven Procedure-Auslöserbeschreibungen, um zu entscheiden, wann ein Wechsel dem Kunden besser dient.
- Wenn mehrere Procedures zutreffen könnten, stellt Fin möglicherweise eine klärende Frage, um die beste auszuwählen.
- Nur die Quell-Procedure (die, 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: Konfliktierende Help Center-Inhalte entfernen oder aktualisieren
Wenn das Aktivieren des Agentic Switch das Problem nicht löst, ist die zuverlässigste Lösung, den Help Center-Inhalt zu entfernen oder zu aktualisieren, den Fin anzeigt, anstatt das Verfahren auszuführen. Fin greift standardmäßig auf Help Center-Antworten zurück, wenn relevante Inhalte zu einem Thema vorhanden sind – wenn also ein Artikel dieselbe Absicht wie Ihr Verfahren abdeckt, antwortet Fin möglicherweise direkt daraus, anstatt das Verfahren auszulösen.

Um den widersprüchlichen Inhalt 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, um Kunden an den Support zu verweisen, damit Fin stattdessen zum Verfahren weiterleitet.

Beispiel: Ein Unternehmen hat ein Verfahren, das Rückerstattungsanfragen bearbeitet – es sammelt die Bestellnummer, prüft die Berechtigung und verarbeitet die Rückerstattung automatisch. Sie haben auch einen Help Center-Artikel mit dem Titel „Wie bekomme ich eine Rückerstattung?“, der die Rückerstattungsrichtlinie erklärt. Wenn ein Kunde „Ich möchte eine Rückerstattung“ schreibt, findet Fin den Help Center-Artikel und antwortet mit der Richtlinienerklärung, anstatt das Verfahren auszulösen. In diesem Fall entfernt die Aktualisierung des Artikels mit einer Formulierung wie „Um eine Rückerstattung zu beantragen, starten Sie einen Chat und unser Assistent führt Sie durch den Prozess“ die widersprüchliche Antwort und leitet Kunden stattdessen zum Verfahren weiter.

5. Verfahren stockt oder bricht vor Abschluss ab

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

Lösung: Dies wird meist durch Designmuster verursacht, die Fins Fähigkeit verwirren, den aktuellen Stand im Verfahren zu verfolgen. Prüfen Sie Folgendes:

Überflüssige „Sofort fortfahren“-Anweisungen: Wenn mehrere Schritte Anweisungen wie „sofort zum nächsten Schritt fortfahren“ enthalten, kann Fin bereits abgeschlossene Schritte erneut bewerten, anstatt voranzuschreiten. Entfernen Sie diese Anweisungen und lassen Sie Fin das Verfahren natürlich entsprechend dem Ablauf durchlaufen.
Schritt-Sprung-Anweisungen: Formulierungen wie „gehe zurück zu Schritt 2“ oder „wiederhole den Verifizierungsschritt“ können dazu führen, dass Fin zwischen Schritten hin- und herläuft, anstatt voranzukommen. Gestalten Sie jeden Schritt so, dass es einen klaren Vorwärtspfad gibt.
Überlappende Bedingungslogik: Wenn zwei Bedingungen gleichzeitig als wahr bewertet werden können, kann Fin unvorhersehbar verzweigen oder stocken. Stellen Sie sicher, dass Ihre Bedingungen sich gegenseitig ausschließen – es sollte zu jedem Zeitpunkt nur einen wahren Zweig geben.
Sub-Verfahren endet ohne Fortsetzung: Wenn ein Sub-Verfahren abgeschlossen ist, das Hauptverfahren aber keine klare Anweisung für den nächsten Schritt hat, kann Fin das Ende des Sub-Verfahrens als Ende des gesamten Ablaufs interpretieren. Fügen Sie im Schritt, der das Sub-Verfahren aufruft, eine explizite Anweisung hinzu: „Sobald das Sub-Verfahren abgeschlossen ist, fahren Sie mit [Name des nächsten Schritts] fort.“

Verwenden Sie Fin's thoughts > Mehr anzeigen im Konversations-Debugger, um genau zu identifizieren, bei welchem Schritt Fin war, als das Verfahren unerwartet beendet wurde.

Fehlerbehebung bei Datenverbindungen

Dieser Abschnitt behandelt Fehler, die speziell bei Datenverbindungen innerhalb eines Verfahrens auftreten. Wenn Ihr Connector im Standalone-Test funktioniert, aber während eines Live-Verfahrens fehlschlägt, beginnen Sie hier.

Connector funktioniert im Test, aber nicht im Live-Verfahren

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

Lösung: Dies wird meist durch eines der Folgenden verursacht:

Zugangsdaten: Speichern und veröffentlichen Sie nach dem Rotieren eines Schlüssels erneut. Prüfen Sie auf versteckte Zeichen wie nachgestellte Leerzeichen in Token-Werten.
Berechtigungen: Eine kürzliche Sicherheitsänderung in Ihrem externen System könnte den Zugriff entfernt haben.
IP-Whitelist: Bestätigen Sie, dass Intercoms ausgehende IPs eingeschlossen sind. Kontaktieren Sie Ihren Account Manager für die aktuellen Bereiche.

Wichtig: Wenn Ihr Connector ohne Änderungen Ihrerseits nicht mehr funktioniert, prüfen Sie, ob Ihr externer API-Anbieter (z. B. Shopify, Stripe) einen Endpunkt aktualisiert oder eingestellt hat.

401- und 403-Autorisierungsfehler

401 Unauthorized: Das Token fehlt, ist abgelaufen oder fehlerhaft. Intercom versucht automatisch einmal erneut. Prüfen Sie den Logs-Tab, um zu bestätigen, ob ein Refresh versucht wurde.
403 Forbidden: Das Token ist gültig, aber es fehlen Berechtigungen. Überprüfen Sie die Berechtigungen in Ihrem externen System.
OAuth users: Verwenden Sie die Reauthenticate-Schaltfläche, anstatt das Token zu löschen und neu zu erstellen.

Connector scheint nicht auszulösen

Prüfen Sie die Logs: Navigieren Sie zu Settings > Integrations > Data connectors > Logs. Wenn kein Log-Eintrag vorhanden ist, wurde der Schritt wahrscheinlich übersprungen; prüfen Sie die vorherige Verzweigungslogik.
Prüfen Sie die Konversationsereignisse: Wählen Sie Logs von jedem Fehlerereignis im Inbox für vollständige Details aus.

Connector liefert Daten, aber Fin nutzt sie nicht

Verwenden Sie Fin's thoughts, um zu sehen, wie Fin die Connector-Antwort interpretiert hat.
Machen Sie die Schrittanweisung expliziter: „Verwenden Sie @connector_name, um diese Frage zu beantworten – verwenden Sie keine knowledge base-Inhalte.“
Prüfen Sie, ob die Antwort leer oder null ist; Fin kann auf andere Quellen zurückgreifen, wenn keine verwertbaren Daten gefunden werden.
Fin ruft pro Runde nur einen Connector auf: Wenn Ihr Verfahren mehrere Connector-Aufrufe in Folge benötigt, muss jeder Aufruf ein eigener Schritt sein. Fin verarbeitet pro Gesprächsrunde nur einen Tool-Aufruf – es kann nicht mehrere Connector-Aufrufe innerhalb einer einzigen Schrittanweisung verketten.

Wichtig: Fin kann pro Runde nur einen Connector-Aufruf verarbeiten. Wenn Ihr MCP-Server zwei separate Antworten über denselben SSE-Stream sendet, kann Fin die erste Antwort nicht zuverlässig zur Erstellung seiner Antwort verwenden.

Connector erscheint nicht im Verfahren-Editor

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

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

Bestätigen Sie, dass der Connector auf Live gesetzt ist: Gehen Sie zu Settings > Integrations > Data connectors und prüfen Sie den Status des Connectors. Ein Connector im Entwurf wird im Verfahren-Editor nicht angezeigt.
Vergewissern Sie sich, dass mindestens eine Aktion konfiguriert ist: Ein Connector ohne definierte Aktionen wird im Verfahren-Editor nicht als Option angezeigt, auch wenn er auf Live steht.
Prüfen Sie Ihre Rollenberechtigungen: Einige Rollen können Connectoren in den Einstellungen sehen, haben aber keinen Zugriff im Verfahren-Editor. Stellen Sie sicher, dass Ihre Rolle Zugang zu beiden Bereichen hat.
Seite aktualisieren: Der Verfahren-Editor benötigt gelegentlich ein hartes Neuladen, um kürzlich veröffentlichte Connectoren anzuzeigen. Verwenden Sie ⌘ + Shift + R (Mac) oder Strg + Shift + R (Windows).
Kontaktieren Sie den Intercom Support: Wenn keine der oben genannten Maßnahmen das Problem löst, wenden Sie sich mit dem Connector-Namen und Ihren Workspace-Details an den Intercom Support. Einige Workspace-Konfigurationen erfordern einen manuellen Schritt, um einen Connector im Verfahren-Editor verfügbar zu machen.

Connector schlägt im Auto-Execute-Modus fehl

Problem: Der Datenconnector ist so konfiguriert, dass er automatisch ausgeführt wird – ohne Aufforderung des Kunden – schlägt aber während einer Live-Konversation stillschweigend fehl. Fin eskaliert oder gibt eine unerwartete Antwort, und es gibt keinen sichtbaren Fehler in der Konversation.

Lösung: Im Auto-Execute-Modus kann Fin einen fehlgeschlagenen Connector-Schritt nicht überspringen und das Verfahren fortsetzen. Wenn der Connector einen Fehler zurückgibt, behandelt Fin den gesamten Schritt als unlösbar und eskaliert entweder an einen Menschen oder greift auf sein Standardverhalten zurück.

Es gibt zwei Möglichkeiten, dies zu handhaben:

Passen Sie Ihre externe API an, um einen Fallback-Wert zurückzugeben: Anstatt 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 sie ein leeres oder Standardergebnis zurückgibt, auf das Fin reagieren kann. Dies ist die zuverlässigste Lösung, da Fin immer etwas erhält, mit dem es arbeiten kann.
Fügen Sie nach dem Connector-Aufruf einen Bedingungsschritt hinzu: Verwenden Sie die status_code-Ausgabe des Connectors, um bei einem Fehler eine freundliche Nachricht oder einen kontrollierten Eskalationspfad zu wählen. Siehe „Erweiterte Fehlerbehandlung mit status_code“ in diesem Artikel, um zu erfahren, wie das eingerichtet wird.

Der Connector-Ausgang füllt keine Konversationsattribute aus

Problem: Ein Daten-Connector-Schritt wird ausgeführt und liefert die erwarteten Daten zurück, aber der Wert erscheint nicht als Konversationsattribut – und spätere Schritte im Ablauf können nicht darauf zugreifen.

Lösung: Konversationsattribute werden zu Beginn einer Konversation gesetzt und können während der Ausführung einer Prozedur nicht in Echtzeit aktualisiert werden. Ein Connector, der innerhalb einer Prozedur ausgeführt wird, kann während der Konversation keinen neuen Wert in ein Konversationsattribut schreiben.

Was das in der Praxis bedeutet:

Verwenden Sie den Connector-Ausgang direkt in späteren Schritten: Die Daten, die Ihr Connector zurückgibt, sind als Schritt-Ausgang innerhalb der Prozedur verfügbar. Verweisen Sie in nachfolgenden Schritt-Anweisungen mit der Syntax @connector_name darauf. Der Wert ist innerhalb der Prozedur zugänglich – er erscheint nur nicht als Konversationsattribut im Inbox.
Um Daten in einem Konversationsattribut zu speichern: Verwenden Sie einen Handoff to workflow-Schritt und setzen Sie den Attributwert stattdessen innerhalb des Workflows. Beachten Sie, dass die Prozedur nach dem Handoff nicht fortgesetzt wird, planen Sie Ihren Ablauf also so, dass er vor dem Handoff abgeschlossen ist.

Daten-Connector ist auf READ statt UPDATE eingestellt

Problem: Die Prozedur läuft, sammelt oder speichert jedoch keine Kundeneingaben, obwohl der Daten-Connector-Schritt ausgeführt zu werden scheint.

Lösung: Überprüfen Sie den Aktionstyp des Daten-Connectors im entsprechenden Schritt. READ prüft nur einen vorhandenen gespeicherten Wert – es fordert den Kunden nicht zur Eingabe auf und speichert keine neuen Daten. UPDATE sammelt Eingaben vom Kunden und speichert sie im Attribut. Wenn Ihre Prozedur Informationen vom Kunden sammeln soll (z. B. E-Mail-Adresse, Bestellnummer oder Kontaktgrund), ändern Sie den Aktionstyp auf UPDATE.

Erweiterte Fehlerbehandlung mit status_code

Der status_code, der von einem Daten-Connector-Aufruf zurückgegeben wird, wird als Ausgabeattribut angezeigt. Sie können diesen in einem Condition step referenzieren, um auf bestimmte HTTP-Antwortcodes zu verzweigen und so eine präzise Steuerung darüber zu erhalten, wie Fin verschiedene Fehlerfälle behandelt, anstatt sich auf einen einzigen Erfolgs-/Fehlerzweig zu verlassen.

Zum Beispiel können Sie eine 404 (Ressource nicht gefunden) an eine andere Nachricht weiterleiten als eine 500 (Serverfehler) oder nur dann an einen menschlichen Agenten eskalieren, wenn ein bestimmter Fehlercode zurückgegeben wird.

Tipp: Siehe Wie man Code-Bedingungen für Fin Procedures schreibt für Codebeispiele zur Verwendung von status_code in einem Condition step.

Fixes mit Simulationen validieren

Bevor Sie Ihre Prozedur live schalten, verwenden Sie Simulations, um die Korrektur zu überprüfen:

Vorschau vs. Simulations – welche soll ich verwenden? Vorschau zeigt das vollständige kundenseitige Erlebnis. Die Verwendung der Vorschau während Ihre Prozedur live ist, kann Schritt-Nachrichten an echte Kunden ausgeben. Simulations führen die Prozedur im Hintergrund ohne kundenseitige Ausgabe aus – sie sind die sicherste Methode, Logik und Trigger-Matching vor dem Livegang zu validieren.

Navigieren Sie zum Prozedur-Editor und klicken Sie auf Test.
Führen Sie eine Simulation durch, 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 Konversations-Debugger für Standard-Fin-Konversationen?

Nein, die "Fin's thoughts"-Timeline und der Debugger sind nur verfügbar, wenn eine Prozedur ausgelöst wurde. Wenn Fin in einer Standard-Konversation eine unerwartete Antwort gab, sind diese Tools nicht vorhanden – prüfen Sie stattdessen die Inbox-Konversationsereignisse.

Wie lange werden Daten-Connector-Protokolle gespeichert?

Daten-Connector-Antwortprotokolle werden standardmäßig bis zu 7 Tage gespeichert. Wenn Ihr Workspace erweiterte Protokolle aktiviert hat, erhöht sich dies auf 14 Tage. Sie finden sie unter Einstellungen > Integrationen > Daten-Connector > Protokolle.

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

Ja – Simulations führen die vollständige Prozedur einschließlich aller Daten-Connector-Schritte aus und sind die zuverlässigste Methode, das Verhalten des Connectors vor dem Livegang zu validieren.

Warum wird meine Prozedur von einem Workflow blockiert?

Workflows laufen, bevor Fin die Prozedurabsicht bewertet. Wenn ein Workflow für denselben Konversationsauslöser aktiv ist, kann er die Konversation weiterleiten, bevor Fin eine Prozedur zuordnen kann. Um dies zu beheben: Überprüfen Sie Ihre aktiven Workflows auf überlappende Auslöser und stellen Sie sicher, dass der Let Fin Handle-Block im Workflow-Pfad, in dem Sie Prozeduren verfügbar machen wollen, korrekt konfiguriert ist.

Warum hat meine Prozedur unerwartet an einen Menschen übergeben?

Es gibt zwei Möglichkeiten, wie eine Prozedur an einen Menschen übergeben kann:

Standard-Eskalationsverhalten – Fin eskaliert automatisch basierend auf seiner eingebauten Logik: wenn ein Kunde klar darum bittet, mit einem Menschen zu sprechen, wenn Fin starke Frustration oder Ärger erkennt oder wenn der Kunde in einer sich wiederholenden Schleife feststeckt. Dies wird immer ausgelöst, unabhängig davon, wie Ihre Prozedur konfiguriert ist.
Konfigurierter Handoff – Ein Handoff to team-Schritt, den Sie an einer bestimmten Stelle in der Prozedur hinzugefügt haben, oder prozedurspezifische Anweisungen, die Fin anweisen, in einem bestimmten Szenario zu übergeben.

Wenn der Handoff 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 Eskalationsanleitung innerhalb einer Prozedur nicht ausgelöst?

Eskalationsanleitungen gelten standardmäßig nicht innerhalb einer Prozedur – Sie müssen sie explizit im Guidance-Panel der Prozedur aktivieren:

Öffnen Sie Ihre Prozedur, klicken Sie auf das Einstellungsrad oben rechts im Instructions-Editor und dann auf Guidance.
Wählen Sie die workspace-weiten Anleitungskategorien aus, die Sie anwenden möchten, einschließlich Handover and escalation.
Fin kombiniert die ausgewählten workspace-weiten Anleitungen mit allen prozedurspezifischen Anleitungen, die Sie geschrieben haben.

Hinweis: Das Standard-Eskalationsverhalten von Fin (Kunde bittet um einen Menschen, Frustration erkannt, sich wiederholende Schleife) wird immer innerhalb einer Prozedur ausgelöst, unabhängig von den Guidance-Einstellungen. Das Guidance-Panel steuert nur Ihre workspace-weiten Eskalationsanleitungen und Eskalationsregeln.

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 Teamkollegen. Die Konversation folgt dann dem Eskalationspfad, der in Ihrem Deploy-Workflow nach dem Let Fin handle (Let Fin handle block)-Schritt konfiguriert ist.
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 Spezialisten-Routing-Flow). Die Prozedur wird nach Abschluss des Workflows nicht fortgesetzt.

Wird ein Prozedur-Handoff als Fin Outcome berechnet?

Ein Fin Procedure 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 Fin-Antwort nicht weiter um Hilfe.
Procedure Handoff – Fin übergibt an ein Team, einen Teamkollegen oder Workflow über einen konfigurierten Handoff-Schritt oder prozedurspezifische Anleitungen, 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 Kosten berechnet, wenn eine Prozedur nicht abgeschlossen wird, vor Erreichen eines dieser Outcomes beendet wird, ein Kunde zu irgendeinem Zeitpunkt um einen Menschen bittet oder die Konversation durch das Standard-Eskalationsverhalten von Fin oder workspace-weite Eskalationsregeln endet.

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

Mein Verfahren stoppt mitten im Gespräch – könnte es eine Zeitüberschreitung sein?

Ja. Verfahren laufen innerhalb eines Let Fin Handle-Blocks in Ihrem Workflow, und dieser Block hat eine standardmäßige Inaktivitätszeitüberschreitung. Wenn ein Kunde länger als diese Zeit zum Antworten benötigt, kann der Block schließen, bevor das Verfahren abgeschlossen ist. Um dies zu beheben, öffnen Sie den Let Fin Handle-Block in Ihren Workflow-Einstellungen und erhöhen Sie die Inaktivitätszeitüberschreitung, um besser zur erwarteten Gesprächsdauer zu passen.

Kann ich Guidance verwenden, um ein Verfahren auszulösen?

Nein. Guidance steuert, wie Fin reagiert und sich verhält – es kann kein Verfahren starten oder ein Gespräch in eines leiten. Die beiden Systeme sind getrennt: Guidance bestimmt Fins Ton und Eskalationsregeln; Procedures definieren schrittweise workflows, denen Fin folgt, wenn eine bestimmte Absicht erkannt wird.

Um mitten im Gespräch von einem Verfahren zu einem anderen zu wechseln, verwenden Sie den @Switch-Befehl im Quellverfahren oder aktivieren Sie Agentic Switch in den Verfahren-Einstellungen (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 den Aussagen des Kunden verfolgt wird, bauen Sie diese Logik in ein Verfahren ein, anstatt in Guidance.

Mein Code-Bedingung verzweigt nicht – wie kann ich sie debuggen?

Code-Bedingungen schlagen still fehl, wenn ein Syntaxfehler vorliegt oder wenn der Datenpfad, auf den Sie zugreifen möchten, im Gesprächskontext nicht existiert. Fin zeigt den Fehler nicht direkt an – es folgt einfach dem Else-Zweig oder bleibt stehen. So diagnostizieren Sie das:

Öffnen Sie das Gespräch im Inbox und aktivieren Sie Show conversation events (siehe „Accessing the conversation debugger“ oben).
Überprüfen Sie in Fin's thoughts, 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: • Kundentyp: inputs["user"]["role"] – gibt "user" oder "lead" zurück • Connector-Ausgabe: Verwenden Sie den genauen Feldnamen aus dem Antwortschema Ihres Connectors • Gesprächsattribut: inputs["conversation"]["attribute_name"]
Testen Sie Ihren Codeblock in einem Python-Interpreter, bevor Sie ihn dem Verfahren hinzufügen. So werden Syntaxfehler sofort erkannt, ohne ein Live-Gespräch führen zu müssen.
Wenn die Bedingung ausgewertet wird, aber zum falschen Zweig führt, fügen Sie eine print()-Anweisung in Ihren Codeblock ein, um den tatsächlichen Wert zu protokollieren, den Fin erhält. Die Ausgabe erscheint in den Gesprächsereignissen.

Verwandte Artikel

Schnellstart: Erstellen Sie eine Fin-Prozedur

Simulationen für Fin Procedures durchführen

Fin-Verfahren erstellen

Übergang von Fin Tasks zu Procedures

Wie man Anweisungen in Fin Procedures schreibt

Fehlerbehebung bei Fin-Prozeduren und Datenverbindungen