Zendesk Automatisierung: Bedingungen zum Wiedereröffnen von Tickets: Ein vollständiger Leitfaden für 2026

Das Verwalten von Ticket-Wiedereröffnungen ist einer dieser Workflows, der einfach erscheint, bis er es nicht mehr ist. Sie lösen ein Ticket, der Kunde antwortet mit einem kurzen "Danke" und plötzlich befindet sich dieses Ticket wieder in Ihrer offenen Warteschlange und überlastet Ihre Arbeitslast. Oder schlimmer noch, ein Ticket bleibt tagelang als gelöst markiert, obwohl es eigentlich ein Follow-up benötigt hätte, und jetzt haben Sie Ihr Zeitfenster für die Hilfe verpasst.

Wenn Sie Ihre Zendesk Automatisierung für die Bedingungen zum Wiedereröffnen von Tickets richtig einrichten, bedeutet dies, Workflows zu erstellen, die diese Szenarien intelligent handhaben. Nicht jede Kundenantwort erfordert eine Wiedereröffnung. Nicht jedes gelöste Ticket sollte für immer gelöst bleiben. Der Trick besteht darin, zu wissen, welches Werkzeug wann zu verwenden ist.

Dieser Leitfaden führt Sie genau durch die Konfiguration von Automatisierungen und Auslösern (Triggers) für Wiedereröffnungsszenarien. Egal, ob Sie versuchen, Agenten über wiedereröffnete Tickets zu benachrichtigen, Follow-ups für später zu planen oder die gefürchtete "Danke"-Wiedereröffnungsschleife zu stoppen, Sie finden die spezifischen Bedingungen und Schritte, die Sie benötigen.

Und wenn Sie feststellen, dass Sie zunehmend komplexe Auslöserketten erstellen, um differenzierte Szenarien zu bewältigen, werden wir uns ansehen, wie wir diese Herausforderungen bei eesel AI anders angehen.

Das Verständnis der Zendesk Ticket-Wiedereröffnungsmechanismen

Bevor wir uns mit Bedingungen und Konfigurationen befassen, wollen wir klären, wie die Ticket-Wiedereröffnung in Zendesk tatsächlich funktioniert. Die Plattform folgt einem strengen Lebenszyklus, der bestimmt, was in jeder Phase geschehen kann und was nicht.

Der Standard-Ticket-Lebenszyklus sieht wie folgt aus: Neu → Offen → In Bearbeitung → Gelöst → Geschlossen (Zendesk Dokumentation)

Hier ist, was jeder Status bedeutet:

• Neu: Das Ticket wurde gerade erstellt und noch nicht zugewiesen
• Offen: Ein Agent arbeitet aktiv an dem Ticket
• In Bearbeitung: Der Agent wartet auf Informationen vom Kunden
• Gelöst: Der Agent glaubt, dass das Problem behoben ist
• Geschlossen: Das Ticket ist gesperrt und kann nicht mehr geändert werden

Die kritische Regel für die Wiedereröffnung: Tickets können nur vom Status "Gelöst" wiedereröffnet werden. Sobald ein Ticket den Status "Geschlossen" erreicht, ist es dauerhaft. Dies ist so gewollt. Geschlossene Tickets werden zu historischen Aufzeichnungen, die die Datenintegrität für Berichte und Compliance wahren.

Wenn ein Kunde auf ein gelöstes Ticket antwortet, ändert Zendesk den Status automatisch wieder in "Offen". Dies ist das häufigste Wiedereröffnungsszenario. Aber es verursacht auch die meisten Kopfschmerzen. Diese "Vielen Dank!"-E-Mail von einem zufriedenen Kunden? Sie öffnet das Ticket genauso wieder wie ein "Das hat nicht funktioniert"-Follow-up.

Das Verständnis dieses Lebenszyklus ist wichtig, da Ihre Automatisierungsbedingungen dies berücksichtigen müssen. Sie können keine Automatisierung erstellen, die ein geschlossenes Ticket wiedereröffnet (Zendesk lässt dies nicht zu). Sie können jedoch ausgefeilte Workflows erstellen, die den Übergang von "Gelöst" zu "Offen" intelligent handhaben.

