Zendesk SLA-Richtlinien Filterbedingungen: Ein umfassender Leitfaden

Stevia Putri
Written by

Stevia Putri

Reviewed by

Stanley Nicholas

Last edited February 20, 2026

Expert Verified

Bannerbild für Zendesk SLA-Richtlinien Filterbedingungen: Ein umfassender Leitfaden

Wenn Ihre SLA-Richtlinien in Zendesk falsch sind, bedeutet dies entweder, dass Ihr Team in unerreichbaren Zielen ertrinkt oder dass kritische Tickets durch die Maschen fallen. Beide Szenarien enden auf die gleiche Weise: frustrierte Kunden und gestresste Agenten.

Die Filterbedingungen, die Sie für jede SLA-Richtlinie festlegen, bestimmen, welche Tickets welche Service Level Agreements (Dienstleistungsvereinbarungen) erhalten. Wenn Sie dies richtig machen, hat Ihr Team klare, erreichbare Ziele. Wenn Sie es falsch machen, versprechen Sie entweder zu viel oder liefern zu wenig.

Dieser Leitfaden führt Sie durch alles, was Sie über die Filterbedingungen für Zendesk SLA-Richtlinien wissen müssen. Sie lernen die verfügbaren Bedingungstypen kennen, wie Sie diese für verschiedene Szenarien strukturieren und welche Best Practices dafür sorgen, dass Ihre SLAs für Sie und nicht gegen Sie arbeiten.

Was sind Filterbedingungen für Zendesk SLA-Richtlinien?

SLA-Richtlinienfilterbedingungen sind die Regeln, die bestimmen, für welche Tickets eine bestimmte Service Level Agreement gilt. Stellen Sie sich diese als die Torwächter vor: Wenn ein Ticket die Bedingungen erfüllt, wird die SLA-Richtlinie aktiviert und beginnt mit der Verfolgung anhand ihrer Ziele.

Jede Filterbedingung in Zendesk folgt der gleichen Struktur: ein zu prüfendes Feld, ein Operator zum Vergleichen und ein Wert, mit dem abgeglichen werden soll. So sieht das aus:

{ "field": "type", "operator": "is", "value": "incident" }

Filter sind in zwei Logik-Arrays organisiert:

ArrayLogikWas es bedeutet
allAND (UND)Jede Bedingung in diesem Array muss wahr sein, damit das Ticket übereinstimmt
anyOR (ODER)Mindestens eine Bedingung in diesem Array muss wahr sein, damit das Ticket übereinstimmt

Die Reihenfolge Ihrer SLA-Richtlinien ist wichtig. Zendesk wertet sie von oben nach unten aus und wendet die erste Richtlinie an, deren Bedingungen übereinstimmen. Dies bedeutet, dass Ihre spezifischsten Richtlinien oben stehen sollten, mit breiteren, allgemeineren Richtlinien unten.

Richtlinienmetriken definieren, was Sie tatsächlich messen: erste Antwortzeit, nächste Antwortzeit, Lösungszeit usw. Jede Metrik kann unterschiedliche Ziele basierend auf der Ticketpriorität haben. Sie können auch wählen, ob Sie nur Geschäftszeiten oder Kalenderstunden rund um die Uhr zählen möchten.

Verfügbare Filterbedingungstypen für Zendesk SLA-Richtlinien

Zendesk bietet eine umfangreiche Palette an Bedingungen für das Targeting von Tickets. Diese lassen sich in zwei Kategorien einteilen: Bedingungen, die für Geschäftsregeln (Auslöser, Automatisierungen, Ansichten und SLAs) gelten, und Bedingungen, die spezifisch für SLA-Richtlinien sind. Vollständige technische Details finden Sie in der Zendesk Conditions Reference.

Gemeinsame Bedingungen

Diese Bedingungen funktionieren über SLA-Richtlinien, Auslöser, Automatisierungen und Ansichten hinweg:

