So verwenden Sie den Wert eines benutzerdefinierten Felds für Zendesk-Triggerbedingungen: Vollständige Anleitung

Zendesk-Trigger sind das Arbeitstier der Support-Automatisierung. Sie übernehmen Routing, Tagging, Benachrichtigungen und Priorisierung, ohne dass jemand einen Finger rühren muss. Aber während die meisten Administratoren grundlegende Trigger schnell beherrschen (wie "Wenn Status Neu ist, weise Level 1 zu"), nutzen viele nie die wahre Kraft, die in ihren benutzerdefinierten Feldern steckt.

Benutzerdefinierte Feld-Triggerbedingungen ermöglichen es Ihnen, eine Automatisierung zu erstellen, die Ihrer tatsächlichen Geschäftslogik entspricht. Anstatt sich auf generische Ticket-Eigenschaften zu verlassen, können Sie basierend auf Produkttyp, Kundenstufe oder Eskalation basierend auf von Ihnen erstellten Kontrollkästchen-Flags routen. Der Haken? Nicht alle Feldtypen funktionieren in Triggern auf die gleiche Weise, und einige haben überraschende Einschränkungen.

Diese Anleitung führt Sie durch alles, was Sie über die Verwendung benutzerdefinierter Feldwerte in Zendesk-Triggerbedingungen wissen müssen, von der grundlegenden Einrichtung bis hin zu fortgeschrittenen Techniken mit benutzerdefinierten Objekten. Und wenn Sie an die Grenzen der regelbasierten Automatisierung stoßen, werden wir darauf eingehen, wie eesel AI komplexere Szenarien bewältigen kann, für die Trigger einfach nicht ausgelegt waren.

Was sind benutzerdefinierte Feld-Triggerbedingungen in Zendesk?

Benutzerdefinierte Feld-Triggerbedingungen ermöglichen es Ihnen, die Werte aus Ihren benutzerdefinierten Ticketfeldern als Kriterien für automatisierte Aktionen zu verwenden. Betrachten Sie sie als eine Erweiterung der Standard-Triggerbedingungen von Zendesk (wie "Status ist Neu" oder "Priorität ist Hoch"), die Sie selbst definieren.

Hier ist, wie sie in das Gesamtbild passen. Standard-Trigger können nur auf die integrierten Ticket-Eigenschaften von Zendesk reagieren: Status, Priorität, Gruppe, Bearbeiter, Tags usw. Das ist nützlich, aber die meisten Support-Teams haben eine Geschäftslogik, die sich nicht sauber auf diese Standardwerte abbilden lässt. Möglicherweise müssen Sie Tickets basierend auf Produktlinie, Kundensegment oder Problemkategorie unterschiedlich routen. Mit benutzerdefinierten Feldern können Sie diese Daten erfassen, und mit benutzerdefinierten Feld-Triggerbedingungen können Sie die Automatisierung darauf basieren.

Der Geschäftswert ist unkompliziert. Anstatt dass Agenten Tickets manuell triagieren oder Tags anwenden, übernehmen Ihre Trigger dies automatisch:

• Leiten Sie Enterprise-Produkt-Tickets an Ihr Senior-Support-Team weiter
• Kennzeichnen Sie VIP-Kunden für die vorrangige Bearbeitung
• Automatisieren Sie die Kategorisierung von Tickets für Berichte und Analysen
• Eskalieren Sie Probleme basierend auf benutzerdefinierten Schweregrad-Flags

Für Teams, die dem entwachsen sind, was regelbasierte Trigger leisten können, gibt es eine weitere Option. Wir haben eesel AI entwickelt, um die Szenarien zu bewältigen, in denen Trigger zu kurz kommen: Kontext verstehen, Absichten interpretieren und Urteile fällen, die mehr als nur einfache Feldübereinstimmungen erfordern. Aber für die unkomplizierte Automatisierung basierend auf bekannten Werten sind benutzerdefinierte Feld-Trigger das richtige Werkzeug.

