SLA-Richtlinien im Kundensupport, einfach erklärt

Ein Service Level Agreement (SLA) ist ein Versprechen, wie schnell Sie auf Anfragen reagieren und sie lösen. Eine SLA-Richtlinie ist das Mittel, mit dem Ihr Helpdesk dieses Versprechen bei jedem Ticket durchsetzt. Die meisten Richtlinien bestehen aus denselben Teilen:

• Bedingungen: für welche Tickets die Richtlinie gilt, etwa nach Kunde, Kanal oder Anfragetyp
• Ziele: Zeitlimits für die erste Antwort, spätere Antworten und die Lösung, meist pro Priorität festgelegt
• Zeiten: ob die Uhr Geschäftszeiten oder Kalenderstunden zählt
• Pausenregeln: welche Status die Uhr anhalten
• Aktionen bei Verletzung: Erinnerungen, bevor ein Ziel verfehlt wird, und Eskalationen danach

Bei mehreren Richtlinien kommt es auf die Reihenfolge an. Zendesk führt zuerst die Trigger aus, vergleicht das Ticket dann von oben nach unten mit seinen SLA-Richtlinien und wendet die erste an, deren Bedingungen erfüllt sind. Stellen Sie spezifische Richtlinien, etwa eine für Enterprise-Kunden, über allgemeine. Zendesk verlangt außerdem, dass die Priorität des Tickets im Standard-Systemfeld für die Priorität gesetzt ist; ein benutzerdefiniertes Prioritätsfeld passt zu keiner Richtlinie.

Zendesk definiert die Next reply time als die Zeit zwischen dem ältesten unbeantworteten Kundenkommentar und dem nächsten öffentlichen Agentenkommentar. Außerdem gibt es die Kennzahl Periodic update, die die Zeit zwischen öffentlichen Agentenkommentaren misst. Für die Lösung hat Zendesk drei Kennzahlen und empfiehlt, pro Richtlinie nur eine zu wählen: Requester wait time (Zeit in New, Open und On-hold), Agent work time (Zeit in New und Open) und Total resolution time (der gesamte Lebenszyklus von der Erstellung, bis das Ticket gelöst ist).

Freshdesk legt in jeder SLA-Richtlinie pro Priorität Ziele für First response, Every response und Resolution fest. In Jira Service Management ist jedes SLA ein benannter Timer: Sie definieren, wann er startet, pausiert und stoppt, und fügen dann Ziele hinzu, die per JQL auswählen, für welche Anfragen sie gelten, mit Zeitvorgaben in der Form 4h 30m.

Geschäftszeiten zählen nur die Zeit innerhalb Ihres Arbeitsplans; Kalenderstunden zählen jede Stunde jedes Tages. In Zendesk wählen Sie innerhalb einer Richtlinie für jede Priorität Geschäfts- oder Kalenderstunden. Freshdesk fragt, ob jedes SLA die von Ihnen festgelegten Geschäftszeiten oder Kalenderstunden (24x7) verwenden soll. Jira Service Management hängt an jedes Ziel einen Kalender mit Zeitzone, Arbeitstagen und Arbeitszeiten sowie Feiertagen.

Ein Ziel von 4 Geschäftsstunden für ein Ticket, das am späten Freitag erstellt wird, wird womöglich erst am Montag fällig. Das ist fair gegenüber Ihrem Team, entspricht aber nicht dem, was der Kunde erlebt – verwenden Sie daher Kalenderstunden für jede Priorität, bei der Sie Erreichbarkeit rund um die Uhr versprechen.

Das Pausieren ist die andere Hälfte. Zeit, in der Sie auf den Kunden warten, sollte in der Regel nicht gegen Sie zählen, und jedes Tool handhabt das anders:

