Zendesk SLA-Zurücksetzung bei Antwort oder Status: Eine vollständige Anleitung

Das Verwalten von Service Level Agreements (SLAs) in Zendesk kann sich anfühlen, als würde man versuchen, Rauch einzufangen. Sie richten Richtlinien ein, definieren Ziele und beobachten, wie die Timer herunterzählen. Aber dann passiert etwas Unerwartetes: Eine Ticketpriorität ändert sich, ein Kunde sendet eine Nachricht, die keine Antwort benötigt, oder Ihr Team markiert ein Ticket als ausstehend. Plötzlich verhalten sich diese SLA-Timer auf eine Weise, die Sie nicht erwartet haben.

Zu verstehen, wann Zendesk SLA-Timer zurückgesetzt oder pausiert werden, ist nicht nur ein technisches Detail. Es ist der Unterschied zwischen einer genauen Berichterstattung und dem wöchentlichen Aufwand von Stunden, um manuell zu erklären, warum Metriken für Ihr Führungsteam "falsch" aussehen. Dieser Leitfaden schlüsselt genau auf, wie diese Mechanismen funktionieren, damit Sie Ihre Richtlinien mit Zuversicht konfigurieren können.

Den Unterschied verstehen: Zurücksetzen vs. Pausieren

Bevor wir in spezifische Metriken eintauchen, lassen Sie uns zwei grundlegend unterschiedliche Verhaltensweisen klären:

Zurücksetzen bedeutet, dass der Timer wieder bei Null zu zählen beginnt. Jegliche verstrichene Zeit wird gelöscht und die SLA beginnt von neuem. Dies geschieht, wenn bestimmte Ereignisse einen neuen Messzyklus auslösen.

Pausieren bedeutet, dass der Timer vorübergehend stoppt, sich aber merkt, wo er aufgehört hat. Wenn sich die Bedingungen ändern, wird der Timer genau dort fortgesetzt, wo er pausiert wurde. Es geht keine Zeit verloren oder gewonnen.

Hier ist, warum diese Unterscheidung wichtig ist. Wenn ein Timer zurückgesetzt wird, erhält Ihr Team ein vollständiges, neues Zielfenster. Wenn er pausiert, bleibt der Druck bestehen, da dieser ursprüngliche Stichtag noch bevorsteht. Das Missverständnis, welches Verhalten auf welche Metrik zutrifft, führt zu falschem Vertrauen oder unnötiger Panik.

Zendesk SLA-Pause bei Status: Wenn Timer vorübergehend stoppen

Lösungsmetriken verhalten sich anders als Antwortmetriken. Anstatt bei Agentenaktionen zurückgesetzt zu werden, pausieren sie basierend auf dem Ticketstatus. Dies spiegelt die Realität von Support-Workflows besser wider, bei denen die Arbeit nicht immer kontinuierlich ist.

Wartezeit des Anfragenden (Requester Wait Time)

Die Wartezeit des Anfragenden misst die Gesamtzeit, die ein Kunde während des gesamten Ticketlebenszyklus auf Ihr Team wartet. Der Clou ist, dass sie automatisch pausiert, wenn sich das Ticket im Status "Wartend" (Pending) befindet (Warten auf den Kunden).

Der Timer läuft, während sich das Ticket im Status "Neu" (New), "Offen" (Open) oder "In Wartestellung" (On-hold) befindet. Wenn Sie es als "Wartend" markieren, wird die Pause aktiviert. Wenn der Kunde antwortet und der Status zu "Offen" zurückkehrt, wird der Timer genau dort fortgesetzt, wo er aufgehört hat.

Diese Metrik gibt Ihnen die kundenorientierteste Sicht auf Ihre Leistung. Sie beantwortet: "Wie lange hat diese Person tatsächlich auf uns gewartet?" und nicht "Wie lange existierte das Ticket?".

Agentenarbeitszeit (Agent Work Time)

Die Agentenarbeitszeit geht mit dem Pausenkonzept noch weiter. Sie zählt nur die Zeit, in der sich das Ticket im Status "Neu" oder "Offen" befindet, und pausiert sowohl bei "Wartend" ALS AUCH bei "In Wartestellung".

Warum der Unterschied? "In Wartestellung" bedeutet typischerweise, dass Sie auf einen Dritten warten: einen Lieferanten, einen Spediteur, eine andere Abteilung. Wenn Sie auf jemand anderen warten, bearbeiten Sie das Ticket nicht aktiv, daher sollte die Metrik nicht gegen Ihr Team zählen.

Diese Metrik ist besonders nützlich für Teams, die Tickets an externe Parteien eskalieren. Sie misst nur die Zeit, in der Tickets Ihren Agenten tatsächlich zur Bearbeitung zur Verfügung stehen.