Für Teams, die diese nativen Einschränkungen als restriktiv empfinden, bietet unsere Zendesk-Integration einen alternativen Ansatz, der die Absicht liest, anstatt nur Statusfelder zu überprüfen.

Auslöser (Triggers) vs. Automatisierungen: Wann Sie welche für Wiedereröffnungsszenarien verwenden sollten

Zendesk bietet Ihnen zwei Werkzeuge für die Automatisierung: Auslöser (Triggers) und Automatisierungen. Sie klingen ähnlich, funktionieren aber sehr unterschiedlich. Die Verwendung des falschen Werkzeugs für Ihren Wiedereröffnungsworkflow ist ein Rezept für Frustration.

Auslöser (Triggers): Ereignisbasiert und sofortig

Auslöser (Triggers) werden in dem Moment ausgelöst, in dem ein Ticket ihre Bedingungen erfüllt. Sie sind perfekt für Echtzeit-Reaktionen auf Statusänderungen. Erfahren Sie mehr in der Zendesk-Dokumentation zu Auslösern (Triggers).

Verwenden Sie Auslöser (Triggers), wenn:

• Sie eine sofortige Benachrichtigung wünschen, wenn ein Ticket wiedereröffnet wird
• Sie Maßnahmen ergreifen müssen, basierend darauf, wer das Ticket aktualisiert hat
• Sie auf Statusübergänge reagieren (Gelöst → Offen)

Die Kernbedingung für Wiedereröffnungs-Auslöser (Triggers):

Ticket: Statuskategorie | Geändert zu | Offen

Diese Bedingung wird nur ausgelöst, wenn sich der Status eines Tickets tatsächlich in "Offen" ändert, nicht wenn er einfach "Offen" "ist". Das ist der Unterschied, der Auslöser (Triggers) für Wiedereröffnungsszenarien funktionieren lässt.

Automatisierungen: Zeitbasiert und geplant

Automatisierungen werden nach einem Zeitplan ausgeführt (ungefähr einmal pro Stunde). Sie sind für Aktionen konzipiert, die nach Ablauf einer bestimmten Zeitspanne erfolgen sollen. Siehe Zendesks Automatisierungsleitfaden für Details.

Verwenden Sie Automatisierungen, wenn:

• Sie Tickets nachverfolgen möchten, die seit X Stunden gelöst sind
• Sie Tickets planen möchten, die zu bestimmten Zeiten wiedereröffnet werden sollen
• Sie eine zeitbasierte Eskalation benötigen (Ticket seit 24+ Stunden offen)

Häufige zeitbasierte Bedingungen:

Ticket: Stunden seit Lösung | Größer als | 24
Ticket: Stunden seit In Bearbeitung | Größer als | 48
Ticket: Stunden seit Fälligkeitsdatum | Größer als | 0

Das Entscheidungs-Framework

So wählen Sie aus:

Die wichtigste Sache, die Sie sich merken sollten: Auslöser (Triggers) reagieren auf Ereignisse, Automatisierungen reagieren auf Zeit. Die meisten Wiedereröffnungsworkflows benötigen tatsächlich beides. Sie könnten einen Auslöser (Trigger) verwenden, um den Bearbeiter sofort zu benachrichtigen, und dann eine Automatisierung, um zu eskalieren, wenn das Ticket zu lange offen bleibt.

Weitere Informationen zur zeitbasierten Automatisierung finden Sie in unserem Leitfaden zu Zendesk Automatisierungsbedingungen.

Wesentliche Bedingungen für Automatisierungen zur Wiedereröffnung von Tickets

Das Erstellen effektiver Wiedereröffnungsworkflows erfordert das Verständnis der gesamten Bandbreite der verfügbaren Bedingungen. Hier ist die vollständige Referenz für die Bedingungen, die Sie tatsächlich verwenden werden.

Statusbasierte Bedingungen

Dies sind Ihre Grundlagen für Wiedereröffnungsszenarien:

Statuskategorie | Geändert zu | Offen

• Wird ausgelöst, wenn ein Ticket in den Status "Offen" übergeht
• Verwenden Sie in Auslösern (Triggers) für sofortige Benachrichtigung
• Häufigste Bedingung zur Erkennung von Wiedereröffnungen

Status | Geändert von | Gelöst

• Wird ausgelöst, wenn ein Ticket den Status "Gelöst" verlässt
• Spezifischer als "Geändert zu Offen" (erfasst Gelöst → jeden Status)
• Nützlich, wenn Sie jede Bewegung weg von "Gelöst" verfolgen möchten

Statuskategorie | Ist | Offen

• Überprüft den aktuellen Zustand, nicht Übergänge
• Verwenden Sie in Automatisierungen für die laufende Überwachung
• Beispiel: "Status ist Offen UND Stunden seit Offen > 24"

Zeitbasierte Bedingungen

Automatisierungen sind stark auf diese angewiesen:

Stunden seit Lösung | Größer als | [Anzahl]

• Am häufigsten für die Nachverfolgung nach der Lösung
• Verwenden Sie "Größer als" nicht "Ist" (zuverlässiger)
• Denken Sie daran: Automatisierungen werden stündlich ausgeführt, daher ist das Timing nicht exakt

Stunden seit In Bearbeitung | Größer als | [Anzahl]

• Für die Eskalation von veralteten Tickets
• Üblicher Wert: 48 Stunden (2 Werktage)

Stunden seit Fälligkeitsdatum | Größer als | 0

• Für geplante Wiedereröffnungsworkflows
• Funktioniert nur mit Tickets vom Typ "Aufgabe", die Fälligkeitsdaten haben

Stunden seit Offen | Größer als | [Anzahl]

• Für die Eskalation von Tickets, die zu lange offen bleiben
• Nützlich für SLAs und Prioritätserhöhungen

Teilnehmerbedingungen

Diese helfen Ihnen zu unterscheiden, WER die Wiedereröffnung verursacht hat:

Aktueller Benutzer | Ist | (Endbenutzer)

• Stellt sicher, dass der Auslöser (Trigger) nur bei Kundenaktionen ausgelöst wird
• Entscheidend, um von Agenten ausgelöste Wiedereröffnungsschleifen zu vermeiden

Aktueller Benutzer | Ist | (Agent)

• Für Workflows, bei denen Agentenaktionen wichtig sind
• Weniger häufig für Wiedereröffnungsszenarien

Kommentar | Ist | Öffentlich

• Unterscheidet Kundenkommentare von internen Notizen
• Wesentlich für "Kunde hat geantwortet"-Workflows

Kommentar | Ist | Privat

• Für interne Workflows
• Selten für Wiedereröffnungsszenarien verwendet

Nullifizierende Bedingungen (Verhindern von Schleifen)

Der häufigste Automatisierungsfehler: Vergessen zu verhindern, dass die Automatisierung wiederholt ausgeführt wird. Fügen Sie immer eine nullifizierende Bedingung hinzu.

Tags | Enthält keines der folgenden | [Ihr-Tag]

• Fügen Sie das Tag als Aktion hinzu, wenn die Automatisierung ausgelöst wird
• Verhindert die erneute Ausführung auf demselben Ticket
• Beispiel: Tag "reopen_notified" nach der ersten Benachrichtigung

Warum "Größer als" "Ist" für Zeitbedingungen schlägt

Zendesk Automatisierungen werden in einem stündlichen Zyklus ausgeführt. Wenn Sie "Stunden seit Lösung | Ist | 24" verwenden, könnte die Automatisierung nach 23,5 Stunden (verpasst) und dann nach 24,5 Stunden (wieder verpasst) überprüfen. Die Verwendung von "Größer als" stellt sicher, dass Sie alle berechtigten Tickets erfassen.

Schritt-für-Schritt: Erstellen eines Auslösers (Triggers) für die Wiedereröffnungsbenachrichtigung

