Ein Workflow wird möglicherweise aufgrund von Konfigurationsproblemen nicht wie erwartet ausgelöst, z. B. wegen Kanal-Kompatibilität, Zielgruppenregeln, Zeitplanung oder Konflikten mit Ihren Messenger-Einstellungen. So beheben Sie diese Probleme.

Sie können überprüfen, wann ein Workflow in einer Konversation ausgelöst wurde, anhand von:

Ja, Sie können wiederverwendbare Workflows erstellen, die Kundendaten wie E-Mail, Telefon, Name sowie benutzerdefinierte Attribute, die Sie in Intercom verfolgen, sammeln.

Dies ist derzeit mit Workflows nicht möglich, aber Sie können dies als Feature-Anfrage einreichen, wenn Sie es hilfreich finden!

Um zu verhindern, dass der Willkommensbot die vollständige Nachricht und Optionen anzeigt, wenn ein Nutzer die Seite besucht, müssen Sie einen anderen Workflow-Auslöser verwenden. Statt des Auslösers „Kunde besucht eine Seite“, der dazu führt, dass der Workflow proaktiv aufpoppt, verwenden Sie den Auslöser „Kunde öffnet eine neue Konversation im Messenger“. So erscheint die Willkommensnachricht in Ihrem Workflow nur, wenn ein Nutzer eine Konversation über den Messenger startet.

Kunden können manchmal Workflows für ausgehende Nachrichten umgehen, indem sie direkt auf den Messenger-Launcher klicken und eine Konversation außerhalb des vorgesehenen Ablaufs starten.

Es gibt zwei Hauptmöglichkeiten, dies zu beheben:

Um Zugriff auf ausgehende Bots (Workflows) in Intercom zu erhalten, stellen Sie sicher, dass folgende Anforderungen erfüllt sind:

Ja, Sie können in einem Datensammelschritt auf verschiedene Weise eine Datei von einem Kunden sammeln:

Ja, Sie können Gespräche automatisch markieren, indem Sie einen Schritt „Tag conversation“ in Ihren Workflow einfügen. Klicken Sie auf Add step an einer beliebigen Stelle im Workflow-Pfad und wählen Sie Tag conversation. Dies gilt nur für zukünftige Gespräche und funktioniert nicht rückwirkend.

Um „if“-Bedingungen in Workflows zu erstellen und zu priorisieren, können Sie weitere bedingte Branches hinzufügen. Die Priorität erfolgt von oben nach unten bei der Verwendung von Branches.

Um Kunden außerhalb Ihrer Geschäftszeiten eine Nachricht zu senden – zum Beispiel, um ihnen mitzuteilen, wann sie mit einer Antwort rechnen können – richten Sie einen Workflow mit einer Branch-Bedingung ein, anstatt die Planung in Ihren Trigger-Einstellungen zu verwenden. Branches werden in Echtzeit ausgewertet und sind somit für zeitbasierte Logik zuverlässiger.

Sobald der Workflow live ist, erhalten neue Gespräche, die Ihrem Trigger entsprechen und außerhalb Ihrer konfigurierten Geschäftszeiten eintreffen, automatisch die von Ihnen eingerichtete Nachricht.

Um sicherzustellen, dass ein Workflow nur für E-Mail-Gespräche ausgelöst wird, müssen Sie die Kanal-Auswahl in Ihren Trigger-Einstellungen einschränken. Wenn ein Kanal nicht explizit aktiviert ist, lösen Gespräche auf diesem Kanal den Workflow nicht aus.

Sobald der Workflow live ist, lösen nur E-Mail-Gespräche, die Ihren Zielgruppenregeln entsprechen, diesen Workflow aus. Gespräche auf anderen Kanälen werden nicht beeinflusst.

Ja, Sie können Tags als Workflow-Zielgruppenregel in den meisten Triggern verwenden, einschließlich Conversation-, People- und Company-Tags. Beachten Sie, dass die Conversation tag-Bedingung in drei Triggern nicht verfügbar ist: Customer visits a page, Customer opens a new conversation in the Messenger und Customer clicks on a website element. Siehe Workflow-Trigger-Einstellungen konfigurieren für die Einrichtung von Workflow-Zielgruppenregeln.