Voraussetzungen und was Sie benötigen

Bevor Sie mit dem Erstellen von Triggern mit benutzerdefinierten Feldbedingungen beginnen, stellen Sie sicher, dass Sie Folgendes haben:

• Ein Zendesk Support-Konto im Team-Plan oder höher (benutzerdefinierte Felder sind im Legacy Essential-Plan nicht verfügbar)
• Administratorzugriff zum Erstellen und Bearbeiten von Triggern
• Benutzerdefinierte Ticketfelder, die bereits erstellt und Ihren Ticketformularen hinzugefügt wurden
• Grundlegende Vertrautheit mit der Funktionsweise von Triggern (Bedingungen und Aktionen)

Einige in dieser Anleitung erwähnte Funktionen erfordern höherwertige Pläne. Benutzerdefinierte Objekte und Nachschlagebeziehungsfelder sind Enterprise-Funktionen. Wenn Sie den Team- oder Growth-Plan verwenden, können Sie weiterhin Standard-Feldtypen (Dropdown, Text, Kontrollkästchen, Datum) in Triggern verwenden.

Schritt-für-Schritt: Einrichten eines Triggers mit benutzerdefinierten Feldbedingungen

Lassen Sie uns gemeinsam einen Trigger erstellen, der eine benutzerdefinierte Feldbedingung verwendet. Das Beispiel, das wir verwenden werden: automatisches Zuweisen von Tickets zu Ihrer Enterprise-Supportgruppe, wenn das benutzerdefinierte Feld "Produkttyp" auf "Enterprise-Software" gesetzt ist.

Schritt 1: Zugriff auf die Trigger-Seite im Admin Center

Navigieren Sie zum Admin Center, klicken Sie dann in der Seitenleiste auf Objekte und Regeln, gefolgt von Geschäftsregeln und Trigger.

Sie sehen eine Liste aller vorhandenen Trigger in Ihrem Konto. Zendesk enthält mehrere Standard-Trigger (wie "Anfragesteller über empfangene Anfrage benachrichtigen"), die grundlegende Benachrichtigungen verarbeiten.

Schritt 2: Neuen Trigger erstellen oder vorhandenen bearbeiten

Klicken Sie auf die Schaltfläche Trigger hinzufügen, um einen neuen zu erstellen. Geben Sie ihm einen klaren, beschreibenden Namen wie "Route: Enterprise-Produkt zum Enterprise-Support" und fügen Sie eine kurze Beschreibung hinzu, die erklärt, was er tut. Dies hilft anderen Administratoren, den Zweck des Triggers zu verstehen, ohne ihn öffnen zu müssen.

Wählen Sie eine Triggerkategorie aus, wenn Sie diese zur Organisation verwenden. Kategorien helfen Ihnen, verwandte Trigger zusammenzufassen.

Schritt 3: Triggerbedingungen mit benutzerdefinierten Feldern konfigurieren

Unter Alle der folgenden Bedingungen erfüllen (oder Eine der folgenden Bedingungen erfüllen, wenn der Trigger ausgelöst werden soll, wenn eine einzelne Bedingung übereinstimmt) erstellen Sie Ihre Bedingungsanweisung.

Klicken Sie auf Bedingung hinzufügen und wählen Sie dann die Kategorie aus, die Ihr benutzerdefiniertes Feld enthält. Suchen Sie für Standard-Ticketfelder unter Ticket und scrollen Sie, um Ihr Feld nach Namen zu finden. Das Feld wird so angezeigt, wie Sie es beim Erstellen benannt haben.

Wenn Ihr benutzerdefiniertes Feld nicht in der Liste angezeigt wird, überprüfen Sie, ob es aktiv ist und mindestens einem Ticketformular hinzugefügt wurde. Inaktive Felder werden nicht als Triggerbedingungen angezeigt.

Schritt 4: Wählen Sie den entsprechenden Operator und Wert aus