FeldOperatorenWas es filtert
group_idis (ist), is_not (ist nicht)Tickets, die bestimmten Agentengruppen zugewiesen sind
assignee_idis (ist), is_not (ist nicht)Tickets, die bestimmten Agenten zugewiesen sind
requester_idis (ist), is_not (ist nicht)Tickets von bestimmten Anfragenden
organization_idis (ist), is_not (ist nicht)Tickets von bestimmten Organisationen
current_tagsincludes (enthält), not_includes (enthält nicht)Tickets mit oder ohne bestimmte Tags
via_idis (ist), is_not (ist nicht)Tickets, die über bestimmte Kanäle erstellt wurden
recipient-Die E-Mail-Adresse, an die das Ticket gesendet wurde
custom_fields_{id}is (ist), is_not (ist nicht)Benutzerdefinierte Ticketfeldwerte

SLA-spezifische Bedingungen

Diese Bedingungen sind nur in SLA-Richtlinienfiltern verfügbar:

FeldOperatorenWas es filtert
ticket_type_idis (ist), is_not (ist nicht)Frage (1), Vorfall (2), Problem (3) oder Aufgabe (4)
current_via_idis (ist), is_not (ist nicht)Kanal, der für das letzte Update verwendet wurde
exact_created_atless_than (weniger als), greater_than (größer als) usw.Zeitstempel der Ticket-Erstellung
custom_status_idis (ist), is_not (ist nicht)Benutzerdefinierte Ticketstatuswerte

Die Unterscheidung zwischen via_id und current_via_id ist erwähnenswert. Die via_id-Bedingung prüft, wie das Ticket ursprünglich erstellt wurde, während current_via_id prüft, wie das letzte Update vorgenommen wurde. Dies ist wichtig, wenn Sie beispielsweise zwischen Tickets unterscheiden möchten, die als E-Mail begonnen haben, und solchen, die in den Chat verschoben wurden.

So erstellen Sie effektive Filterbedingungen für Zendesk SLA-Richtlinien

Das Erstellen von SLA-Richtlinien, die tatsächlich funktionieren, erfordert Planung. Hier ist ein praktischer Ansatz.

Schritt 1: Planen Sie Ihre Richtlinienstruktur

Bevor Sie Zendesk berühren, erstellen Sie eine Übersicht über Ihre Supportstruktur:

  • Welche Kundensegmente benötigen unterschiedliche Reaktionszeiten? (VIP, Unternehmen, kostenlose Stufe)
  • Welche Kanäle haben unterschiedliche Erwartungen? (Chat versus E-Mail)
  • Rechtfertigen unterschiedliche Tickettypen unterschiedliche Behandlungen? (Vorfälle versus Fragen)
  • Welche Teams bearbeiten welche Arten von Aufgaben?

Diese Zuordnung wird zu Ihrer Richtlinienstruktur. Jede eindeutige Kombination erhält ihre eigene Richtlinie.

Visueller Workflow für die Planung der SLA-Richtlinienstruktur basierend auf Kundensegmenten und Kanälen
Visueller Workflow für die Planung der SLA-Richtlinienstruktur basierend auf Kundensegmenten und Kanälen

Schritt 2: Navigieren Sie zum SLA-Richtlinien-Builder

Gehen Sie in Ihrem Zendesk Admin Center (Administrationscenter) zu Objekte und Regeln > Geschäftsregeln > Service Level Agreements (Dienstleistungsvereinbarungen). Klicken Sie auf Richtlinie erstellen, um mit dem Aufbau zu beginnen. Detaillierte Einrichtungsanweisungen finden Sie in der offiziellen Zendesk SLA-Richtliniendokumentation.

Schritt 3: Konfigurieren Sie Ihre Filterbedingungen

Beginnen Sie mit den "All" (Alle) Bedingungen. Dies sind Ihre obligatorischen Kriterien. Wenn diese Richtlinie beispielsweise nur für VIP-Kunden gilt, fügen Sie Folgendes hinzu: Organisation ist "VIP-Kunden".

Fügen Sie dann "Any" (Beliebige) Bedingungen für optionale Kriterien hinzu. Möglicherweise möchten Sie, dass die Richtlinie angewendet wird, wenn das Ticket mit "dringend" gekennzeichnet ist ODER von einer bestimmten Organisation stammt.