Nein, das Hinzufügen eines Tags zu einem Gespräch löst keinen Workflow aus – es gibt keinen Trigger-Typ für das Hinzufügen eines Tags. Die Option Conversation tag existiert nur als Bedingung innerhalb der Zielgruppenregeln eines bestehenden Triggers, wo sie einschränkt, welche Gespräche zu einem bereits auslösenden Trigger passen (zum Beispiel Conversation tag is Bug report bei einem During a conversation-Trigger). Da es kein „Tag hinzugefügt“-Ereignis gibt, startet das manuelle Markieren eines Gesprächs im Inbox keinen Workflow von selbst.

Um eine Abfolge von Wartezeiten und Follow-up-Nachrichten zu automatisieren, wenn ein bestimmtes Tag auf ein Gespräch angewendet wird, erstellen Sie einen wiederverwendbaren Workflow, den ein Teammitglied manuell aus dem Inbox startet, anstatt sich darauf zu verlassen, dass das Tag selbst den Workflow auslöst.

Sobald Ihre erste Nachricht im Inbox ist, öffnen Sie das Gespräch, drücken Cmd/Ctrl+K, suchen Sie nach „Trigger reusable workflow“ und wählen Sie diesen Workflow aus, um ihn zu starten.

Um externe Inhalte zu einem Workflow hinzuzufügen, können Sie den Schritt „Send an app“ hinzufügen und die Content Showcase-App auswählen.

Ja, wenn Sie eine Bedingung „Message contains XYZ“ zu einem Workflow hinzufügen, wird auch im Betreff der E-Mail gesucht, nicht nur im Textkörper. Selbst wenn Sie eine separate Bedingung für „Email subject contains XYX“ verwenden, schließt „Message contains“ auch den E-Mail-Betreff mit ein.

Das hängt von den Kanälen ab, die Sie für den Workflow aktiviert haben. Für das Senden von Workflow-Nachrichten über Web, iOS, Android, Facebook, Instagram und Email fallen keine Gebühren an.

Wenn Sie jedoch SMS oder WhatsApp als einen der Workflow-Kanäle ausgewählt haben, werden alle Nachrichten, die über diese Kanäle gesendet werden, zu den jeweiligen Tarifen berechnet.

Dafür müssen Sie zwei Workflows erstellen:

Diese Einrichtung stellt sicher, dass jede Kundenantwort auf ein Resolved/Closed Ticket es automatisch auf „In progress“ setzt.

Sie können einen Workflow mit dem Auslöser „Teammate changes the conversation team assignment“ einrichten, um automatisch einen bestimmten Teamkollegen zuzuweisen, wenn eine Konversation einem Team Inbox zugewiesen wird.

Wählen Sie im Auslöserpublikum „Team assigned is [X]“ aus:

Fügen Sie dann einen Workflow-Pfad mit dem Assign-Schritt hinzu, um einem Teamkollegen zuzuweisen:

Um aktualisierte Workflow-Logik in einer Produktionsumgebung zu testen, ohne Live-Users zu beeinträchtigen:

Testen Sie nach Möglichkeit immer zuerst in einer Staging-Umgebung, um unbeabsichtigte Auswirkungen auf Live-Konversationen zu vermeiden.

Um E-Mail-Workflows zu testen, ohne Live-Users zu beeinträchtigen:

Vermeiden Sie es, ungetestete Änderungen direkt an einem Live-Workflow vorzunehmen – das Duplizieren isoliert das Risiko.

Um sicher zu testen, ob Fin Attribute korrekt erkennt:

Ja. Es gibt zwei Optionen:

Vorschau-Konversationen, die mit der Workflows Preview-Funktion erstellt wurden, erscheinen im Inbox und werden als echte Konversationen behandelt – das bedeutet, dass Vorschau-Benutzeraktivitäten in den Workflow-Berichtsmesswerten enthalten sind. Erwarten Sie, dass Vorschau-Benutzer neben echten Kunden in den Zählungen für gesendet, engagiert und abgeschlossen aufgeführt werden. Wenn Ihre Berichtszahlen nach dem Testen unerwartet hoch erscheinen, prüfen Sie, ob Vorschau-Benutzeraktivitäten gezählt wurden. Um Ihre Metriken sauber zu halten, sollten Sie Ihre gesendet/engagiert/abgeschlossen Zählungen nach jeder Vorschau-Sitzung überprüfen.

Wenn ein Kunde eine zuvor geschlossene Konversation außerhalb der Geschäftszeiten wieder öffnet, wird ein Standard-Nach-Geschäftszeiten-Workflow möglicherweise nicht wie erwartet ausgelöst.

