Zendesk SLA-Richtlinien Filterbedingungen: Ein umfassender Leitfaden

Stevia Putri

Stanley Nicholas
Last edited February 20, 2026
Expert Verified
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:
| Array | Logik | Was es bedeutet |
|---|---|---|
| all | AND (UND) | Jede Bedingung in diesem Array muss wahr sein, damit das Ticket übereinstimmt |
| any | OR (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:
| Feld | Operatoren | Was es filtert |
|---|---|---|
| group_id | is (ist), is_not (ist nicht) | Tickets, die bestimmten Agentengruppen zugewiesen sind |
| assignee_id | is (ist), is_not (ist nicht) | Tickets, die bestimmten Agenten zugewiesen sind |
| requester_id | is (ist), is_not (ist nicht) | Tickets von bestimmten Anfragenden |
| organization_id | is (ist), is_not (ist nicht) | Tickets von bestimmten Organisationen |
| current_tags | includes (enthält), not_includes (enthält nicht) | Tickets mit oder ohne bestimmte Tags |
| via_id | is (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:
| Feld | Operatoren | Was es filtert |
|---|---|---|
| ticket_type_id | is (ist), is_not (ist nicht) | Frage (1), Vorfall (2), Problem (3) oder Aufgabe (4) |
| current_via_id | is (ist), is_not (ist nicht) | Kanal, der für das letzte Update verwendet wurde |
| exact_created_at | less_than (weniger als), greater_than (größer als) usw. | Zeitstempel der Ticket-Erstellung |
| custom_status_id | is (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.
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:
| Metrik | Am besten geeignet für |
|---|---|
| Erste Antwortzeit | Anfängliche Kundenbestätigung |
| Nächste Antwortzeit | Laufende Reaktionsfähigkeit der Konversation |
| Wartezeit des Anfragenden | Gesamte Wartezeit des Kunden |
| Gesamte Lösungszeit | Vollständige Problemlösung |
| Regelmäßige Aktualisierungszeit | Kunden während langer Untersuchungen auf dem Laufenden halten |
Legen Sie Ziele für jede Prioritätsstufe fest. Ein üblicher Ausgangspunkt ist:
| Priorität | Erste Antwort | Nächste Antwort |
|---|---|---|
| Dringend | 15 Minuten | 30 Minuten |
| Hoch | 1 Stunde | 2 Stunden |
| Normal | 4 Stunden | 8 Stunden |
| Niedrig | 24 Stunden | 48 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.
Beispiel 1: VIP-Kundenrichtlinie
Für Kunden mit Premium-Supportverträgen:
Alle Bedingungen:
- Organisation ist "VIP-Kunden" ODER Tags enthalten "Premium-Support"
Metriken:
| Priorität | Erste Antwort | Nächste Antwort |
|---|---|---|
| Dringend | 15 Minuten | 30 Minuten |
| Hoch | 30 Minuten | 1 Stunde |
| Normal | 1 Stunde | 2 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:
- VIP-/Enterprise-Kundenrichtlinien
- Spezifische Kanalrichtlinien (Chat, Telefon)
- Spezifische Tickettyprichtlinien (Vorfälle)
- 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
| Problem | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Richtlinie wird nicht angewendet | Falsche Reihenfolge oder Logikfehler | Überprüfen Sie, ob spezifischere Richtlinien zuerst angezeigt werden; Überprüfen Sie die UND/ODER-Logik |
| Es scheinen mehrere Richtlinien zu gelten | Nur die erste Übereinstimmung zählt | Überprüfen Sie die Reihenfolge; Überlegen Sie, ob die Bedingungen zu breit gefasst sind |
| SLA-Uhr scheint falsch zu sein | Fehlkonfiguration der Geschäftszeiten | Überprüfen Sie die Zeitplanzuweisung und die Einstellungen für die Geschäftszeiten |
| Gruppen-SLA-Konflikte | Verwechslung zwischen regulären und Gruppen-SLAs | Denken 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
Diesen Beitrag teilen

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.