Sobald Sie Ihr benutzerdefiniertes Feld ausgewählt haben, wählen Sie den Operator aus. Die verfügbaren Operatoren hängen von Ihrem Feldtyp ab:

• Dropdown-Felder: ist, ist nicht, vorhanden, nicht vorhanden
• Mehrfachauswahlfelder: enthält, enthält nicht, vorhanden, nicht vorhanden
• Textfelder: vorhanden, nicht vorhanden (nur)
• Datumsfelder: ist, ist nicht, vor, nach, vorhanden, nicht vorhanden, liegt innerhalb des vorherigen/nächsten

Wählen Sie für unser Beispiel ist als Operator und wählen Sie dann "Enterprise-Software" aus dem Wert-Dropdown aus.

Schritt 5: Triggeraktionen hinzufügen

Definieren Sie nun, was passiert, wenn die Bedingung erfüllt ist. Klicken Sie auf Aktion hinzufügen und wählen Sie die gewünschte Aktion aus. Häufige Aktionen sind:

• Gruppe: Weisen Sie das Ticket einer bestimmten Gruppe zu
• Bearbeiter: Weisen Sie es einem bestimmten Agenten zu
• Tags hinzufügen: Wenden Sie Tags für Berichte oder Routing an
• Priorität: Legen Sie die Ticketpriorität fest
• Benachrichtigen per: Senden Sie E-Mail-Benachrichtigungen

Fügen Sie für unser Beispiel die Aktion Gruppe hinzu und wählen Sie Ihre Gruppe "Enterprise-Support" aus.

Sie können einem einzelnen Trigger mehrere Aktionen hinzufügen. Denken Sie nur daran, dass alle Aktionen ausgelöst werden, wenn die Bedingungen erfüllt sind.

Schritt 6: Speichern und testen Sie Ihren Trigger

Klicken Sie auf Speichern, um Ihren Trigger zu aktivieren. Testen Sie ihn nun, indem Sie ein Testticket erstellen und den Wert des benutzerdefinierten Felds so einstellen, dass er Ihrer Bedingung entspricht. Stellen Sie sicher, dass der Trigger ausgelöst wird und die von Ihnen konfigurierten Aktionen anwendet.

Wenn der Trigger nicht wie erwartet ausgelöst wird, überprüfen Sie, ob Sie Alle erfüllen im Vergleich zu Eine erfüllen korrekt verwenden. Alle bedeutet, dass jede Bedingung wahr sein muss. Eine bedeutet, dass nur eine Bedingung übereinstimmen muss.

Benutzerdefinierte Feldtypen und ihre verfügbaren Operatoren

Nicht alle benutzerdefinierten Felder funktionieren in Triggern auf die gleiche Weise. Das Verständnis, welche Operatoren für jeden Feldtyp verfügbar sind, hilft Ihnen, eine Automatisierung zu entwerfen, die tatsächlich funktioniert.

Dropdown-Felder

Dropdown-Felder sind der flexibelste benutzerdefinierte Feldtyp für Trigger. Sie unterstützen:

• ist / ist nicht: Exakte Übereinstimmung mit einer bestimmten Option
• vorhanden / nicht vorhanden: Ob ein Wert ausgewählt ist

Verwenden Sie diese für das Routing nach Kategorie, Produkttyp, Prioritätsstufe oder in jedem Szenario, in dem Sie eine vordefinierte Liste von Optionen haben. Dropdown-Felder sind die erste Wahl, wenn Sie zuverlässige Triggerbedingungen benötigen, da die Werte kontrolliert und konsistent sind.

Mehrfachauswahlfelder

Mit Mehrfachauswahlfeldern können Benutzer mehrere Werte auswählen. In Triggern unterstützen sie:

• enthält / enthält nicht: Prüft, ob bestimmte Werte zu den ausgewählten Optionen gehören
• vorhanden / nicht vorhanden: Ob Werte ausgewählt sind