Um dies zuverlässig zu handhaben:

Sobald live, prüft Intercom die Zeit anhand Ihrer Geschäftszeiten, wann immer ein Kunde eine geschlossene Konversation wieder öffnet, und sendet Ihre Nachricht, wenn sie außerhalb Ihrer konfigurierten Zeiten liegt.

Wenn ein Kunde auf eine geschlossene oder snoozed Conversation antwortet, öffnet Intercom sie wieder (oder hebt das Snooze auf), bevor der Workflow ausgewertet wird. Wenn der Workflow Customer sends any message seine Bedingungen prüft, ist die Conversation bereits geöffnet – daher passt eine Bedingung wie Conversation status = Closed oder Conversation status = Snoozed nie. Dadurch ist das Conversation-Status-Attribut als Bedingung in diesem Workflow effektiv unbrauchbar.

Dasselbe Wiederöffnungsverhalten gilt für snoozed Conversations – eine Kundenantwort hebt das Snooze automatisch auf, bevor die Workflow-Auswertung erfolgt.

Workflow-Ziele zählen nur Ereignisse, die nach dem Auslösen des Workflows passieren – Ereignisse davor werden nicht berücksichtigt.

Nein, die Anzeige von Quick Reply-Buttons innerhalb von Workflows kann nicht angepasst werden.

Nein, Workflows können keine Daten direkt an externe E-Mail-Adressen senden. Workflows können Kundendaten (wie Name, E-Mail und benutzerdefinierte Attribute) sammeln und Conversations unzugeordnet lassen, aber der Versand dieser Daten an externe E-Mail-Adressen wird in Workflows nicht unterstützt. Wenn Sie gesammelte Daten extern weiterleiten müssen, verwenden Sie einen Data Connector oder integrieren Sie ein Drittanbieter-Tool über webhook.

Nein, die Eingabevalidierung für PIN- und ID-Längen wird im Messenger oder in Workflows nicht unterstützt. Wenn Sie bestimmte Zeichen- oder Ziffernanforderungen durchsetzen müssen, muss dies extern erfolgen – beispielsweise über Ihr eigenes Backend oder einen Data Connector, der die Eingabe nach der Erfassung validiert.

Wenn Ihr Workflow bei bestimmten Conversations nicht funktioniert, stellen Sie sicher, dass Ihre Workflow-Zielgruppeneinstellungen auf die richtigen Teilnehmer-Typen (Leads, Visitors und Users) eingestellt sind. Aktualisieren Sie die Zielgruppe entsprechend, um das Problem zu beheben. Stellen Sie außerdem sicher, dass keine Konfigurationsfehler verhindern, dass der Workflow die richtige Zielgruppe anspricht. Wenn Ihr Workflow beispielsweise nur für „Users“ ausgelöst wird, aktivieren Interaktionen mit „Leads“ den Workflow nicht. Passen Sie die Zielgruppenfilter an, um sowohl „Leads“ als auch „Users“ einzuschließen, oder stellen Sie sicher, dass der Conversation-Typ mit der Workflow-Einstellung übereinstimmt.

Dies kann passieren, wenn die Content Security Policy (CSP) Ihrer Website bestimmte Verbindungen zu Intercom blockiert, die für die erwartete Funktion des Messengers erforderlich sind. Die CSP muss möglicherweise überprüft und aktualisiert werden. Weitere Details zur Verwendung von Intercom mit CSP finden Sie in diesem Artikel.

Sie können pro Conversation nur einen kundenorientierten Workflow-Auslöser haben. Um dies zu erreichen, bearbeiten Sie Ihren bestehenden Workflow „When customer sends their first message“ und fügen Sie einen Schritt hinzu, um die erste Nachricht des Kunden zu erfassen, gefolgt von einem Schritt, der Ihre Folge-Nachricht sendet: „Wir prüfen, bitte warten.“

Datum-&-Uhrzeit-Attribute können in Workflows nicht verwendet werden, da die Zeitzone des Kunden nicht zuverlässig validiert werden kann, was zu Abweichungen führen kann – besonders wenn der Kunde VPN nutzt oder sich an einem anderen Standort als Ihre Bürozeiten befindet. Um mögliche Diskrepanzen mit den Bürozeiten des Workspaces zu vermeiden, sind Datum-&-Uhrzeit-Attribute in Workflows nicht verfügbar.

