SLAs und Eskalationen in Zoho Desk: Fristen, Geschäftszeiten und Stufen einrichten

SLAs und Eskalationen in Zoho Desk richten Sie in drei Schritten ein. Sie legen pro Abteilung Reaktions- und Lösungszeiten fest. Sie binden diese Fristen an Ihre Geschäftszeiten. Dann definieren Sie Eskalationsstufen, die überfällige Tickets einem anderen Agenten zuweisen oder ihre Priorität ändern.

Ein SLA (Service-Level-Agreement) ist nach der Definition von Zoho der Teil eines Vertrags, der Art und Qualität der zugesagten Leistung festlegt. In Zoho Desk wird diese Zusage zu einer messbaren Frist am Ticket. Laut der Zoho-Desk-Hilfe zu SLAs gelten SLAs je Abteilung und nur im Modul Tickets. Anlegen dürfen sie nur Administratoren.

Die Grenzen sind klar gezogen. Pro SLA sind höchstens zwei Eskalationen für die Reaktionszeit und vier für die Lösungszeit möglich. Wie viele Ziele ein SLA enthalten darf, hängt von der Edition ab. Dieser Beitrag zeigt die Begriffe, die Rangfolge der SLAs, die Editionsgrenzen und ein durchgerechnetes Beispiel mit zwei Eskalationsstufen.

Eine Voraussetzung gilt vorab: Tickets müssen in der richtigen Abteilung landen, sonst greift das falsche SLA. Wenn die Zuordnung noch nicht steht, beginnen Sie mit dem Beitrag Zoho Desk Ticketsystem einrichten und Routing planen.

Die Begriffe rund um SLAs in Zoho Desk sind schnell erklärt, aber sie entscheiden, was gemessen wird. Zoho verwendet die folgenden Definitionen:

• Reaktionszeit ist die Zeit, in der ein Agent auf das Ticket antworten soll, sobald das SLA greift.
• Lösungszeit ist die Frist, bis zu der das Ticket gelöst und geschlossen sein muss.
• Eskalation ist eine im SLA hinterlegte Stufe, auf der Zoho Desk das Ticket einem anderen Agenten zuweisen und seine Priorität ändern kann.
• OLA (Operational-Level-Agreement) ist eine interne Vereinbarung darüber, was einzelne Teams tun, damit die zugesagte Leistung erbracht wird.

Ein Ticket gilt für Zoho Desk erst dann als geschlossen, wenn das Standardfeld „Ticket status“ auf „Closed“ steht. Ein Status wie „gelöst, wartet auf Bestätigung“ stoppt die Lösungsfrist also nicht. Prüfen Sie deshalb Ihre eigenen Statuswerte, bevor Sie Lösungszeiten zusagen.

In der Community taucht außerdem der Begriff „Response Violation“ auf. Gemeint ist eine überschrittene Reaktionsfrist. Ein Anwender fragt dort, wie er solche Verstöße vermeiden kann, und erhält auf der Seite keine Antwort. Die Antwort liegt in der Konfiguration: Fristen passend zu den Geschäftszeiten und Eskalationen, die vor dem Fristende eine verantwortliche Person erreichen.

Wer größere Teams steuert, sollte OLAs nicht ignorieren. Zoho beschreibt sie als besonders nützlich in Organisationen, in denen Teams voneinander abhängen. Ein SLA gegenüber dem Kunden hält nur, wenn die interne Übergabe zwischen erster und zweiter Ebene ebenfalls geregelt ist.

Zoho Desk wählt das SLA für ein Ticket in fester Reihenfolge. Zuerst sucht das System ein gültiges Vertrags-SLA, dann ein Konto-SLA. Findet es keines und passen die Kriterien, gilt standardmäßig das globale SLA.

Vertrags-SLAs hängen über Supportpläne an Verträgen. Wird ein Vertrag angelegt und einem Konto zugeordnet, verknüpft Zoho Desk Supportplan und SLA automatisch mit diesem Konto. Das spart Handarbeit, wenn Ihre Servicezusagen ohnehin vertraglich geregelt sind. Wenn Ihre Kundenkonten aus dem CRM kommen, hilft die Anleitung Zoho Desk mit Zoho CRM verknüpfen, damit Konten nicht doppelt gepflegt werden.

Auch die Automatisierungen laufen in fester Reihenfolge, wenn ein Ticket angelegt oder geändert wird:

1. Direkte Zuweisungsregeln
2. Workflow-Regeln
3. SLA
4. Round-Robin-Regeln (sequenziell, nach Auslastung, nach Fähigkeiten)
5. Blueprint
6. Benachrichtigungen

Die Reihenfolge hat eine praktische Folge. Eine Workflow-Regel, die etwa die Priorität setzt, läuft vor dem SLA. Ihre SLA-Kriterien können also auf Werten aufbauen, die ein Workflow gerade gesetzt hat.

