Zendesk SLA-Berichterstattung in Explore: Ein vollständiger Leitfaden für 2026

Die Einhaltung Ihrer Service Level Agreements (SLAs) bedeutet mehr als nur das Halten von Versprechen. Es geht darum, Vertrauen bei Ihren Kunden aufzubauen und die operative Effizienz in Ihrem Support-Team aufrechtzuerhalten. Wenn Sie Zendesk nutzen, haben Sie Zugriff auf eine leistungsstarke Berichterstattungsplattform namens Explore, die Ihnen hilft, Ihre SLA-Leistung zu verfolgen, zu analysieren und zu verbessern.

Dieser Leitfaden führt Sie durch alles, was Sie über die Zendesk SLA-Berichterstattung in Explore wissen müssen. Sie werden lernen, wie Sie aussagekräftige Berichte erstellen, die verfügbaren Metriken verstehen und häufige Probleme beheben. Wir werden auch untersuchen, wie KI-Tools wie eesel AI Ihre Berichterstattung ergänzen können, indem sie Ihnen helfen, SLA-Ziele proaktiv zu erreichen, anstatt sie nur im Nachhinein zu verfolgen.

Die Grundlagen der Zendesk SLAs verstehen

Bevor wir in Explore eintauchen, stellen wir sicher, dass wir das gleiche Verständnis davon haben, was SLAs sind und wie sie in Zendesk funktionieren.

Ein SLA oder Service Level Agreement ist im Wesentlichen ein Versprechen, das Sie Ihren Kunden geben, wie schnell Sie auf deren Anliegen reagieren und diese lösen werden. In Zendesk konfigurieren Sie diese Versprechen über SLA-Richtlinien, die automatisch auf Tickets angewendet werden, basierend auf von Ihnen definierten Bedingungen.

Wichtige SLA-Metriken in Zendesk

Zendesk verfolgt mehrere Standardmetriken, die verschiedene Aspekte Ihrer Support-Leistung abdecken:

Erste Antwortzeit (First Reply Time, FRT) misst die Zeit von der Übermittlung eines Tickets durch einen Kunden bis zum Senden der ersten öffentlichen Antwort durch einen Agenten. Dies ist oft die Metrik für den ersten Eindruck. Sie signalisiert dem Kunden, dass Sie seine Anfrage erhalten haben und daran arbeiten.

Nächste Antwortzeit (Next Reply Time, NRT) verfolgt die Zeit zwischen einem Folgekommentar des Kunden und der nächsten Antwort Ihres Agenten. Im Gegensatz zur ersten Antwortzeit, die einmal pro Ticket gemessen wird, kann die nächste Antwortzeit mehrfach während einer Konversation gemessen werden.

Wartezeit des Anforderers (Requester Wait Time, RWT) ist die Gesamtzeit, die ein Kunde auf eine Antwort Ihres Teams wartet. Diese Uhr läuft, wenn sich ein Ticket im Status „Neu“, „Offen“ oder „Angehalten“ befindet, und pausiert, wenn das Ticket auf „Wartend“ steht (Warten auf Input vom Kunden). Dies vermittelt ein faireres Bild der tatsächlichen Wartezeiten.

Arbeitszeit des Agenten (Agent Work Time, AWT) misst die Gesamtzeit, die ein Ticket im Status „Neu“ oder „Offen“ verbringt. Dies spiegelt wider, wie viel aktiver Aufwand Ihr Team in ein Ticket investiert.

Vollständige Lösungszeit (Full Resolution Time) deckt den gesamten Lebenszyklus eines Tickets von der Erstellung bis zur endgültigen Lösung ab. Dies ist Ihre End-to-End-Metrik dafür, wie lange es dauert, das Problem eines Kunden vollständig zu lösen.

Ziele setzen und Zeit messen

Wenn Sie SLA-Richtlinien konfigurieren, legen Sie Zielzeiten für jede Metrik basierend auf der Ticketpriorität fest. Ein typisches Setup könnte 15 Minuten für „Dringende“ Tickets, 4 Stunden für „Hohe“ Priorität, 24 Stunden für „Normal“ und 72 Stunden für „Niedrige“ Priorität vorsehen.