Nein. Datumsattribute können in Workflow-Schritten nicht gesetzt werden – dies ist eine aktuelle Produktbeschränkung. Workflow-Aktionen, die Attributwerte setzen (wie Set conversation data), unterstützen den Datumsattributtyp nicht.

Um ein Datumsattribut zu aktualisieren, können Sie als Workaround einen Data Connector mit unserer REST API verwenden.

Die Zielgruppenregel „Conversation starter is Outbound message“ für einen Workflow gilt nur beim Versand von Nachrichten über den Outbound-Bereich in Ihrem Workspace. Wenn Sie eine Conversation im Inbox erstellen, verwenden Sie „Teammate sending a direct message“ für einzelne Nachrichten oder „Teammate sending to many customers“ für Massen-Nachrichten in Ihren Workflow-Zielgruppenregeln.

Wenn Ihr Workflow bei E-Mails, die in Tickets umgewandelt wurden, nicht ausgelöst wird, prüfen Sie, ob „Email“ als Kanal in den Workflow-Auslöser-Einstellungen ausgewählt ist (da dies der ursprüngliche Kanal ist, auf dem die Conversation gestartet wurde).

Tickets, die aus Anrufen umgewandelt wurden, behalten den Kanal „Phone call“ aus der ursprünglichen Conversation. Das bedeutet, kanalabhängige Workflow-Auslöser – wie Teammate changes conversation state – werden für diese Tickets nicht ausgelöst, da der Auslöser den Kanal zum Zeitpunkt der Erstellung bewertet, nicht den Ticket-Typ.

Diese Einschränkung gilt speziell für kanalabhängige Auslöser wie Teammate changes conversation state. Wenn Sie diesen Auslöser verwenden, um eine Kundenzufriedenheitsumfrage (CSAT) für telefonisch entstandene Tickets zu senden, wird er für diese Tickets nicht ausgelöst.

Als Workaround verwenden Sie stattdessen einen Ticket-Auslöser-Workflow (z. B. Teammate changes the state of a ticket) und konfigurieren ihn so, dass er den relevanten Ticket-Typ anspricht. Dieser Auslöser bewertet Ticket-Statusänderungen direkt, unabhängig vom ursprünglichen Kanal.

Alternativ verwenden Sie den Auslöser When a phone call ends, um Nachbearbeitungsaktionen für Anrufe und telefonisch entstandene Tickets zu automatisieren. Im Gegensatz zu kanalabhängigen Auslösern wird er basierend darauf ausgelöst, wie der Anruf beendet wurde – unabhängig davon, ob der Anruf zu einer Conversation oder einem Ticket führte. Siehe Automate actions when a phone call ends für Einrichtungsschritte und Beispiele.

Der Selektor Show workflow until ist nur für Standard-Auto-Message-Workflows When customer visits a page verfügbar, die keinen wiederkehrenden Zeitplan oder ereignisbasierten Auslöser haben.

Wenn Ihr Workflow einen wiederkehrenden Zeitplan hat (z. B. wöchentlich oder kalenderbasiert), ist die Option absichtlich ausgeblendet. Wiederkehrende geplante Nachrichten werden immer einmal pro Versandzyklus angezeigt, daher ist der Show workflow until-Auswahl deaktiviert.

Dies sind zwei verschiedene Auslöser, die zu unterschiedlichen Zeitpunkten im Anrufverlauf ausgeführt werden:

Nein, es wird nicht ausgelöst, wenn nur Ihr Teammitglied mitten im Anruf auflegt. Der Auslöser wird einmal am tatsächlichen Ende des Anrufs ausgelöst – nachdem der Kunde und alle externen Teilnehmer getrennt sind. Wenn ein Teammitglied trennt, der Kunde aber noch in der Leitung ist, läuft der Anruf weiter und der Auslöser wird nicht ausgeführt.

Nein, ein Rückruf, der vor dem Ende des eingehenden Anrufs gestartet wurde, verhindert, dass dieser Anruf als verpasster Anruf behandelt wird, selbst wenn der eingehende Anruf später als verlassen endet. Die Weiterleitung zu verpassten Anrufen erfolgt nur, wenn ein Anruf endet, ohne dass ein Teammitglied zugeordnet ist. Wenn ein Teammitglied den Kunden während des aktiven eingehenden Anrufs zurückruft, gilt die Conversation bereits als zugeordnet – daher wird sie beim Ende des eingehenden Anrufs nicht zu verpassten Anrufen verschoben.