Pausierbare Aktualisierung (Pausable Update)

Die pausierbare Aktualisierung kombiniert Konzepte aus beiden Kategorien. Wie die periodische Aktualisierung misst sie die Zeit zwischen Agentenkommentaren. Aber wie Lösungsmetriken pausiert sie, wenn sich das Ticket im Status "Wartend" befindet.

Das Ziel wird aktiviert, wenn ein Agent seinen ersten öffentlichen Kommentar abgibt, während sich das Ticket im Status "Neu", "Offen" oder "In Wartestellung" befindet. Es pausiert, wenn das Ticket in den Status "Wartend" übergeht. Es wird fortgesetzt, wenn das Ticket zu "Offen" oder "In Wartestellung" zurückkehrt.

Eine Besonderheit, auf die Sie achten sollten: Wenn ein Agent einen öffentlichen Kommentar abgibt und den Status in derselben Aktion in "Wartend" ändert, gilt die Metrik "Pausierbare Aktualisierung" erst, wenn das Ticket zuerst in "Neu", "Offen" oder "In Wartestellung" mit einem öffentlichen Kommentar eingereicht wurde. Dies bringt einige Teams durcheinander, die erwarten, dass die Metrik sofort startet.

Häufige Sonderfälle und Workarounds

Auch mit klaren Regeln erschweren reale Szenarien die SLA-Verfolgung. Hier sind die häufigsten Sonderfälle, denen Supportteams begegnen.

Das Szenario "Keine Antwort erforderlich"

Ihr Agent löst ein Ticket. Der Kunde antwortet mit einem einfachen "Danke" oder einer Bestätigung, dass die Lösung funktioniert hat. Technisch gesehen erstellt dies ein neues Ziel für die nächste Antwort, da ein unbeantworteter Kundenkommentar vorliegt. Aber eine Antwort fühlt sich umständlich und unnötig an.

Wenn der Kunde erneut zu einem wirklich neuen Problem kommentiert, zählt der SLA-Timer ab seiner ursprünglichen "Danke"-Nachricht und nicht ab der neuen Problemstellung. Dies erzeugt falsche Verstoßberichte und verzerrt Ihre Metriken.

Ein Workaround besteht darin, ein Makro zu verwenden, das einen kurzen öffentlichen Kommentar hinzufügt (der die SLA erfüllt) und ihn dann sofort privatisiert, sodass der Kunde ihn nie sieht. Ein anderer Ansatz verschiebt das Ticket vorübergehend in eine andere SLA-Richtlinie, die die Zeit für die nächste Antwort nicht erzwingt, und verwendet einen Trigger, um es zurück zu verschieben, wenn der Kunde eine weitere Nachricht sendet.

Prioritätsänderungen und falsche Verstöße

Ein Ticket kommt mit normaler Priorität mit einem 24-Stunden-Lösungsziel herein. Nach der Untersuchung stellen Sie fest, dass es dringender ist, und ändern es in hohe Priorität mit einem 4-Stunden-Ziel. Das Problem? Wenn das Ticket bereits unter normaler Priorität verletzt wurde, bleibt dieser Verstoß in Ihrer Berichterstattung, obwohl das Ticket jetzt unter hohen Prioritätszielen angemessen behandelt wird.

Zendesk wendet neue Prioritätsziele für die Zukunft an, passt aber historische Verstoßdaten nicht rückwirkend an. Dies verursacht Kopfschmerzen für Teams, die versuchen, die SLA-Leistung genau zu melden.

Einige Teams umgehen dies, indem sie bei erheblichen Prioritätsänderungen ganz neue Tickets erstellen, obwohl dadurch die Gesprächshistorie verloren geht. Andere führen separate Tracking-Tabellen, um zu notieren, welche Verstöße "legitim" gegenüber "Prioritätsänderungsartefakten" waren.

Wiedereröffnete Tickets

Wenn ein gelöstes Ticket wiedereröffnet wird, verhalten sich verschiedene Metriken unterschiedlich:

• Zeit für die erste Antwort und Zeit für die nächste Antwort: Aktivieren Sie neue Ziele, wenn sie mit einem öffentlichen Kundenkommentar wiedereröffnet werden
• Periodische Aktualisierung und pausierbare Aktualisierung: Aktivieren Sie neue Ziele nur, wenn sie mit einem öffentlichen Agentenkommentar wiedereröffnet werden
• Agentenarbeitszeit und Wartezeit des Anfragenden: Reaktivieren Sie dasselbe Ziel und behandeln Sie die Zeit im Status "Gelöst" wie eine Pause
• Gesamte Lösungszeit: Zählt ab der Ticketerstellung weiter und behandelt die Zeit im Status "Gelöst" als Pause