Sie können auch wählen, ob die Ziele in Geschäftszeiten (unter Berücksichtigung Ihres Betriebsplans) oder in Kalenderstunden (24/7) gemessen werden. Geschäftszeiten geben Ihnen einen genaueren Überblick über die tatsächliche Leistung Ihres Teams, während Kalenderstunden das gesamte Kundenerlebnis einschließlich der Zeiten außerhalb der Geschäftszeiten widerspiegeln.

Erste Schritte mit dem SLA-Datensatz in Explore

Zendesk Explore ist Ihre Analyseplattform, um SLA-Daten in umsetzbare Erkenntnisse zu verwandeln. Um SLA-Berichte zu erstellen, arbeiten Sie mit dem Datensatz Support: SLAs, der alle Daten darüber enthält, wie Ihre Tickets im Vergleich zu Ihren SLA-Richtlinien abgeschnitten haben.

Den Datensatz verstehen

Der SLA-Datensatz ist um einige Schlüsselkonzepte herum strukturiert, die Sie verstehen müssen:

Abschlusszeit der SLA-Metrik (SLA metric completion time) ist die tatsächliche Zeit, die benötigt wurde, um ein SLA-Ziel zu erfüllen. Wenn Ihr Ziel für die erste Antwortzeit 60 Minuten betrug und ein Agent in 45 Minuten antwortete, beträgt die Abschlusszeit 45 Minuten.

Zielzeit der SLA-Metrik (SLA metric target time) ist das Ziel, das Sie in Ihrer Richtlinie festgelegt haben. Dies könnten beispielsweise 60 Minuten für die erste Antwortzeit bei Tickets mit normaler Priorität sein.

SLA-Zielstatus (SLA target status) gibt an, ob das Ziel erreicht wurde (Achieved - innerhalb des Ziels erfüllt), verletzt wurde (Breached - verfehlt) oder noch aktiv ist (Active - noch nicht erfüllt).

SLA-Tickets vs. SLA-Ziele

Hier geraten viele Nutzer durcheinander. Zendesk bietet zwei Möglichkeiten, die SLA-Leistung zu zählen:

SLA-Tickets betrachtet das gesamte Ticket. Wenn ein einziges Ziel bei diesem Ticket verletzt wurde, zählt das gesamte Ticket als verletzt. Dies bietet Ihnen eine kundenorientierte Sichtweise.

SLA-Ziele (SLA Targets) zählt jede einzelne Instanz separat. Da ein Ticket mehrere Ziele für die nächste Antwortzeit haben kann (eines für jedes Hin und Her), bietet dies eine granularere Sicht auf die Leistung.

Stellen Sie sich zum Beispiel ein Ticket vor, bei dem Sie das Ziel für die erste Antwortzeit erreicht, aber zwei nachfolgende Ziele für die nächste Antwortzeit verpasst haben. Bei der Verwendung von SLA-Tickets ist dies ein verletztes Ticket. Bei der Verwendung von SLA-Zielen sind dies zwei Verstöße bei insgesamt drei Zielen.

Instanzbasierte Berichterstattung

Diese Unterscheidung ist wichtig, da einige Metriken, wie die nächste Antwortzeit und die Zeit für periodische Aktualisierungen, mehrere Instanzen pro Ticket haben können. Bei der Berechnung Ihrer prozentualen Erreichungsrate teilt Zendesk die erreichten Instanzen durch die Gesamtinstanzen. Das Verständnis dieses Punktes hilft Ihnen, Ihre Berichte korrekt zu interpretieren.

Erstellung Ihres ersten SLA-Berichts

Lassen Sie uns Schritt für Schritt einen einfachen SLA-Leistungsbericht erstellen.

Schritt 1: Einen neuen Bericht erstellen Öffnen Sie Explore und klicken Sie auf das Berichte-Symbol. Klicken Sie auf Neuer Bericht und wählen Sie den Datensatz Support: SLAs aus.

Schritt 2: Ihre Metriken hinzufügen Ziehen Sie diese Metriken in Ihren Bericht:

• % Erreicht (% Achieved), um Ihre Erfolgsquote zu sehen
• Verletzte Tickets (Breached tickets), um die Fehler zu zählen
• Gesamtzahl der Tickets (Total tickets) für den Kontext

Schritt 3: Attribute zur Segmentierung hinzufügen Fügen Sie diese Attribute hinzu, um Ihre Daten aufzuschlüsseln:

• SLA-Richtlinie (SLA policy), um die Leistung nach verschiedenen Richtlinientypen zu sehen
• Metrikname (Metric name), um FRT vs. NRT vs. Lösungszeit zu vergleichen
• Priorität (Priority), um zu sehen, ob dringende Tickets angemessen bearbeitet werden

Schritt 4: Zeitfilter konfigurieren Verwenden Sie den Datumsfilter, um sich auf relevante Zeiträume zu konzentrieren. Für die laufende Überwachung könnten Sie „Diese Woche“ oder „Diesen Monat“ verwenden. Für Analysen könnten Sie „Letzte 90 Tage“ wählen, um Trends zu erkennen.

Schritt 5: Visualisierungen wählen Wählen Sie Diagrammtypen, die Ihre Daten klar darstellen:

• Balkendiagramme eignen sich gut zum Vergleich von Gruppen (Agenten, Teams, Prioritäten)
• Liniendiagramme zeigen Trends im Zeitverlauf
• Kreisdiagramme können das Verhältnis von erreichten zu verletzten Zielen darstellen

Schritt 6: Speichern und teilen Speichern Sie Ihren Bericht und fügen Sie ihn einem Dashboard hinzu, um einen einfachen Zugriff zu ermöglichen. Sie können Dashboard-Zustellungen an Stakeholder in einem regelmäßigen Rhythmus planen.

Gängige Szenarien für die SLA-Berichterstattung

Hier sind vier praktische Berichtskonfigurationen, die Sie heute implementieren können.

Szenario 1: Verstoßrate nach Agentengruppe

Dies hilft Ihnen zu identifizieren, welche Teams zusätzliche Unterstützung oder Schulung benötigen.

Metriken: % Erreicht, Verletzte Tickets, Gesamtzahl der Tickets

Attribute: Ticketgruppe, SLA-Richtlinie

Visualisierung: Balkendiagramm, sortiert nach % Erreicht (aufsteigend)

Erkenntnis: Gruppen mit niedrigeren Erreichungsraten benötigen möglicherweise Prozessverbesserungen, zusätzliches Personal oder Schulungen zur Prioritätenbehandlung.

Szenario 2: Trends der ersten Antwortzeit

Verfolgen Sie, wie sich Ihre Leistung bei der ersten Reaktion im Laufe der Zeit verändert.

Metriken: % Erreicht (gefiltert nur auf die Metrik „Erste Antwortzeit“)

Attribute: Ticket erstellt - Datum (nach Woche)

Visualisierung: Liniendiagramm mit Trendlinie

Erkenntnis: Achten Sie auf Muster wie sinkende Leistung während Stoßzeiten oder Verbesserungen nach Prozessänderungen.

Szenario 3: Vergleich mehrerer Metriken

Vergleichen Sie die Leistung über verschiedene SLA-Metriken hinweg, um Engpässe zu identifizieren.

Metriken: % Erreicht

Attribute: Metrikname, Priorität

Visualisierung: Gruppiertes Balkendiagramm

Erkenntnis: Wenn die erste Antwortzeit stark, aber die Lösungszeit schwach ist, haben Sie möglicherweise eher ein Triage-Problem als ein Problem mit der Reaktionszeit.

Szenario 4: Tickets kurz vor dem Verstoß (Workaround)

Leider kann Explore nicht über die „Zeit bis zum Verstoß“ für aktive Tickets berichten. Diese Daten sind nur in Echtzeitansichten verfügbar. Hier ist ein Workaround:

1. Erstellen Sie eine Ticketansicht, gefiltert nach Tickets mit SLA-Verstoß in der nächsten Stunde.
2. Fügen Sie die Spalte „Nächster SLA-Verstoß“ hinzu, um Countdown-Timer zu sehen.
3. Verwenden Sie diese Ansicht für die Echtzeit-Überwachung während Stoßzeiten.
4. Es gelten Exportbeschränkungen: CSV-Exporte verlieren die verbleibenden Stunden und wandeln sie in Zeitstempel um.

Für automatisierte Warnmeldungen bei Tickets, die kurz vor einem Verstoß stehen, sollten Sie Dashboard-Tools von Drittanbietern in Betracht ziehen, die häufiger aktualisiert werden als Explore.