Erstellen wir einen praktischen Auslöser (Trigger), der Bearbeiter benachrichtigt, wenn ihre gelösten Tickets wiedereröffnet werden. Dies ist einer der häufigsten Wiedereröffnungsworkflows.

Schritt 1: Navigieren Sie zur Seite "Auslöser (Triggers)"

Gehen Sie zu Admin Center > Objekte und Regeln > Geschäftsregeln > Auslöser (Triggers). Sie sehen eine Liste der vorhandenen Auslöser (Triggers). Löschen Sie die Standardauslöser (Triggers) nicht, es sei denn, Sie wissen genau, was sie tun. Beachten Sie die Zendesk-Referenz zu Auslöserbedingungen für vollständige Bedingungsoptionen.

Schritt 2: Erstellen Sie einen neuen Auslöser (Trigger)

Klicken Sie auf Auslöser (Trigger) hinzufügen. Geben Sie ihm einen beschreibenden Namen wie:

• "Bearbeiter benachrichtigen, wenn Ticket vom Kunden wiedereröffnet wird"
• "Benachrichtigung über wiedereröffnetes Ticket"

Vermeiden Sie vage Namen wie "Auslöser 1". Das zukünftige Ich wird dem gegenwärtigen Ich bei der Fehlersuche danken.

Schritt 3: Legen Sie die Bedingungen fest

Fügen Sie unter "Alle der folgenden Bedingungen müssen erfüllt sein" hinzu:

Ticket: Statuskategorie | Geändert zu | Offen

Optionale, aber empfohlene Ergänzungen:

Ticket: Kommentar | Ist | Öffentlich

(Dies stellt sicher, dass er nur bei Kundenantworten ausgelöst wird, nicht bei internen Notizen)

Ticket: Aktueller Benutzer | Ist | (Endbenutzer)

(Dies bestätigt, dass der Kunde die Wiedereröffnung verursacht hat, nicht ein Agent)

Ticket: Tags | Enthält keines der folgenden | reopen_notified

(Dies verhindert, dass der Auslöser (Trigger) zweimal auf demselben Ticket ausgelöst wird)

Schritt 4: Konfigurieren Sie die Aktionen

Fügen Sie unter "Führen Sie diese Aktionen aus" hinzu:

Bearbeiter benachrichtigen:

Benachrichtigungen: E-Mail-Benutzer | (Bearbeiter)
Betreff: "Ticket vom Kunden wiedereröffnet: {{ticket.title}}"
Text: Fügen Sie Ticketdetails und einen Link hinzu

Tracking-Tag hinzufügen:

Ticket: Tags hinzufügen | reopen_notified

Optional: Priorität festlegen:

Ticket: Priorität | Hoch

(Nützlich, wenn wiedereröffnete Tickets sofortige Aufmerksamkeit benötigen)

Schritt 5: Testen Sie Ihren Auslöser (Trigger)

1. Speichern Sie den Auslöser (Trigger) (er wird automatisch aktiviert)
2. Erstellen Sie ein Testticket oder verwenden Sie ein vorhandenes
3. Lösen Sie das Ticket
4. Fügen Sie einen öffentlichen Kommentar als Endbenutzer hinzu (verwenden Sie ein Inkognito-Fenster oder ein anderes Konto)
5. Überprüfen Sie, ob sich der Status in "Offen" ändert
6. Überprüfen Sie, ob der Bearbeiter die Benachrichtigung erhalten hat

Wenn es nicht funktioniert, überprüfen Sie die Auslöserposition. Zendesk verarbeitet Auslöser (Triggers) von oben nach unten. Wenn ein anderer Auslöser (Trigger) das Ticket zuerst ändert, wird Ihr Auslöser (Trigger) möglicherweise nicht ausgelöst.

Der Automatisierungs-Builder verwendet eine ähnliche Oberfläche, konzentriert sich jedoch auf zeitbasierte Bedingungen anstelle von sofortigen Ereignissen:

Für einen anderen Ansatz für Statusänderungs-Auslöser (Triggers) lesen Sie unseren Leitfaden zum Erstellen von Zendesk-Auslösern (Triggers), wenn sich der Status in "Offen" ändert.

Rezept: Planen von Tickets, die zu bestimmten Zeiten wiedereröffnet werden sollen

Manchmal müssen Sie ein Ticket für die spätere Nachverfolgung "snoozen". Vielleicht hat ein Kunde gesagt "melden Sie sich nächste Woche wieder bei mir" oder Sie müssen überprüfen, ob eine Korrektur funktioniert hat, bevor Sie sie vollständig schließen. So erstellen Sie einen geplanten Wiedereröffnungsworkflow.

Schritt 1: Aktivieren Sie den Status "In Wartestellung"

Standardmäßig ist der Status "In Wartestellung" nicht aktiv. Gehen Sie zu Admin Center > Objekte und Regeln > Tickets > Status und fügen Sie den Status "In Wartestellung" hinzu, falls Sie dies noch nicht getan haben. Weitere Informationen finden Sie im Zendesk-Rezept für die geplante Wiedereröffnung.

Schritt 2: Erstellen Sie ein Makro für Agenten

Makros stellen sicher, dass Agenten den Workflow konsistent befolgen. Erstellen Sie ein Makro, das:

1. Typ auf Aufgabe setzt
2. Status auf In Wartestellung setzt
3. Ein benutzerdefiniertes Tag hinzufügt (wie "schedule_reopen")
4. Den Agenten auffordert, das Feld Fälligkeitsdatum festzulegen

So erstellen Sie das Makro:

• Admin Center > Arbeitsbereiche > Agenten-Tools > Makros
• Makro hinzufügen
• Aktionen: Typ = Aufgabe, Status = In Wartestellung, Tags hinzufügen = schedule_reopen

Schritt 3: Erstellen Sie die Wiedereröffnungsautomatisierung

Erstellen Sie nun eine Automatisierung, die auf Fälligkeitsdaten achtet:

Bedingungen:

Ticket: Statuskategorie | Ist | In Wartestellung
Ticket: Typ | Ist | Aufgabe
Ticket: Tags | Enthält mindestens eines der folgenden | schedule_reopen
Ticket: Stunden seit Fälligkeitsdatum | Größer als | 0

Aktionen:

Ticket: Statuskategorie | Offen
Ticket: Tags hinzufügen | auto_reopened

Die Bedingung "Stunden seit Fälligkeitsdatum > 0" bedeutet "das Fälligkeitsdatum ist verstrichen". Wenn die Automatisierung ausgeführt wird (stündlich), wird jedes Ticket, dessen Fälligkeitsdatum verstrichen ist, wiedereröffnet.

So verwenden Agenten diesen Workflow

1. Agent wendet das Makro auf ein Ticket an
2. Agent wählt das gewünschte Wiedereröffnungsdatum im Feld "Fälligkeitsdatum" aus
3. Ticket geht in den Status "In Wartestellung"
4. Am ausgewählten Datum wird es von der Automatisierung automatisch wiedereröffnet

Dieser Workflow ist besonders nützlich für:

• Follow-up-Erinnerungen
• Warten auf externe Abhängigkeiten
• Saisonale oder zeitkritische Probleme
• Vom Kunden angeforderte Rückrufe

Lösen des "Danke"-Wiedereröffnungsproblems

Hier ist eine Statistik aus der Zendesk-Community, die möglicherweise Anklang findet: 60-70 % der Ticket-Wiedereröffnungen sind nur Kunden, die "Danke" sagen. Keine Follow-up-Fragen. Keine Beschwerden. Nur höfliche Dankbarkeit, die unnötige Arbeit für Agenten verursacht.

Die Herausforderung besteht darin, echtes Dankeschön von "Danke, aber ich brauche immer noch Hilfe" zu unterscheiden. Ein einfacher Keyword-Auslöser (Trigger), der alles, was "Danke" enthält, automatisch löst, wird irgendwann ein echtes Problem verpassen.

Lösung 1: Die Hashtag-Methode