Der Operator enthält ist besonders nützlich. Er ermöglicht es Ihnen, Trigger zu erstellen, die ausgelöst werden, wenn ein Ticket mit einer von mehreren verwandten Kategorien getaggt ist. Zum Beispiel ein Trigger, der Ihrer Engineering-Warteschlange zugewiesen wird, wenn "Fehlerbericht" oder "Funktionsanfrage" ausgewählt ist.

Text- und mehrzeilige Felder

Hier werden Trigger einschränkend. Textfelder unterstützen nur:

• vorhanden / nicht vorhanden: Ob das Feld Inhalte enthält

Sie können bestimmte Textinhalte in Triggerbedingungen nicht abgleichen. Eine Bedingung wie "Beschreibung enthält 'dringend'" ist mit benutzerdefinierten Textfeldern in Triggern nicht möglich. Wenn Sie bestimmte Werte abgleichen müssen, verwenden Sie stattdessen ein Dropdown-Feld. Die Einschränkung des Textfelds besteht, weil der Textabgleich rechenintensiv und anfällig für falsche Übereinstimmungen sein kann.

Zahlen- und Dezimalfelder

Zahlenfelder haben die gleiche Einschränkung wie Textfelder:

• nur vorhanden / nicht vorhanden

Sie können keine Operatoren wie größer als, kleiner als oder gleich mit numerischen benutzerdefinierten Feldern in Standard-Triggern verwenden. Dies überrascht viele Administratoren, die erwarten, Bedingungen wie "Bestellwert > 1000 $" zu erstellen. Für diese Art von Logik müssten Sie Tags oder Dropdowns als Workaround verwenden.

Kontrollkästchen-Felder

Kontrollkästchen sind unkompliziert:

• ist aktiviert / ist deaktiviert

Diese sind perfekt für binäre Flags wie "Eskalation erforderlich", "VIP-Kunde" oder "Benötigt Manager-Überprüfung". Die Einfachheit macht sie zu zuverlässigen Triggerbedingungen.

Datumsfelder

Datumsfelder haben den reichhaltigsten Satz von Operatoren:

• ist / ist nicht: Bestimmtes Kalenderdatum
• vorher / nachher: Relativ zu einem bestimmten Datum
• vorhanden / nicht vorhanden: Ob ein Datum festgelegt ist
• liegt innerhalb des vorherigen / liegt innerhalb des nächsten: Relative Zeitfenster

Die Operatoren "liegt innerhalb" verdienen besondere Aufmerksamkeit. Laut Zendesk's Dokumentation werden diese basierend auf 24-Stunden-Vielfachen ausgewertet. "Liegt innerhalb der nächsten 3" bedeutet innerhalb der nächsten 72 Stunden, nicht unbedingt 3 Kalendertage. Beachten Sie auch, dass benutzerdefinierte Datumsfelder immer Kalendertage verwenden; Geschäftszeiten und Zeitpläne werden nicht berücksichtigt.

Nachschlagebeziehungsfelder (Enterprise)

Für Enterprise-Pläne verbinden Nachschlagebeziehungsfelder Tickets mit benutzerdefinierten Objekten, Benutzern oder Organisationen. Sie unterstützen:

• ist / ist nicht: Übereinstimmung mit einem bestimmten verknüpften Datensatz
• vorhanden / nicht vorhanden: Ob eine Beziehung besteht

In Ticket-Triggern können Nachschlagebeziehungsfelder nur in Benachrichtigungsaktionen verwendet werden. Sie können sie nicht verwenden, um Feldwerte festzulegen oder Tickets direkt zuzuweisen. Für die vollständige Automatisierung basierend auf benutzerdefinierten Objekten würden Sie Objekt-Trigger verwenden (die im Abschnitt "Erweitert" unten behandelt werden).

Praktische Beispiele und Anwendungsfälle

Sehen wir uns einige reale Szenarien an, in denen benutzerdefinierte Feld-Triggerbedingungen einen Mehrwert bieten.

Beispiel 1: Tickets nach Produkttyp routen