Ein Grenzfall zeigt sich in der Community. Ein Anwender betreut einen Kunden mit zwei Produkten, eines mit SLA-Stufe „Diamond“, eines mit „Standard“. Beim Versuch, demselben Kunden ein zweites SLA zuzuordnen, meldet Zoho Desk einen Fehler, weil bereits ein SLA existiert. Klären Sie solche Fälle vor dem Aufbau, statt sie im Betrieb zu entdecken.

Welche SLA-Funktionen Sie nutzen können, hängt direkt von Ihrer Zoho-Desk-Edition ab. Die Hilfeseite nennt drei Grenzen: mehrere Ziele pro SLA, kundenbezogene SLAs und die Vertrags- oder SLA-Verwaltung. Die folgende Tabelle fasst die Angaben aus der Zoho-Hilfe zusammen.

Edition	Mehrere Ziele pro SLA	Kundenbezogene SLAs	Vertrags- und SLA-Verwaltung
Free	nein	nein	nein
Express	nein	nein	nein
Standard	ja, bis zu 10	nein	nein
Professional	ja, bis zu 10	ja	nein
Enterprise	ja, bis zu 10	ja	ja

Für die Entscheidung heißt das: Wer allen Kunden dieselbe Frist zusagt, kommt mit einem globalen SLA aus. Wer je Kunde unterschiedliche Fristen braucht, benötigt mindestens Professional. Wer Fristen über Verträge und Supportpläne steuern will, braucht Enterprise.

Die Zahl der Konten spielt ebenfalls eine Rolle. Ein Anwender in der Community führt jeden Kundenstandort als eigenes Konto. Einige seiner Kunden haben 50 oder mehr Standorte, und er fragt, ob sich ein SLA mehreren Konten auf einmal zuordnen lässt. Die Seite zeigt keine Lösung dafür. Planen Sie bei vielen Standorten deshalb früh, ob die Zuordnung über Verträge oder über ein globales SLA mit passenden Kriterien laufen soll.

Geschäftszeiten legen fest, welche Stunden auf eine SLA-Frist angerechnet werden. Wählen Sie im SLA Geschäftszeiten aus, überspringt die Frist die Feiertage und arbeitsfreien Tage, die in diesen Geschäftszeiten hinterlegt sind. Ohne diese Verknüpfung läuft die Uhr auch nachts und am Wochenende.

Ein Ticket, das freitagabend eingeht, würde sonst bis Montag längst als überfällig gelten. Die Eskalation ginge dann an Menschen, die gar nicht im Dienst sind. Hinterlegen Sie deshalb zuerst die Geschäftszeiten mit allen Feiertagen und arbeitsfreien Tagen Ihrer Teams. Erst danach legen Sie die Fristen an.

Ein Praxisbeispiel aus der Community zeigt einen pragmatischen Aufbau. Eine Supportorganisation arbeitet mit Fristen für drei Prioritäten und unterschiedliche Supportpakete, gemessen an der Erstreaktion. Zusätzlich wendet sie ein Standard-SLA als Auffangregel auf alle Tickets an. Der Zweck laut Anwender: Zeit außerhalb der Geschäftszeiten und Zeit im Status „On Hold“ sollen nicht in die zeitbasierten Kennzahlen einfließen.

Für Ihre Einrichtung lassen sich daraus zwei Fragen ableiten:

• Welche Geschäftszeiten gelten für welche Abteilung, einschließlich Feiertagen?
• Welche Ticketstatus sollen die Messung anhalten, weil Sie auf den Kunden warten?

Beantworten Sie beide Fragen schriftlich, bevor Sie Fristen eintragen. Die Antworten bestimmen, ob Ihre gemessenen Zeiten später mit der Wahrnehmung der Kunden übereinstimmen.

Das folgende Beispiel stammt aus einer Anwenderfrage in der Zoho-Community und eignet sich gut als Vorlage. Das SLA sieht drei Stunden für die Erstreaktion und zwölf Stunden für die Lösung vor. Ein Ticket geht um 09:00 Uhr ein, die Reaktionsfrist endet also um 12:00 Uhr.

Der Anwender möchte vor Fristende zwei Hinweise auslösen. Dreißig Minuten vorher soll der zuständige Agent informiert werden, zwanzig Minuten vorher dessen Vorgesetzter. Die Zeitachse sieht so aus:

Uhrzeit	Ereignis	Empfänger
09:00	Ticket geht ein, SLA greift	zuständiger Agent
11:30	erste Stufe, 30 Minuten vor Fristende	zuständiger Agent
11:40	zweite Stufe, 20 Minuten vor Fristende	Vorgesetzter des Agenten
12:00	Reaktionsfrist endet	Auswertung als Verstoß