Dies ist erwartetes Verhalten, kein Bug. Nur Anrufe, die enden, ohne dass jemand den Kunden betreut, gelten als wirklich verpasst. Wenn der Rückruf stattdessen nach dem Ende des eingehenden Anrufs gestartet wird und dieser zu verpassten Anrufen weitergeleitet wurde, gibt es keinen Konflikt und die Conversation bleibt korrekt zugeordnet.

Kundenorientierte Aktionen – wie das Senden einer Nachricht, das Sammeln von Daten über Antwort-Buttons oder das Anzeigen einer erwarteten Antwortzeit – sind in Workflows mit Live-Call-Auslösern nicht verfügbar. Während eines laufenden Anrufs telefoniert der Kunde und liest keine Chat-Nachrichten, daher sind diese Schritte absichtlich deaktiviert.

Live-Call-Auslöser unterstützen nur Hintergrundaktionen, die still ausgeführt werden, ohne den Anrufer zu unterbrechen: Conversation taggen, neu zuweisen, snoozen, Regeln anwenden und interne Notizen hinzufügen. Der Builder zeigt ein Banner mit dem Hinweis „Phone Call workflows support a reduced set of actions“ an.

Ja, „When a phone call ends“ gilt für eingehende und ausgehende Anrufe – der Auslöser wird unabhängig von der Anrufrichtung ausgelöst. Verwenden Sie beim Verzweigen nach dem Anrufende das richtige Attribut für die Richtung:

Siehe Automate actions when a phone call ends für die vollständige Liste der Zustände und Beispiel-Workflows.

Das ist erwartet. Der Auslöser „When a phone call ends“ gilt automatisch für Gespräche und Tickets. Wenn ein Anruf an ein Ticket angehängt ist, wird der Auslöser auch für dieses Ticket ausgelöst – eine Einschränkung nur auf Gespräche oder nur auf Tickets ist nicht möglich.

Wenn Sie unterschiedliche Nach-Anruf-Logik für Tickets und Gespräche benötigen, fügen Sie in Ihrem Workflow einen Condition-Schritt hinzu, um nach Gesprächs- oder Tickettyp zu verzweigen.

Nein, Sie können einen Anruf nicht in ein Ticket umwandeln, solange er noch läuft. Die Option zur Umwandlung in ein Ticket wird erst im Gesprächskopf nach Beendigung des Anrufs verfügbar.

Um Aktionen bei Tickets zu automatisieren, die aus Anrufen erstellt wurden, verwenden Sie einen Ticket-Trigger-Workflow – zum Beispiel A ticket is created oder Teammate changes the state of a ticket. Diese werden ausgelöst, sobald ein Teammitglied den beendeten Anruf manuell in ein Ticket umwandelt. Siehe Automate actions during live phone calls für weitere Informationen zur Zusammenarbeit von Ticket-Triggern mit Anrufen.

Wenn Ihr Workflow nicht wie erwartet angezeigt wird, kann es sein, dass Ihr Sitzungscookie mit einer älteren Version verknüpft ist. Öffnen Sie den Workflow testweise in einem Inkognito- oder privaten Browserfenster, um die aktuellste Version ohne zwischengespeicherte Daten zu sehen. Wenn das Problem weiterhin besteht, löschen Sie Ihre Browser-Cookies und aktualisieren Sie die Seite. Außerdem können Filter und Bedingungen in Workflows manchmal falsch registriert werden oder unerwartet reagieren. Um dies zu beheben, fügen Sie die betroffenen Filter erneut hinzu, speichern Sie den Workflow und setzen Sie ihn wieder live, um die korrekte Funktion sicherzustellen.

Sobald ein Workflow in einem Gespräch gestartet wurde, läuft er mit der Version weiter, die zum Zeitpunkt des Auslösens live war. Das erneute Veröffentlichen oder Aktualisieren des Workflows beeinflusst bereits laufende Gespräche nicht – diese bleiben in der Version, mit der sie gestartet wurden. Neue Gespräche, die nach der Veröffentlichung ausgelöst werden, verwenden die neueste Version.

Nein. Workflows können für spezifische laufende Gespräche nicht zurückgesetzt werden. Gespräche bleiben an die Version gebunden, mit der sie gestartet wurden. Wenn alle neuen Gespräche eine aktualisierte Version verwenden sollen, veröffentlichen Sie Ihre Änderungen – nur neue Gespräche übernehmen diese. Alternativ duplizieren Sie den Workflow und setzen die Kopie live. So entsteht ein neuer Workflow mit eigenem Versionsverlauf, und neue Gespräche starten mit dieser Version.