Häufige Bedingungskombinationen umfassen organisationsbasierte Filterung für Kundentier-SLAs, gruppenbasierte Filterung für teamspezifische interne SLAs, kanalbasierte Filterung für unterschiedliche Erwartungen an die Reaktionszeit und tagbasierte Filterung für flexibles Routing.

Schritt 4: Richten Sie Ihre Richtlinienmetriken ein

Wählen Sie aus, welche Metriken für diese Richtlinie verfolgt werden sollen:

MetrikAm besten geeignet für
Erste AntwortzeitAnfängliche Kundenbestätigung
Nächste AntwortzeitLaufende Reaktionsfähigkeit der Konversation
Wartezeit des AnfragendenGesamte Wartezeit des Kunden
Gesamte LösungszeitVollständige Problemlösung
Regelmäßige AktualisierungszeitKunden während langer Untersuchungen auf dem Laufenden halten

Legen Sie Ziele für jede Prioritätsstufe fest. Ein üblicher Ausgangspunkt ist:

PrioritätErste AntwortNächste Antwort
Dringend15 Minuten30 Minuten
Hoch1 Stunde2 Stunden
Normal4 Stunden8 Stunden
Niedrig24 Stunden48 Stunden

Wählen Sie Geschäftszeiten, wenn Ihr Team keinen 24/7-Support bietet. Dadurch wird sichergestellt, dass Sie nur die Zeit zählen, in der Agenten tatsächlich zum Arbeiten zur Verfügung stehen.

Häufige Beispiele für Filterbedingungen für Zendesk SLA-Richtlinien

Theorie ist hilfreich, aber konkrete Beispiele erleichtern die Implementierung. Hier sind vier gängige Szenarien.

Vier gängige SLA-Richtlinienkonfigurationen für verschiedene Support-Szenarien
Vier gängige SLA-Richtlinienkonfigurationen für verschiedene Support-Szenarien

Beispiel 1: VIP-Kundenrichtlinie

Für Kunden mit Premium-Supportverträgen:

Alle Bedingungen:

  • Organisation ist "VIP-Kunden" ODER Tags enthalten "Premium-Support"

Metriken:

PrioritätErste AntwortNächste Antwort
Dringend15 Minuten30 Minuten
Hoch30 Minuten1 Stunde
Normal1 Stunde2 Stunden

Platzieren Sie diese Richtlinie oben in Ihrer Liste, damit VIP-Tickets vor Ihren allgemeinen Richtlinien erfasst werden.

Beispiel 2: Kanalspezifische Richtlinien

Verschiedene Kanäle haben unterschiedliche Erwartungen. Eine Chat-Konversation erfordert eine schnellere Antwort als eine E-Mail.

Messaging-Richtlinie (Alle Bedingungen):

  • Via ist "Chat" ODER Via ist "Messaging"

E-Mail-Richtlinie (Alle Bedingungen):

  • Via ist "E-Mail"

Legen Sie Ihre Messaging-Ziele aggressiver fest als bei E-Mails. Kunden erwarten im Chat eine nahezu sofortige Antwort, sind aber bei E-Mails geduldiger.

Beispiel 3: Interne Team-SLAs mit Gruppen-SLAs

Gruppen-SLAs verfolgen die interne Teamleistung und nicht kundenorientierte Metriken. Sie sind nur in Enterprise-Plänen verfügbar.

Gruppen-SLA-Filter:

  • Gruppe ist "Tier 2 Support"

Die einzige für Gruppen-SLAs verfügbare Metrik ist die Gruppenbesitzzeit, die misst, wie lange ein Ticket bei dieser Gruppe verbleibt, bevor es gelöst oder neu zugewiesen wird.

Beispiel 4: Eskalationspfad für Vorfälle

Kritische Vorfälle erfordern eine strenge Verfolgung:

Alle Bedingungen:

  • Priorität ist "Dringend" UND Typ ist "Vorfall"

Fügen Sie Ziele für regelmäßige Aktualisierungen hinzu, um sicherzustellen, dass Kunden auch vor der Lösung Fortschrittsaktualisierungen erhalten.