Erstellung alternativer SLA-Metriken für Sonderfälle

Manchmal spiegeln die nativen SLA-Metriken die Realität nicht genau wider. Dies passiert typischerweise, wenn:

• Sie Geschäftszeiten geändert haben und aktive Tickets geteilte Daten aufweisen.
• Sie die Erreichung basierend auf der Dauer statt auf dem gespeicherten Status messen müssen.
• Das SLA-Status-Badge eine Sache anzeigt, die Dauer-Metriken jedoch eine andere.

Erstellung der alternativen Metrik für die Verstoßzeit

Erstellen Sie eine standardmäßige berechnete Metrik mit dieser Formel:

VALUE(SLA metric completion time (min)) - VALUE(SLA metric target time (min))

Dies berechnet die Differenz zwischen der tatsächlichen Dauer und der geplanten Dauer. Eine positive Zahl bedeutet, dass das Ziel um diese Anzahl von Minuten verletzt wurde. Eine negative Zahl bedeutet, dass es mit verbleibender Zeit erreicht wurde.

Erstellung des alternativen Status-Attributs

Erstellen Sie ein standardmäßiges berechnetes Attribut mit dieser Formel:

IF VALUE(SLA metric completion time (min)) - VALUE(SLA metric target time (min)) >= 0
THEN "Verletzt"
ELIF VALUE(SLA metric completion time (min)) - VALUE(SLA metric target time (min)) < 0
THEN "Erreicht"
ELSE "Unbekannt"
ENDIF

Dies kennzeichnet jedes Ticket rein basierend auf der Dauer als „Verletzt“ oder „Erreicht“ und umgeht so etwaige Status-Inkonsistenzen.

Wann alternative Metriken verwendet werden sollten

Verwenden Sie diese alternativen Berechnungen nur, wenn Sie vermuten, dass Ihre nativen Metriken ungenau sind. Für die meisten Tickets und Berichterstattungsanforderungen funktioniert das native Attribut für den SLA-Zielstatus korrekt. Diese Alternativen dienen speziell der Fehlerbehebung bei Datenqualitätsproblemen.

Bekannte Einschränkungen und Workarounds

Explore ist leistungsstark, hat aber Einschränkungen, die Sie verstehen sollten.

Zeit bis zum Verstoß nicht verfügbar

Explore ist ein Tool für die historische Berichterstattung, kein Echtzeit-Überwachungssystem. Es kann Ihnen nicht die „Stunden bis zum Verstoß“ für aktive Tickets anzeigen. Diese Daten existieren nur in Ticketansichten.

Workaround: Für Teams, die eine proaktive Überwachung von Verstößen benötigen, bieten Dashboard-Tools von Drittanbietern wie Geckoboard eine häufigere Datenaktualisierung und können Tickets, die kurz vor einem Verstoß stehen, in Echtzeit anzeigen.

Verzögerungen bei der Datenaktualisierung

Abhängig von Ihrem Zendesk-Tarif werden Explore-Daten stündlich oder täglich aktualisiert. Das bedeutet, dass Sie sie nicht für unmittelbare operative Entscheidungen nutzen können.

Workaround: Verwenden Sie Zendesk-Ansichten für den Echtzeitbetrieb und Explore für Trendanalysen und Berichte. Die Tools ergänzen einander.

Planänderungen können Daten splitten

Wenn Sie Ihren Geschäftszeitenplan ändern, können Tickets, die während der Änderung aktiv waren, geteilte SLA-Daten aufweisen, bei denen der Status den alten Plan verwendet, die Dauer-Metriken jedoch den neuen Plan.

Workaround: Verwenden Sie die oben beschriebenen alternativen Metriken, wenn Sie historische Daten analysieren, die Planänderungen umspannen.

SLA-Management über die Berichterstattung hinaus

Das Problem bei der SLA-Berichterstattung ist: Sie sagt Ihnen nur, was bereits passiert ist. Sie ist wertvoll, um Trends zu verstehen und Probleme zu identifizieren, aber sie hilft Ihnen nicht, Verstöße im Moment ihres Entstehens zu verhindern.

Das eigentliche Ziel sollte sein, Ihre SLAs konsequent einzuhalten, nicht nur zu verfolgen, wann Sie sie verfehlen. Hier kann KI einen signifikanten Unterschied machen.