Änderungen an einem Workflow – wie hinzugefügte Bedingungen, aktualisierte Nachrichten oder neue Schritte – gelten nur für neue Gespräche. Bereits laufende Gespräche verwenden weiterhin die Version, die beim Start aktiv war. Das Löschen und Neuerstellen des Workflows beeinflusst diese laufenden Gespräche ebenfalls nicht. Um Ihre Änderungen zu überprüfen, starten Sie nach der Veröffentlichung ein neues Gespräch.

Wenn Ihr Workflow nach dem Klick eines Kunden auf eine bestimmte Schaltfläche stoppt, liegt das meist daran, dass der Workflow einen Schritt enthält, der „Collect customer reply“ konfiguriert hat. Der Workflow pausiert, bis der Kunde eine Eingabe gemäß diesem Schritt liefert. Um den Workflow ohne Unterbrechung fortzusetzen, überprüfen Sie Ihre Workflow-Konfiguration und entfernen Sie gegebenenfalls den Schritt „Collect customer reply“.

Dies passiert meist, weil mehrere Workflows mit Zuweisungsaktionen gleichzeitig ausgelöst werden. Der Workflow mit der höchsten Priorität bestimmt die endgültige Zuweisung und kann andere überschreiben. Zur Lösung:

Ein häufiges Problem entsteht, wenn Customer Satisfaction Score (CSAT)-Umfragen unbeabsichtigt mehrfach gesendet werden, besonders wenn ein Teammitglied ein Gespräch wiederholt schließt. Dies kann Kunden frustrieren, da sie mehrfach dieselbe CSAT-Umfrage für dieselbe Interaktion erhalten. Hier sind die Schritte, damit eine CSAT-Umfrage nur einmal gesendet wird, selbst wenn das Gespräch mehrfach geschlossen wird.

Die Lösung: Sicherstellen, dass CSAT nur einmal pro Gesprächsschließung gesendet wird

Um sicherzustellen, dass eine CSAT-Umfrage nur einmal pro Gespräch gesendet wird, wenn ein Teammitglied es schließt, müssen Sie eine spezifische Audience-Regel in Ihrer Workflow-Bedingung hinzufügen. Der Screenshot unten zeigt die Regel „Conversation rating requested is false“ in den Workflow-Audience-Einstellungen konfiguriert:

Fügen Sie die Audience-Regel „Conversation rating requested is false“ zu Ihrer Workflow-Bedingung hinzu.

Diese Regel stellt sicher, dass für das jeweilige Gespräch noch keine CSAT-Anfrage an den Kunden gesendet wurde. Diese wichtige Bedingung verhindert, dass bei mehrfacher Schließung oder Aktualisierung des Gesprächs mehrere Umfrageanfragen an den Kunden gesendet werden.

Um Workflow-Konflikte zu vermeiden, verwenden Sie eindeutige Audience-Einstellungen für Workflows und priorisieren Sie diese angemessen. Stellen Sie sicher, dass Logikverknüpfungen („AND“ vs. „OR“) korrekt konfiguriert sind. Zudem erhalten Sie Workflow-Zuverlässigkeit durch bewährte Methoden wie regelmäßige Prüfungen auf inaktive Trigger und Konflikte. Verwenden Sie klare Namenskonventionen zur Unterscheidung von Workflows und testen Sie neue Setups in verschiedenen Kundenszenarien vor dem Einsatz.

Workflows sind so konzipiert, dass sie stoppen, wenn ein Teammitglied sie unterbricht. Dies gilt auch für wiederverwendbare Workflows, selbst wenn die Änderungen aus dem inbox ausgelöst werden. Prüfen Sie die Gesprächsereignisse, ob Updates die Unterbrechung verursacht haben könnten.

Ein Gespräch wird dem Standard-Zuständigen zugewiesen, wenn keine Workflows auf das Gespräch passen. Aktualisieren Sie den Standard-Zuständigen oder überprüfen Sie die Workflow-Audience-Regeln, um eine korrekte Zuordnung sicherzustellen.