Best Practices und Fehlerbehebung für Filterbedingungen für Zendesk SLA-Richtlinien

Auch gut geplante SLA-Richtlinien können auf Probleme stoßen. So vermeiden Sie häufige Fallstricke.

Richtlinienreihenfolge

Der häufigste Fehler ist eine schlechte Richtlinienreihenfolge. Denken Sie daran: Zendesk wendet die erste übereinstimmende Richtlinie an und hört auf zu suchen. Wenn Sie eine spezielle Richtlinie für VIP-Kunden haben, muss diese vor Ihrer allgemeinen Richtlinie "alle Tickets" stehen.

Empfohlene Reihenfolge:

  1. VIP-/Enterprise-Kundenrichtlinien
  2. Spezifische Kanalrichtlinien (Chat, Telefon)
  3. Spezifische Tickettyprichtlinien (Vorfälle)
  4. Allgemeine Richtlinien (Auffangrichtlinien)

Die richtige Reihenfolge stellt sicher, dass die richtigen Tickets die richtigen Servicelevel erhalten.

Verwenden von Auslösern mit SLAs

Ein effektives Muster ist die Verwendung von Auslösern, um die Ticketpriorität vor der SLA-Auswertung festzulegen. Dies vereinfacht Ihre SLA-Bedingungen.

Erstellen Sie beispielsweise einen Auslöser, der die Priorität auf "Dringend" setzt, wenn:

  • Betreff enthält "Ausfall" ODER
  • Organisation ist "VIP-Kunden"

Dann können Ihre SLA-Richtlinien einfach nach Priorität filtern, anstatt komplexe Bedingungskombinationen zu verwalten.

Testen vor der Aktivierung

Testen Sie neue SLA-Richtlinien immer mit Beispieltickets, bevor Sie sie aktivieren. Überprüfen Sie, ob:

  • Die richtigen Tickets stimmen mit den richtigen Richtlinien überein
  • Richtlinien werden in der richtigen Reihenfolge angewendet
  • Ziele sind basierend auf historischen Daten realistisch

Häufige Probleme und Lösungen

ProblemWahrscheinliche UrsacheLösung
Richtlinie wird nicht angewendetFalsche Reihenfolge oder LogikfehlerÜberprüfen Sie, ob spezifischere Richtlinien zuerst angezeigt werden; Überprüfen Sie die UND/ODER-Logik
Es scheinen mehrere Richtlinien zu geltenNur die erste Übereinstimmung zähltÜberprüfen Sie die Reihenfolge; Überlegen Sie, ob die Bedingungen zu breit gefasst sind
SLA-Uhr scheint falsch zu seinFehlkonfiguration der GeschäftszeitenÜberprüfen Sie die Zeitplanzuweisung und die Einstellungen für die Geschäftszeiten
Gruppen-SLA-KonflikteVerwechslung zwischen regulären und Gruppen-SLAsDenken Sie daran, dass sie separat verfolgt werden; Gruppen-SLAs messen nur die Besitzzeit

Weitere Tipps zur Fehlerbehebung finden Sie in diesen SLA-Richtlinien Best Practices.

Verwalten von SLAs in großem Maßstab mit KI

Wenn Ihre Supportaktivitäten wachsen, wird die manuelle Verwaltung von SLA-Richtlinien schwieriger. Sie müssen die Leistung überwachen, Trends erkennen und Ziele basierend auf realen Daten anpassen.

Hier können KI-gestützte Tools helfen. Bei eesel AI sind wir darauf spezialisiert, Supportaktivitäten durch intelligente Automatisierung effizienter zu gestalten.

Unsere KI kann Ihre Ticketinhalte analysieren und automatisch Prioritätsanpassungen vor der SLA-Auswertung vorschlagen. Anstatt sich ausschließlich auf manuelle Auslöser zu verlassen, liest die KI den Ticketkontext, um Dringlichkeitssignale zu identifizieren, die möglicherweise übersehen werden.