Die zwei Stufen passen genau zur Grenze von Zoho Desk: Für die Reaktionszeit sind höchstens zwei Eskalationen möglich. Für die zwölfstündige Lösungsfrist stehen bis zu vier Stufen bereit. Ob eine Stufe vor oder nach dem Fristende auslöst, prüfen Sie in den Eskalationseinstellungen Ihres SLA.

Der Anwender will dasselbe Muster auch für die zweite Frist nutzen, sobald der Agent geantwortet hat und die Lösungszeit zählt. Übertragen Sie dafür die Logik auf die Lösungseskalationen. Planen Sie dort die Stufen breiter, etwa Agent, Teamleitung und Bereichsleitung, damit nicht jede Stufe dieselbe Person trifft.

Eine Eskalation in Zoho Desk wirkt nur, wenn sie eine Person erreicht, die handeln kann. Zoho Desk kann ein Ticket bei einer Eskalation einem anderen Agenten zuweisen und die Priorität ändern. Beides verschiebt Verantwortung sichtbar, statt nur eine weitere E-Mail zu erzeugen.

Wie schnell Benachrichtigungen zur Last werden, zeigt ein Bericht aus der Community. Nach dem Einrichten von SLA-Regeln erhält ein Anwender für jedes Ticket eine E-Mail, wenn ein Agent nicht innerhalb von zwei Stunden antwortet. Er fragt, ob diese Hinweise nur im Feed erscheinen können oder ob sich E-Mails ohne Folgen für das SLA abschalten lassen. Wer solche Mails in Massen erhält, liest sie bald nicht mehr.

Planen Sie die Empfänger deshalb pro Stufe:

• Erste Stufe: der zuständige Agent, damit er selbst reagieren kann.
• Zweite Stufe: eine benannte Teamleitung, verbunden mit Neuzuweisung oder höherer Priorität.
• Weitere Lösungsstufen: Bereichsleitung, nur für Tickets, die wirklich festhängen.

Bei Svennis testen wir jede Eskalationsstufe vor dem Livegang mit einem Testticket, das wir bewusst liegen lassen, und prüfen, wer die Benachrichtigung tatsächlich erhält. So fällt sofort auf, wenn eine Stufe an ein Sammelpostfach statt an eine verantwortliche Person geht.

Für kleine Teams, in denen eine Person mehrere Rollen trägt, finden Sie Hinweise im Beitrag Zoho Desk für ein kleines Support-Team einrichten.

Die meisten SLA-Probleme in Zoho Desk entstehen in der Konfiguration, nicht in der Software. Vier Fehlerquellen lassen sich aus der Hilfe und aus Community-Berichten ablesen.

Frist setzt sich bei jeder Änderung zurück

Wählen Sie im SLA mehrere Ausführungsoptionen, setzt sich das SLA laut Zoho bei jeder Aktualisierung zurück. Ein Ticket, das regelmäßig bearbeitet wird, erreicht dann nie seine Frist. Wählen Sie die Ausführungsoptionen deshalb sparsam und bewusst.

Ticket ist erledigt, aber nicht geschlossen

Nur der Status „Closed“ im Feld „Ticket status“ beendet die Lösungsfrist. Eigene Abschlussstatus zählen nicht. Agenten müssen das wissen, sonst eskalieren erledigte Tickets.

Eskalation bleibt aus

Ein Anwender berichtet, dass die Eskalation trotz eingerichteter SLAs nicht mehr ausgelöst wurde, obwohl sie früher funktionierte. Im selben Bericht wurden Zwischenantworten aus dem Portal als neue Tickets behandelt. Testen Sie Eskalationen deshalb nicht nur einmal, sondern nach jeder Änderung an Regeln oder Kanälen.

Standard-SLAs sind schlecht dokumentiert

Laut einem Community-Bericht tragen die systemseitigen Standard-SLAs für alle Stufen dieselbe Beschreibung, obwohl ihre Einstellungen abweichen. Änderungen an der Beschreibung wurden nicht gespeichert. Dokumentieren Sie Ihre SLAs daher zusätzlich außerhalb von Zoho Desk und benennen Sie eigene SLAs eindeutig.

Klären Sie zudem vorab, welche Tickets ganz ohne Frist laufen sollen. Ein Anwender wollte das SLA entfernen, indem er die Priorität auf „-None-“ setzt, und fand dafür auf der Seite keine Antwort.

Die Auswertung von SLA-Kennzahlen braucht eine eigene Prüfung, sobald Tickets zwischen Supportebenen wandern. Ein Anwender beschreibt in der Community genau dieses Problem. In Zoho Analytics scheint die Erstreaktionszeit seines Frontline-Teams dem Agenten der nächsten Ebene zugeschrieben zu werden, der das Ticket schließt.