Wenn Fin über Simple Deploy (Fins automatische Deployment-Konfiguration) aktiviert ist, hat es Vorrang vor benutzerdefinierten Zuweisungs-Workflows für dieselbe Audience. Dies gilt für Fin for Service und Fin for Ecommerce – wenn Simple Deploy for Ecommerce aktiv ist, hat es Vorrang vor benutzerdefinierten Fin for Ecommerce-Workflows, benutzerdefinierten Fin for Service-Workflows und Fin for Service Simple Deploy. Automatisierte Workflows werden nicht ausgelöst, und das Workflow-Fehlerbehebungstool bewertet oder zeigt diese Workflows nicht an. Dadurch werden benutzerdefinierte Workflow-Schritte wie Zuweisungsaktionen (z. B. Zuweisung zu einem bestimmten inbox) nicht ausgeführt. Folgen Sie den untenstehenden Schritten, um Konflikte zwischen Fin und Ihren Workflow-Automatisierungen zu identifizieren und zu lösen.

Ein geschlossenes Gespräch kann durch einen „Customer sends their first message“ (conversation_started) Routing-Workflow wieder geöffnet und neu zugewiesen werden, auch wenn in der Timeline keine neue Kundenantwort angezeigt wird. Dies passiert, wenn es eine zeitliche Lücke zwischen dem Eintreffen der Nachricht und der Auswertung durch den Workflow gibt.

Wenn eine neue Nachricht eingeht, zeigt Intercom sie sofort einem Teammitglied an und fügt einen Hintergrundjob in die Warteschlange ein, der bestimmt, welcher Workflow sie bearbeiten soll. Dieser Job wird normalerweise innerhalb von ein bis zwei Sekunden abgeschlossen. Wenn die gemeinsame Verarbeitungswarteschlange ungewöhnlich beschäftigt ist, kann sich der Job um mehrere Minuten verzögern. Bis er schließlich ausgeführt wird, hat ein Teammitglied möglicherweise bereits geantwortet und das Gespräch geschlossen. Der Workflow hat keine Möglichkeit zu wissen, dass das Gespräch bereits bearbeitet wurde, daher fährt er fort, als wäre das Gespräch brandneu: Die Aktion Assign öffnet das geschlossene Gespräch wieder und weist es neu zu, obwohl zu diesem Zeitpunkt keine neue Kundenmeldung in der Timeline sichtbar ist.

Wenn Sie dies wiederholt oder bei mehreren betroffenen Gesprächen beobachten, wenden Sie sich mit den konkreten Gesprächsbeispielen (einschließlich Zeitstempel für das Schließen und Wiederöffnen) an den Intercom-Support, damit die Backend-Ausführungsprotokolle überprüft werden können.

Wenn ein Workflow durch das Schließen eines Gesprächs ausgelöst wird (zum Beispiel ein CSAT- oder Bewertungsworkflow, der nach dem Schließen läuft), hält seine Assign-Aktion das Gespräch jetzt geschlossen, anstatt es wieder zu öffnen. Dies gilt speziell für Workflows, die durch ein Gesprächs-geschlossen-Ereignis ausgelöst werden – jede Kundenantwort, Bewertungseinreichung oder andere für den Nutzer sichtbare Aktivität, die den Workflow auslöst, öffnet das Gespräch nicht mehr automatisch wieder; nur die Zuweisung erfolgt, und das Gespräch bleibt geschlossen.

Wenn Sie das Gespräch nach der Zuweisung wieder öffnen müssen (zum Beispiel damit ein Teammitglied es als aktives Gespräch sieht), fügen Sie nach dem Zuweisungsschritt einen Snooze-Schritt hinzu. Das Snoozen und anschließende Aufwecken bringt das Gespräch aus dem geschlossenen Zustand heraus – eine Minute ist die kürzeste verfügbare Snooze-Dauer, sodass ein einminütiger Snooze-Schritt das Gespräch fast sofort nach der Zuweisung wieder öffnet.

Wenn ein Fin AI Workflow nach einer Bearbeitung keine Bot-Antworten mehr auslöst, prüfen Sie, ob der Workflow-Pfad einen "Let Fin answer"-Schritt enthält. Fügen Sie diesen Schritt erneut hinzu und veröffentlichen Sie den Workflow, um die Funktionalität wiederherzustellen.

Wenn Ihr Workflow nach WhatsApp-Nummer verzweigt, kann er fehlschlagen, wenn nur eine WhatsApp Business number aktiv ist. Vereinfachen Sie Ihre Konfiguration, um diese einzelne Nummer zu verwenden. Passen Sie Ihre Verzweigungslogik später an, wenn weitere Nummern hinzugefügt werden.