Wie KI SLA-Verstöße verhindert

eesel AI ist ein KI-Teammitglied, das sich direkt in Ihren Zendesk-Workflow integriert. Im Gegensatz zu Explore, das zurückblickt, hilft Ihnen eesel AI in Echtzeit:

Erreichen der Ziele für die erste Antwortzeit: eesel AI kann sofort Antwortentwürfe erstellen, wenn Tickets eingehen. Anstatt dass ein Agent wertvolle Minuten damit verbringt, eine Antwort zu lesen und zu formulieren, erhält er einen versandfertigen Entwurf, den er nur noch prüfen und senden muss. Dies reduziert Ihre erste Antwortzeit drastisch.

Beschleunigung der Lösung: Für laufende Konversationen schlägt eesel AI Antworten basierend auf den leistungsstärksten Tickets Ihres Teams vor. Agenten verbringen weniger Zeit mit Tippen und mehr Zeit mit dem Lösen von Problemen.

Kontinuierliches Lernen: eesel AI lernt aus jeder Interaktion. Wenn Sie einen Entwurf bearbeiten, merkt es sich das. Wenn Sie interne Notizen hinterlassen, bezieht es dieses Wissen ein. Die Entwürfe werden mit der Zeit immer besser.

Nahtlose Integration: eesel AI arbeitet innerhalb von Zendesk. Es gibt kein separates Interface, das man erlernen oder bei dem man sich anmelden muss. Es ist einfach da, wenn Sie es brauchen.

Kombination von Explore-Analysen mit KI-Maßnahmen

Der effektivste Ansatz kombiniert beide Tools. Verwenden Sie Explore, um Ihre SLA-Leistungstrends zu verstehen und Verbesserungsmöglichkeiten zu identifizieren. Verwenden Sie eesel AI, um diese Verbesserungen umzusetzen, indem Sie Ihrem Team helfen, schneller und konsistenter zu reagieren.

Wenn Explore beispielsweise zeigt, dass Ihre erste Antwortzeit während der Morgenstunden, wenn das Ticketvolumen spitzt, konsequent das Ziel verfehlt, kann eesel AI helfen, indem es diese ersten Antworten sofort entwirft und Ihren Agenten so bei jedem Ticket einen Vorsprung verschafft.

Beginnen Sie noch heute mit der Verbesserung Ihrer SLA-Leistung

Sie haben nun eine solide Grundlage für die Erstellung von SLA-Berichten in Zendesk Explore. Sie verstehen die wichtigsten Metriken, wissen, wie man Basisberichte erstellt, und kennen die Einschränkungen der Plattform.

Hier ist, was Sie als Nächstes tun sollten:

1. Überprüfen Sie Ihre aktuellen SLA-Richtlinien. Stellen Sie sicher, dass Ihre Ziele realistisch sind und mit den Kundenerwartungen übereinstimmen.

2. Erstellen Sie Ihren ersten Bericht. Beginnen Sie einfach mit „% Erreicht nach Priorität“. Machen Sie sich mit der Benutzeroberfläche vertraut, bevor Sie Komplexität hinzufügen.

3. Identifizieren Sie Ihre größte Chance. Schauen Sie sich Ihre Daten an, um herauszufinden, wo Sie Ziele am häufigsten verfehlen. Ist es die erste Antwortzeit? Die Lösungszeit? Ein bestimmtes Team oder eine Prioritätsstufe?

4. Ziehen Sie KI-Unterstützung in Betracht. Wenn Sie Ziele für die erste Antwortzeit verfehlen, weil die Agenten mit dem Volumen nicht Schritt halten können, oder wenn die Lösungszeit hoch ist, weil Agenten zu viel Zeit mit dem Verfassen von Antworten verbringen, kann eesel AI helfen.

Denken Sie daran: Berichterstattung ist ein Mittel zum Zweck. Das Ziel sind nicht perfekte Dashboards. Das Ziel ist es, Ihre Versprechen gegenüber den Kunden zu halten und ihnen den Support-Service zu bieten, den sie verdienen.

Bereit, Ihre SLA-Leistung auf die nächste Stufe zu heben? Testen Sie eesel AI zusammen mit Ihrer Zendesk SLA-Verfolgung und verwandeln Sie Erkenntnisse in Taten.