Das Szenario: Sie unterstützen mehrere Produktlinien mit unterschiedlichen Fachkenntnissen. Enterprise-Software benötigt Ihr Senior-Team; Konsumgüter können an den allgemeinen Support gehen.

Der Trigger:

• Bedingung: Produktdropdown ist "Enterprise-Software"
• Aktion: Der Enterprise-Supportgruppe zuweisen, Tag "enterprise" hinzufügen

Der Geschäftswert: Tickets erreichen sofort die richtige Expertise, wodurch Übertragungen reduziert und die Lösungszeit verbessert wird.

Beispiel 2: VIP-Kunden priorisieren

Das Szenario: Sie haben einen gestaffelten Kundenstamm und möchten, dass Platin-Kunden eine vorrangige Bearbeitung erhalten.

Der Trigger:

• Bedingung: Kundenstufe ist "Platin"
• Aktion: Priorität auf Hoch setzen, Account Manager per E-Mail benachrichtigen

Der Geschäftswert: Hochwertige Kunden erhalten schnellere Reaktionszeiten ohne manuelle Triage.

Beispiel 3: Automatisches Tagging für die Berichterstellung

Das Szenario: Sie benötigen eine konsistente Kategorisierung für Analysen, können sich aber nicht darauf verlassen, dass Agenten jedes Ticket manuell taggen.

Der Trigger:

• Bedingung: Problemkategorie enthält "Fehlerbericht"
• Aktion: Tags "Fehlerbericht" und "Untersuchung erforderlich" hinzufügen, der Engineering-Warteschlange zuweisen

Der Geschäftswert: Saubere Berichtsdaten und automatisches Routing zum richtigen Team.

Beispiel 4: Eskalation basierend auf Kontrollkästchen

Das Szenario: Agenten benötigen eine einfache Möglichkeit, Tickets zur Eskalation zu kennzeichnen, ohne komplexe Workflows.

Der Trigger:

• Bedingung: Kontrollkästchen "Eskalation erforderlich" ist aktiviert
• Aktion: Priorität auf Dringend setzen, Follower (Manager) hinzufügen, Tag "eskaliert" hinzufügen

Der Geschäftswert: One-Click-Eskalation, die das vollständige Antwortprotokoll auslöst.

Beispiel 5: SLA-Management mit Datumsfeldern

Das Szenario: Sie möchten proaktive Benachrichtigungen, bevor SLA-Fristen verpasst werden.

Der Trigger:

• Bedingung: Datum "SLA-Frist" liegt innerhalb des nächsten 1 Tag
• Aktion: Bearbeiter per E-Mail benachrichtigen, Tag "SLA nähert sich" hinzufügen

Der Geschäftswert: Verhindert SLA-Verstöße, indem gefährdete Tickets vor Ablauf angezeigt werden.

Häufige Probleme und Fehlerbehebung

Selbst einfache Trigger können nicht ausgelöst werden. Hier sind die häufigsten Probleme mit benutzerdefinierten Feldbedingungen und wie Sie sie beheben können.

Trigger wird überhaupt nicht ausgelöst

Überprüfen Sie Ihre ALLE- versus EINE-Logik. Wenn Sie mehrere Bedingungen unter "Alle der folgenden Bedingungen erfüllen" haben, muss jede einzelne wahr sein, damit der Trigger ausgelöst wird. Ein häufiger Fehler ist das Mischen von Bedingungen, die nicht alle gleichzeitig wahr sein können.

Benutzerdefiniertes Feld wird im Bedingungs-Dropdown nicht angezeigt

Das Feld muss aktiv sein und mindestens einem Ticketformular hinzugefügt werden. Gehen Sie zu Admin Center > Objekte und Regeln > Tickets > Ticketfelder und überprüfen Sie den Feldstatus. Überprüfen Sie dann Ihre Ticketformulare, um zu bestätigen, dass das Feld enthalten ist.

Die Datumsfeld-Zeitangabe scheint falsch zu sein