Schulen Sie Kunden, einen bestimmten Hashtag zu verwenden, wenn sie tatsächlich eine Wiedereröffnung benötigen. Fügen Sie in Ihre E-Mail mit dem gelösten Ticket Formulierungen wie die folgenden ein:

"Wenn Sie weitere Unterstützung benötigen, antworten Sie mit #reopen und wir werden uns bei Ihnen melden. Andernfalls ist keine Antwort erforderlich."

Auslöser (Trigger) einrichten:

Bedingungen:
- Statuskategorie | Geändert zu | Offen
- Kommentartext | Enthält nicht die folgende Zeichenfolge | #reopen

Aktionen:
- Status | Gelöst
- Tags hinzufügen | false_reopen
- E-Mail-Anforderer | "Ihr Ticket bleibt gelöst. Antworten Sie mit #reopen, wenn Sie Hilfe benötigen."

Dies funktioniert, erfordert aber Kundenschulung. Nicht alle Kunden lesen sorgfältig.

Lösung 2: Der Auto-Solve-Auslöser (Trigger) (mit Schutzmaßnahmen)

Erstellen Sie einen Auslöser (Trigger), der Tickets, die "Danke" oder "Vielen Dank" enthalten, automatisch löst, aber NUR, wenn keine Fragezeichen vorhanden sind.

Auslöser (Trigger) einrichten:

Bedingungen:
- Statuskategorie | Geändert zu | Offen
- Kommentartext | Enthält mindestens eines der folgenden | danke vielen dank
- Kommentartext | Enthält keines der folgenden | ?

Aktionen:
- Status | Gelöst
- Tags hinzufügen | auto_solved_thanks

Dies erfasst "Vielen Dank für Ihre Hilfe!", verpasst aber "Danke, aber wie mache ich...?"

Lösung 3: Apps von Drittanbietern

Die Thank You GPT App vom Zendesk Marketplace verwendet KI, um echtes Dankeschön von Follow-up-Fragen zu unterscheiden. Sie wurde speziell für dieses Problem entwickelt.

Lösung 4: KI-gestützte Erkennung (erweitert)

Für Teams mit Zapier- und OpenAI-Zugriff können Sie einen ausgefeilten Workflow erstellen:

1. Auslöser (Trigger) erkennt die Wiedereröffnung und fügt ein Tag hinzu
2. Zapier überwacht eine Ansicht für getaggte Tickets
3. OpenAI analysiert den Kommentar: "Ist das nur ein Dankeschön oder gibt es eine echte Frage?"
4. Wenn nur ein Dankeschön, löst Zapier das Ticket über die API

Ein Head of CX bei einem großen Unternehmen teilte sein Setup:

Ich habe eine Automatisierung über Zapier mit einer Eingabeaufforderung in OpenAI erstellt, die Wunder für uns wirkt. Ich würde es sehr empfehlen.

Zendesk Community

Unsere Empfehlung

Beginnen Sie mit Lösung 2 (Auto-Solve mit Fragezeichen-Schutz). Es ist einfach, kostenlos und erfasst die meisten Fälle. Wenn Sie immer noch in Dankeschön-Wiedereröffnungen ertrinken, aktualisieren Sie auf die Thank You GPT App oder ziehen Sie einen KI-gestützten Ansatz in Betracht.

Apropos, unser KI-Agent behandelt genau dieses Szenario, indem er die Absicht versteht, anstatt nur Schlüsselwörter abzugleichen. Er kennt den Unterschied zwischen "Danke!" und "Danke, aber..." ohne komplexe Auslöserketten.

Häufige Fehler und Fehlerbehebung

Selbst erfahrene Zendesk-Administratoren stoßen auf Probleme mit Wiedereröffnungsautomatisierungen. Hier sind die häufigsten Probleme und wie Sie sie beheben können.

Auslöser (Trigger) wird nicht ausgelöst