Das Verständnis dieser Nuancen hilft zu erklären, warum wiedereröffnete Tickets manchmal ein seltsames SLA-Verhalten zu haben scheinen.

Best Practices für die Konfiguration von SLA-Richtlinien

Nachdem Sie die Mechanismen zum Zurücksetzen und Pausieren verstanden haben, wie sollten Sie Ihre Richtlinien tatsächlich einrichten? Hier sind praktische Empfehlungen von Teams, die auf die harte Tour gelernt haben.

Beginnen Sie einfach. Wählen Sie die Zeit für die erste Antwort plus eine Lösungsmetrik (die Wartezeit des Anfragenden ist normalerweise die kundenorientierteste Wahl). Machen Sie sich mit diesen Grundlagen vertraut, bevor Sie Komplexität wie die Zeit für die nächste Antwort oder die periodische Aktualisierung hinzufügen.

Entscheiden Sie sorgfältig zwischen Geschäftszeiten und Kalenderstunden. Geschäftszeiten sind fairer für Ihr Team, da sie Nächte und Wochenenden nicht zählen. Aber Kunden erleben Kalenderzeit. Ein Ticket, das am Freitagabend eingereicht wird, fühlt sich an, als wäre es das ganze Wochenende geöffnet gewesen, auch wenn Ihre Geschäftszeituhr nicht viel getickt hat. Einige Teams verwenden Geschäftszeiten für die interne Berichterstattung und Kalenderstunden für kundenorientierte Zusagen.

Ordnen Sie Ihre Richtlinien korrekt an. Zendesk wertet sie von oben nach unten aus und wendet die erste Übereinstimmung an. Platzieren Sie Ihre restriktivsten Richtlinien oben und breitere Auffangrichtlinien unten. Ein häufiger Fehler besteht darin, dass eine generische Richtlinie alles abgleicht, bevor spezifische Richtlinien ausgewertet werden.

Berücksichtigen Sie Kanalunterschiede. Chat-Konversationen haben andere Erwartungen als E-Mail-Tickets. Möglicherweise möchten Sie eine 5-Minuten-Zeit für die erste Antwort für den Chat, aber ein 1-Stunden-Ziel für E-Mails. Verwenden Sie Bedingungen, um verschiedene Kanäle an verschiedene Richtlinien weiterzuleiten.

Legen Sie realistische Ziele fest, die auf der tatsächlichen Kapazität basieren, und nicht auf ambitionierten Zielen. Eine SLA, die Sie konsequent verletzen, ist schlimmer als gar keine SLA. Sie trainiert Ihr Team, die Metrik zu ignorieren, und untergräbt das Vertrauen bei Kunden, die sehen, dass Zusagen nicht eingehalten werden.

Verbesserung der Zendesk SLA-Leistung mit KI

Das Verständnis der SLA-Mechanismen ist wichtig. Aber wäre es nicht besser, diese Ziele mühelos zu erreichen?

Moderne KI-Tools helfen Ihnen, Tickets schneller und konsistenter zu lösen. eesel AI bietet AI Agent und AI Copilot, die direkt mit Ihrer Zendesk-Integration zusammenarbeiten, um Ihre Metriken zu verbessern.

Unser AI Agent bearbeitet häufige, sich wiederholende Fragen sofort. Ein Kunde fragt nach Passwortzurücksetzungen, Bestellstatus oder grundlegender Fehlerbehebung? Er erhält in Sekundenschnelle eine genaue Antwort, nicht in Stunden. Ihre Zeit für die erste Antwort wird für diese Tickets effektiv sofort, und Ihre Lösungszeiten sinken, da Routineprobleme nie eine menschliche Warteschlange erreichen.

Für komplexe Probleme, die menschliches Zutun erfordern, entwirft unser AI Copilot Antworten, indem er Informationen aus Ihrer Wissensdatenbank, vergangenen Tickets und verbundener Dokumentation abruft. Agenten überprüfen und senden, anstatt von vorne zu beginnen. Dies reduziert die Agentenarbeitszeit und liefert Kunden schneller Antworten.

Sie können unsere KI auf Ihren historischen Tickets simulieren, bevor Sie live gehen. Sehen Sie genau, wie sie im Vergleich zu Ihren bestehenden SLA-Zielen abgeschnitten hätte. Passen Sie die Konfigurationen basierend auf realen Daten an, anstatt auf das Beste zu hoffen.

Da wir direkt in Zendesk integriert sind, gibt es keine komplexe Einrichtung oder Workflow-Änderungen. Ihre bestehenden SLA-Richtlinien messen wie immer weiter, aber die Zahlen sehen besser aus.