Denken Sie daran, dass "liegt innerhalb des vorherigen/nächsten" 24-Stunden-Fenster und keine Kalendertage verwendet. "Liegt innerhalb des nächsten 1" bedeutet die nächsten 24 Stunden, nicht "heute". Beachten Sie auch, dass Datumsfelder zum Zeitpunkt der Ausführung des Triggers und nicht kontinuierlich ausgewertet werden.

Textfeld kann bestimmte Inhalte nicht abgleichen

Dies ist kein Fehler; es ist eine Einschränkung. Standard-Trigger können bestimmte Textinhalte in benutzerdefinierten Feldern nicht abgleichen. Wenn Sie diese Funktionalität benötigen, sollten Sie stattdessen ein Dropdown-Feld verwenden oder die erweiterten KI-Funktionen von Zendesk in Betracht ziehen, die Ticketinhalte analysieren können.

Einschränkungen bei Nachschlagebeziehungen

In Ticket-Triggern können Nachschlagebeziehungsfelder nur in Benachrichtigungsaktionen verwendet werden (wie "Benachrichtigen per: Benutzer-E-Mail"). Sie können sie nicht verwenden, um Tickets zuzuweisen oder Feldwerte festzulegen. Für die Automatisierung basierend auf benutzerdefinierten Objektdaten benötigen Sie Objekt-Trigger.

Leistungsüberlegungen

Zu viele komplexe Trigger können die Ticketverarbeitung verlangsamen. Wenn Sie Dutzende von Triggern haben, die bei jeder Ticketaktualisierung ausgewertet werden, kann es zu Verzögerungen kommen. Zendesk wertet Trigger der Reihe nach aus, platzieren Sie daher Ihre am häufigsten ausgelösten Trigger frühzeitig in der Liste.

Erweiterte Techniken mit benutzerdefinierten Objekten (Enterprise)

Für Enterprise-Kunden erschließen benutzerdefinierte Objekte eine ausgefeiltere Automatisierung. Hier ist, was möglich ist, wenn Sie benutzerdefinierte Objekte mit Triggern kombinieren.

Verwenden von Nachschlagebeziehungen in Ticket-Triggern

Wenn Sie ein Nachschlagebeziehungsfeld erstellen, das Tickets mit benutzerdefinierten Objekten verbindet, können Sie diese Beziehung in Triggerbedingungen verwenden. Wenn Sie beispielsweise ein benutzerdefiniertes Objekt "Servicevertrag" haben, das mit Tickets verknüpft ist, können Sie Trigger erstellen, die basierend auf Vertragseigenschaften ausgelöst werden.

Die Bedingung würde wie folgt aussehen: Servicevertrag ist [bestimmter Vertragsdatensatz].

Denken Sie an die Einschränkung: In Ticket-Triggern können Nachschlagebeziehungen nur in Benachrichtigungsaktionen verwendet werden, nicht für die Zuweisung oder Feldaktualisierungen.

Objekt-Trigger

Objekt-Trigger sind ein separater Triggertyp, der ausgelöst wird, wenn benutzerdefinierte Objektdatensätze erstellt oder aktualisiert werden, nicht wenn sich Tickets ändern. Dies eröffnet neue Automatisierungsmöglichkeiten:

• Senden Sie Benachrichtigungen, wenn sich ein Servicevertrag der Verlängerung nähert
• Aktualisieren Sie zugehörige Tickets, wenn sich Produktinformationen ändern
• Benachrichtigen Sie Account Manager, wenn die Kunden-Health-Scores sinken

Objekt-Trigger verwenden die gleiche Bedingungs-/Aktionsstruktur wie Ticket-Trigger, arbeiten aber stattdessen mit benutzerdefinierten Objektdatensätzen.

Platzhalter für benutzerdefinierte Objekte

Wenn Sie benutzerdefinierte Objektdaten in Triggerbenachrichtigungen einfügen müssen, verwenden Sie Platzhalter. Die Syntax unterscheidet sich von Standard-Ticketplatzhaltern:

Für Ticket-Level-Lookups: {{ticket.ticket_fields_123456789.custom_fields.field_name}}

Für Objekt-Trigger: {{custom_objects.object_type.custom_fields.field_name}}

Sie können auch Datumsangaben formatieren: {{custom_objects.contract.custom_fields.renewal_date | date: '%Y-%m-%d'}}

Best Practices für das Trigger-Management

Ein paar Gewohnheiten machen den Unterschied zwischen Triggern, die helfen, und Triggern, die Chaos verursachen.

Verwenden Sie konsistente Namenskonventionen. Fügen Sie den Zweck des Triggers in den Namen ein. "Route: Enterprise zu Enterprise-Support" ist nützlicher als "Enterprise-Trigger".

Dokumentieren Sie Ihre Trigger. Das Beschreibungsfeld ist durchsuchbar und hilft anderen Administratoren zu verstehen, warum ein Trigger existiert. Notieren Sie die Geschäftslogik, nicht nur das, was der Trigger tut.

Testen Sie zuerst in der Sandbox. Wichtige Triggeränderungen sollten in einer Sandbox-Umgebung getestet werden, bevor sie in die Produktion gehen. Ein falsch konfigurierter Trigger kann Hunderte von Benachrichtigungen senden oder Tickets falsch zuweisen.

Gruppieren Sie verwandte Trigger. Verwenden Sie Triggerkategorien, um verwandte Automatisierungen zu organisieren. Dies erleichtert das Auffinden und Verwalten von Triggern, wenn Ihre Instanz wächst.

Führen Sie regelmäßig Audits durch. Deaktivieren Sie Trigger, die keinen Zweck mehr erfüllen. Alte Trigger können mit neuen in Konflikt geraten oder unnötig ausgelöst werden.

Wissen Sie, wann Sie über Trigger hinausgehen müssen. Regelbasierte Automatisierung hat Grenzen. Wenn Sie feststellen, dass Sie zunehmend komplexe Triggerketten erstellen, um differenzierte Szenarien zu bewältigen, ist es möglicherweise an der Zeit, KI-gestützte Alternativen in Betracht zu ziehen. Wir haben eesel AI speziell für Teams entwickelt, die dem entwachsen sind, was Trigger vernünftigerweise leisten können.

Erste Schritte mit intelligenter Automatisierung

Benutzerdefinierte Feld-Trigger sind leistungsstark für die unkomplizierte Automatisierung: Wenn Feld X gleich Wert Y ist, führe Z aus. Sie haben jedoch Schwierigkeiten mit Nuancen, Kontext und allem, was Verständnis anstelle von Mustererkennung erfordert.

Hier unterscheiden sich KI-Agenten. Anstatt Regeln für jedes mögliche Szenario zu konfigurieren, trainieren Sie eine KI auf Ihrer Wissensdatenbank und lassen sie Tickets interpretieren. Sie kann Absichten verstehen, klärende Fragen stellen und Urteile fällen, für die Dutzende von Triggern erforderlich wären, um sie anzunähern.

Wir haben eesel AI entwickelt, um sich direkt in Zendesk zu integrieren und neben (oder anstelle von) herkömmlichen Triggern zu arbeiten. Sie können damit beginnen, dass die KI bestimmte Tickettypen verarbeitet, ihre Arbeit überprüft und ihren Umfang erweitert, sobald sie sich bewährt hat. Oder verwenden Sie sie als Copilot, der Antworten für Ihre Agenten entwirft, die sie überprüfen können.

Wenn Sie mehr Zeit mit der Verwaltung der Triggerkomplexität verbringen, als die Trigger Ihnen sparen, lohnt es sich möglicherweise zu prüfen, ob KI besser zu Ihrem Workflow passt. Sie können eesel AI kostenlos ausprobieren und sehen, wie es im Vergleich zu Ihrer aktuellen Automatisierungseinrichtung abschneidet.