Für Teams, die mit SLA-Verletzungen zu kämpfen haben, bietet unsere Plattform proaktive Warnungen, bevor Ziele verfehlt werden, nicht danach. Dies gibt Agenten Zeit, die richtigen Tickets zu priorisieren, anstatt auf Verletzungen zu reagieren.

Wir integrieren uns direkt in Zendesk, sodass Ihre bestehenden SLA-Richtlinien weiterhin funktionieren, während die KI-Schicht Intelligenz hinzufügt. Wenn Sie daran interessiert sind, wie KI Ihre SLA-Verwaltung optimieren kann, erfahren Sie mehr über unsere AI Agent-Funktionen.

Das Beste aus Ihren Zendesk SLAs herausholen

Gut konfigurierte SLA-Richtlinien verändern die Arbeitsweise Ihres Supportteams. Sie ersetzen vage Anweisungen wie "schnell antworten" durch klare, messbare Ziele. Sie geben der Führungsebene Einblick in die Leistung. Und sie setzen Kundenerwartungen, die Ihr Team konsequent erfüllen kann.

Die von Ihnen festgelegten Filterbedingungen sind die Grundlage. Nehmen Sie sich Zeit, diese richtig zu planen, gründlich zu testen und regelmäßig anhand von Leistungsdaten zu überprüfen.

Wenn Sie Ihre Supportaktivitäten weiter ausbauen möchten, sollten Sie überlegen, wie KI Ihre bestehende Zendesk-Einrichtung erweitern kann. Wir haben eesel AI entwickelt, um Teams dabei zu helfen, wachsende Supportvolumina zu bewältigen, ohne die Mitarbeiterzahl proportional zu erhöhen. Sie können eesel kostenlos ausprobieren oder eine Demo buchen, um zu sehen, wie es mit Ihrem spezifischen Workflow funktioniert.

Häufig gestellte Fragen

Zendesk wendet die erste übereinstimmende Richtlinie an und stoppt. Deshalb ist die Reihenfolge der Richtlinien so wichtig. Platzieren Sie Ihre spezifischsten Richtlinien oben und Ihre allgemeinen Auffangrichtlinien unten.
Ja. Sie können benutzerdefinierte Ticketfelder im Format custom_fields_{field_id} referenzieren. Die Feld-ID ist in Ihren Ticketfeldeinstellungen sichtbar. Dies ist nützlich, um nach benutzerdefinierten Attributen wie Kundenstufe, Produktlinie oder Region zu filtern.
Gruppen-SLAs haben ihre eigenen separaten Filter, die nur group_id-Bedingungen unterstützen. Sie werden unabhängig von Standard-SLA-Richtlinien ausgewertet, sodass ein Ticket gleichzeitig sowohl eine Standard-SLA als auch eine Gruppen-SLA aktiv haben kann.
via_id prüft den Kanal, über den das Ticket ursprünglich erstellt wurde. current_via_id prüft den Kanal, der für das letzte Update verwendet wurde. Verwenden Sie via_id für das Routing basierend darauf, wie das Ticket gestartet wurde. Verwenden Sie current_via_id, wenn Sie verfolgen müssen, wie sich die Konversation entwickelt hat.
Nein, Zendesk unterstützt keine Auslöserbedingungen basierend auf dem SLA-Verletzungsstatus. Sie können Automatisierungen mit den Bedingungen 'Stunden bis zur nächsten SLA-Verletzung' oder 'Stunden seit der letzten SLA-Verletzung' verwenden, aber diese werden nach einem Zeitplan ausgeführt und nicht sofort ausgelöst, wenn eine Verletzung auftritt.
Mindestens vierteljährlich überprüfen. Überprüfen Sie Ihre SLA-Erfolgsraten in Zendesk Explore. Wenn Ihr Team die Ziele ständig verfehlt, passen Sie entweder die Ziele an oder untersuchen Sie, ob Ihre Filterbedingungen die richtigen Tickets erfassen. Wenn Sie eine 100%ige Zielerreichung erzielen, sind Ihre Ziele möglicherweise zu konservativ.

Diesen Beitrag teilen

Stevia undefined

Article by

Stevia Putri

Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.