Derselbe Anwender sieht in manchen Fällen Antworten von Agenten der zweiten Ebene als Erstreaktion. Diese Agenten haben aber nicht als Erste geantwortet. Für eine Leistungsbewertung einzelner Teams ist das ein ernstes Problem.

Prüfen Sie deshalb vor der ersten Auswertung drei Dinge:

1. Wählen Sie einige Tickets mit Weitergabe aus und vergleichen Sie die Ticket-Historie mit dem Bericht.
2. Klären Sie, welchem Agenten der Bericht die Erstreaktion zuordnet.
3. Entscheiden Sie, ob Sie Fristen pro Team oder pro Ticket bewerten wollen.

Diese Stichprobe kostet wenig Zeit und verhindert, dass Teams auf Basis falsch zugeordneter Zahlen beurteilt werden. Wer SLA-Berichte mit Daten aus anderen Systemen verbinden möchte, findet Hintergründe auf der Seite zur Einführung von Zoho Analytics.

Für Unternehmen in Deutschland ist das SLA in Zoho Desk vor allem die technische Abbildung einer Zusage aus dem Vertrag. Zoho definiert das SLA selbst als Vertragsbestandteil. Die Fristen in Zoho Desk sollten daher wörtlich zu dem passen, was in Ihren Serviceverträgen steht.

Vier Punkte verdienen dabei besondere Aufmerksamkeit:

• Geschäftszeiten: Hinterlegen Sie die Feiertage und arbeitsfreien Tage jedes Standorts, an dem Ihr Supportteam arbeitet.
• Vertragsbezug: Wenn Sie Fristen je Kunde vertraglich zusagen, wählen Sie eine Edition mit kundenbezogenen SLAs oder Vertragsverwaltung.
• Wortlaut: Verwenden Sie in Verträgen dieselben Begriffe wie im System, also Reaktionszeit und Lösungszeit mit klarer Definition.
• Mitbestimmung: Wenn Sie SLA-Berichte oder Eskalationen nutzen, um die Arbeit einzelner Agenten auszuwerten, kann das ein Mitbestimmungsrecht des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG auslösen. Klären Sie das vor dem Livegang.

Ein Abgleich zwischen Vertragstext und SLA-Konfiguration verhindert Streit über die Frage, wann eine Frist begann. Steht im Vertrag „innerhalb von drei Stunden“, muss klar sein, ob Geschäftsstunden oder Kalenderstunden gemeint sind. Zoho Desk misst nur das, was Sie im SLA einstellen.

Für Administratoren bietet Zoho außerdem zertifizierte virtuelle Schulungen zu Zoho Desk an, ausdrücklich auch für Nutzer in Europa. Das ist eine Option für Teams, die SLAs dauerhaft selbst pflegen wollen.

Ihr SLA-Setup in Zoho Desk steht stabil, wenn Sie in dieser Reihenfolge vorgehen:

1. Prüfen Sie Ihre Edition anhand der Tabelle oben und klären Sie, ob Sie kundenbezogene SLAs oder Verträge brauchen.
2. Legen Sie Geschäftszeiten mit Feiertagen und arbeitsfreien Tagen für jede Abteilung an.
3. Gleichen Sie Reaktions- und Lösungszeiten mit Ihren Serviceverträgen ab.
4. Planen Sie pro Frist die Eskalationsstufen und benennen Sie für jede Stufe eine verantwortliche Person.
5. Wählen Sie die Ausführungsoptionen so, dass sich die Frist nicht bei jeder Änderung zurücksetzt.
6. Testen Sie jede Stufe mit einem Testticket, auch außerhalb der Geschäftszeiten.
7. Prüfen Sie nach den ersten Wochen eine Stichprobe von Tickets mit Weitergabe zwischen den Ebenen.

Diese Reihenfolge stellt sicher, dass Fristen auf den richtigen Zeiten beruhen und Eskalationen eine handelnde Person erreichen. Wenn Sie Kunden zusätzlich entlasten wollen, bevor überhaupt ein Ticket entsteht, lesen Sie den Beitrag Wissensdatenbank und Kundenportal in Zoho Desk aufbauen.

Wenn Sie SLAs, Geschäftszeiten und Eskalationen gemeinsam mit der übrigen Desk-Konfiguration planen möchten, finden Sie den Ablauf auf der Seite zur Implementierung von Zoho Desk.

• Zoho Desk Hilfe: SLAs - Scope, Purpose, Understanding, and Setting up
• Zoho Community: Creating alerts and escalations before SLA violated
• Zoho Community: SLA - Stop Email Notification
• Zoho Community: Question regarding ticket SLAs and first response time
• Zoho Community: One customer multiple products and SLA
• Zoho Community: Assign SLA to multiple accounts at the same time
• Zoho Community: Zoho support - escalation not working
• Zoho Community: System default SLA descriptions can't be modified
• Zoho Community: Ticket SLA
• Zoho Community: Response Violation - Zoho Desk