Wenn bestimmte Nachrichten fehlschlagen, kann dies an Meta platform errors liegen, die den Endnutzer betreffen und nicht Intercom. Prüfen Sie die Fehlermeldungen in Ihrem Gespräch oder im Meta-Dashboard zur Bestätigung.

Wenn Kunden nicht auf Ihre WhatsApp-Vorlagen reagieren, überprüfen Sie sowohl die Einrichtung als auch die Nachrichtenqualität.

Vorlageneinrichtung:

Fehlerprotokolle:

Wenn Profile Gespräche vor Workflows abgleichen, wird der Workflow möglicherweise nicht ausgelöst. Passen Sie Profile gegebenenfalls an, um WhatsApp-Nachrichten auszuschließen und sicherzustellen, dass Workflows korrekt priorisiert werden.

Nein, es ist nicht möglich, eine Procedure von einem Workflow oder einem wiederverwendbaren Workflow auszulösen. Sie können jedoch innerhalb der Anweisungen einer Procedure an einen Workflow übergeben.

Nein. In Workflows wählen Sie aus einer vordefinierten Liste von Triggern – wie Customer sends their first message, Ticket is created oder New comment. Es gibt keine Möglichkeit, eine natürliche Sprachbeschreibung zu schreiben, wann die Automatisierung ausgeführt werden soll.

Wenn Sie KI-gesteuerte Trigger-Logik benötigen – bei der Fin entscheidet, wann eine Automatisierung basierend auf der Beschreibung der Kundenabsicht gestartet wird – verwenden Sie stattdessen eine Fin Procedure. Procedures enthalten in ihren When to trigger-Einstellungen eine Option Based on what the customer says, bei der Sie die Situationen beschreiben, in denen Fin die Procedure ausführen soll.

Die Felder first_name und last_name werden automatisch aus dem Feld name generiert und nicht separat gespeichert. Deshalb können sie in Workflow-Verzweigungen nicht zum Filtern oder Abgleichen verwendet werden. Um nach name zu filtern, verwenden Sie das Namensattribut direkt. Wenn Sie nach Vor- oder Nachname einzeln filtern müssen, können Sie diese als benutzerdefinierte Datenattribute erstellen und die Werte über Ihre Integration übergeben.

Wenn Sie Fix issues in order to save. auf dem Button Set changes live sehen, aber keine Fehlersymbole an Ihren Schritten erscheinen, überprüfen Sie den Abschnitt Scheduling des Workflows.

Ein Workflow, der ursprünglich geplant war, an einem zukünftigen Datum live zu gehen, behält dieses geplante Datum auch nach dem Live-Schalten bei. Sobald dieses Datum vergangen ist, ist es nicht mehr gültig, und das Speichern wird blockiert, bis Sie es aktualisieren. Ein Stopp-Datum, das in der Vergangenheit liegt, bewirkt dasselbe.

Um dies zu beheben und Ihre Änderungen zu speichern:

1. Öffnen Sie den Abschnitt Scheduling des Workflows.

2. Wählen Sie unter Start sending Immediately aus.

3. Wählen Sie unter Stop sending, falls das Datum in der Vergangenheit liegt, Never oder ein Custom-Datum in der Zukunft aus.

4. Klicken Sie auf Set changes live.
​

Ihr Workflow bleibt durchgehend live, Ihre Änderungen werden normal gespeichert, und er läuft weiterhin für sein bestehendes Publikum und seine Regeln. Wenn Sie ein zukünftiges Stopp-Datum wählen, pausiert der Workflow sich selbst, sobald dieses Datum erreicht ist.

Wenn Sie Finish creating your workflow before setting it live sehen, aber keine Fehlersymbole an Ihren Schritten erscheinen, überprüfen Sie den Abschnitt Scheduling des Workflows.

Ein Workflow mit einem Stopp-Datum pausiert sich selbst, sobald dieses Datum erreicht ist. Das abgelaufene Datum bleibt gesetzt und verhindert, dass der Workflow wieder live geschaltet wird, bis Sie es ändern.

Um es wieder live zu schalten:

1. Öffnen Sie den Abschnitt Scheduling des Workflows.

2. Wählen Sie unter Stop sending Never oder ein zukünftiges Custom date aus.

3. Klicken Sie auf Set changes live.