Überprüfen Sie die Auslöserposition. Zendesk verarbeitet Auslöser (Triggers) von oben nach unten. Wenn ein anderer Auslöser (Trigger) das Ticket zuerst ändert (insbesondere einer, der den Status ändert oder Tags hinzufügt), hat Ihr Auslöser (Trigger) möglicherweise nie die Chance, ausgeführt zu werden. Verschieben Sie Ihren Wiedereröffnungs-Auslöser (Trigger) nach oben.

Überprüfen Sie "Geändert zu" vs "Ist". Dies ist der Fehler Nr. 1. "Status ist Offen" entspricht jedem offenen Ticket. "Status geändert zu Offen" entspricht nur Tickets, die gerade offen geworden sind. Für die Wiedereröffnungserkennung benötigen Sie "Geändert zu".

Überprüfen Sie Ihr Statusfeld. Wenn Sie benutzerdefinierte Status aktiviert haben, verwenden Sie "Statuskategorie" nicht "Status". Wenn Sie einen Team-Plan ohne benutzerdefinierte Status haben, verwenden Sie "Status".

Automatisierung wird mehrfach ausgeführt

Sie haben eine nullifizierende Bedingung vergessen. Jede Automatisierung benötigt eine Möglichkeit, um zu verhindern, dass sie wiederholt ausgeführt wird. Fügen Sie ein Tag hinzu, wenn die Automatisierung ausgelöst wird, und fügen Sie dann "Tags enthält keines der folgenden" in Ihre Bedingungen ein.

Beispielhafte Korrektur:

Bedingungen:
- Status | Gelöst
- Stunden seit Lösung | Größer als | 24
- Tags | Enthält keines der folgenden | solved_24h_notified

Aktionen:
- E-Mail-Bearbeiter | "Ticket wurde seit 24 Stunden gelöst"
- Tags hinzufügen | solved_24h_notified

API-Updates verursachen unerwartete Öffnungen

Tools von Drittanbietern, die Tickets über die API aktualisieren, können Ihre Wiedereröffnungsworkflows unbeabsichtigt auslösen. Ein häufiger Übeltäter: Umfrage-Tools, die Bewertungen zurück in gelöste Tickets schreiben.

Korrektur: Fügen Sie diese Bedingung hinzu:

Ticket: Aktualisierung über | Ist nicht | Webdienst (API)

Dies verhindert, dass Ihr Auslöser (Trigger) bei API-basierten Aktualisierungen ausgelöst wird, während benutzerinitiierte Änderungen weiterhin erfasst werden.

Status vs. Statuskategorie Verwirrung

Dies stolpert fast jeden:

• Status (Team-Pläne): Das tatsächliche Statusfeld (Neu, Offen, In Bearbeitung, Gelöst, Geschlossen)
• Statuskategorie (Growth+ mit benutzerdefinierten Status): Gruppen verwandter Status

Wenn Sie benutzerdefinierte Ticketstatus aktiviert haben, werden Ihre Standardstatus zu Kategorien. Verwenden Sie "Statuskategorie"-Bedingungen, um alle Variationen zu erfassen. Wenn Sie einen Team-Plan haben, verwenden Sie "Status".

Zeitbedingung verpasst

Die Verwendung von "Stunden seit Lösung | Ist | 24" ist riskant. Da Automatisierungen stündlich ausgeführt werden, überprüfen sie möglicherweise nach 23,5 Stunden (verpasst) und dann nach 24,5 Stunden (wieder verpasst).

Verwenden Sie immer "Größer als" für Zeitbedingungen.

Wann Sie stattdessen eine KI-gestützte Automatisierung in Betracht ziehen sollten

Zendesk Auslöser (Triggers) und Automatisierungen sind leistungsstark, aber sie sind im Wesentlichen regelbasiert. Sie tun genau das, was Sie ihnen sagen, nicht mehr und nicht weniger. Manchmal ist das einschränkend.

Betrachten Sie diese Szenarien:

Sie haben 20+ Auslöser (Triggers) nur für die Wiedereröffnungsbehandlung. Wenn Ihre Auslöserliste unübersichtlich wird, ist dies ein Zeichen dafür, dass die regelbasierte Automatisierung an ihre Grenzen stößt