• Zendesk: Die Requester wait time pausiert in Pending; die Agent work time pausiert in Pending und On-hold; die Total resolution time pausiert bei keinem Statuswechsel, bis das Ticket gelöst ist.
• Freshdesk: Der Status Pending pausiert SLA-Timer, und Sie können den SLA-Timer für jeden Status ausschalten, auch für eigene wie Waiting on Third Party. Tickets mit ausgeschaltetem Timer werden als On Hold angezeigt, und wenn der Kunde antwortet, wechselt das Ticket zurück auf Open und die Uhr läuft weiter.
• Jira Service Management: Ein SLA kann neben seinen Start- und Stopp-Bedingungen Pause-Bedingungen haben, etwa während Sie auf eine Antwort des Kunden warten.

Ein SLA nützt nur, wenn jemand handelt, bevor es verfehlt wird. Legen Sie eine Warnung vor der Frist und eine Eskalation danach fest:

• Zendesk: Bauen Sie eine Automation mit der Bedingung 'Hours until next SLA breach', die ein Team oder eine Person benachrichtigt, wenn ein Ticket kurz vor einer Verletzung steht. Automationen laufen einmal pro Stunde; die Warnung kann also bis zu eine Stunde vor oder nach dem Schwellenwert eintreffen, nie genau im Moment selbst. Im Beispiel von Zendesk fügt dieselbe Automation ein Tag hinzu, damit sie pro Ticket nur einmal auslöst.
• Freshdesk: Jede SLA-Richtlinie kann Agenten 5 Minuten bis 4 Stunden vor Fälligkeit eines Ziels für First response oder Resolution erinnern und bei einer Zielverletzung an den zugewiesenen Agenten oder andere von Ihnen gewählte Personen eskalieren, etwa an eine Teamleitung. Beides wird unter Admin > Workflows > SLA Policies eingestellt.
• Jedes Tool: Schicken Sie Warnungen dorthin, wo Ihr Team tatsächlich hinschaut, etwa in einen Slack-Channel, und nicht nur per E-Mail.

• Zendesk: Legen Sie SLA-Richtlinien mit Bedingungen und Zielen pro Priorität an, wählen Sie für jede Priorität Geschäfts- oder Kalenderstunden und ordnen Sie die Liste so, dass spezifische Richtlinien zuerst kommen. Ergänzen Sie eine Automation für Warnungen kurz vor einer Verletzung.
• Freshdesk: Legen Sie unter Admin > Workflows > SLA Policies pro Priorität Ziele für First response, Every response und Resolution fest, wählen Sie Geschäfts- oder Kalenderstunden und ergänzen Sie dann Erinnerungen und Eskalationen. Legen Sie in den Einstellungen Ihrer Ticketstatus fest, welche Status den SLA-Timer ausschalten.
• Jira Service Management: Legen Sie jedes SLA mit Start-, Pause- und Stopp-Bedingungen an. Mehrere Start-Bedingungen wirken als ODER-Verknüpfung, und das SLA stoppt, sobald irgendeine Stopp-Bedingung erfüllt ist. Fügen Sie dann Ziele hinzu, die Anfragen per JQL auswählen, legen Sie eine Zeitvorgabe fest und wählen Sie einen Kalender.

Unabhängig vom Tool: Starten Sie mit einer Richtlinie und wenigen Prioritäten, lassen Sie sie ein paar Wochen laufen und vergleichen Sie dann die tatsächlichen Zeiten bis zur ersten Antwort und bis zur Lösung mit den Zielen, bevor Sie diese verschärfen.

TascaLab richtet SLA-bezogene Automatisierung auf Zendesk, Freshdesk und Jira ein: Routing, das die Priorität setzt, damit die richtige Richtlinie greift, Warnungen vor SLA-Verletzungen in Slack und geplante SLA-Berichte. Die relevanten Einmalpreise sind Ticket Routing & Categorization (690 €), Automated Reports (620 €) und Custom Automation (ab 1.070 €). Projekte umfassen eine Basisdokumentation, 30 Tage Support nach dem Launch und keine versteckten Kosten, und die meisten dauern 1–3 Wochen. Starten Sie mit einem kostenlosen 30-minütigen Health-Check-Gespräch.