Einführung in das Service Level-Management
SICHERHEIT Wenn Ihre Firma Service Level-Management verwendet, werden alle Mitarbeiter, die Tickets erstellen, verwalten oder an ihnen arbeiten, mit Service Level Agreements arbeiten und sollten sich mit diesem Thema vertraut machen.
Administratoren, die Service Level Agreements erstellen und verwalten, sollten dieses Thema sowie Service Level Agreements verwalten durchlesen.
BEVOR SIE BEGINNEN Diese Funktion kann in Ihrer Autotask-Instanz ausgeblendet sein, da sie nicht aktiviert ist. Wenn ja, können Sie sie auf der Seite > Admin > Adminkategorien > Aktivierungen aktivieren. Siehe Aktivierungen.
In Autotask werden im Service Level-Management Service Level Agreements (SLAs) verwendet, um die Standards für die Leistungserbringung Ihrer Firma zu definieren und dann automatisch den Erfolg beim Erreichen dieser Standards zu messen. Das Service Level-Management beinhaltet vier Hauptkomponenten:
- Richten Sie Standards für die Dauer ein, die Ihr Serviceteam benötigt, um verschiedene Arten von Problemen zu beheben, zum Beispiel wie schnell Sie auf ein kritisches Serverproblem reagieren und es lösen.
- Legen Sie diese Standards in Service Level Agreements (SLAs) fest, die Sie Ihren Kunden präsentieren oder intern verwenden können, um Ihre Servicezielvorgaben zu definieren.
HINWEIS Ihre Firma muss entscheiden, ob Sie Service Level Agreements Ihren Kunden als ein angestrebtes Ziel oder als vertragliche Verpflichtung präsentieren.
- Verbinden Sie die SLAs mit Tickets und Verträgen, um die angegebenen Standards auf die Services anzuwenden, die Sie Ihren Kunden bieten.
- Nutzen Sie Autotask-Daten, um Ihren Erfolg beim Erreichen Ihrer SLA-Zielvorgaben und -Ziele zu messen.
Informationen über Service Level Agreements in Autotask
Egal, ob Sie SLAs erstellen und verwalten oder an Tickets arbeiten, die mit einem SLA verbunden sind, sollten Sie mit diesen grundlegenden Elementen vertraut sein.
Ein Service Level ist ein Leistungsstandard, der den Zeitrahmen definiert, in dem ein Problem je nach Schwere und Auswirkungen gelöst wird.
Ein Service Level Agreement (SLA) ist ein Mindestsatz Service Levels, d. h. Leistungsstandards, den Ihre Firma definiert, um die Servicebedürfnisse eines oder mehrerer Kunden zu erfüllen. Sie können ein SLA haben, das für alle Kunden gilt, oder mehrere SLAs, um unterschiedliche Kundenbedürfnisse zu unterschiedlichen Preispunkten zu erfüllen.
BEISPIEL Sie verhandeln mit einem neuen Kunden, einer Rechtsanwaltskanzlei. Diese Firma speichert alle ihre aktuellen und alten Dokumente auf einem Dateiserver, auf den alle Angestellten mit den entsprechenden Zugriffsrechten zugreifen können.
Wenn Angestellte nicht auf diesen Server zugreifen können, ruhen alle Geschäftstätigkeiten. Sollte dies geschehen, ist dies ein unternehmenskritischen Problem für die Firma, da sie oft gesetzlichen Fristen unterliegen.
Mit einem Service Level Agreement können Sie der Firma Ihre Service Level-Ziele zusichern:
• Bei unternehmenskritischem Service beginnt ein Mitarbeiter innerhalb von 15 Minuten damit, auf das Problem einzugehen. Sie werden innerhalb von drei Stunden berichten, wie Sie das Problem beheben werden. Das Problem wird innerhalb von 8 Stunden gelöst werden. Dieser Standard gilt rund um die Uhr, sieben Tage die Woche, das ganze Jahr über.
• Bei Servicebedürfnissen, die kritisch sind, die Firma jedoch nicht lahmlegen, wird ein Mitarbeiter innerhalb von 2 Stunden reagieren und das Problem wird innerhalb von 16 verlängerten Geschäftsstunden behoben.
• Bei routinemäßigen Support- und Wartungsservices, die kein Notfall sind (wenn beispielsweise ein Drucker ausfällt), wird ein Mitarbeiter innerhalb der regulären Geschäftszeiten reagieren und den erforderlichen Service einplanen.
Die unterschiedlichen Ziele in diesem Beispiel können alle in einem einzigen SLA definiert werden. Sie erreichen dies, indem Sie mehrere „Zielvorgaben“ erstellen.
Autotask definiert vier Hauptphasen im Serviceprozess als SLA-Ereignisse: Erstreaktion, Lösungsplan, Warten auf Kundenreaktion und Gelöst. Bevor Sie damit beginnen, SLAs in Autotask zu verwenden, weist ein Administrator diese Ereignisse zu einem oder mehreren Ticketstatus zu.
Wenn Sie ein Ticket erstellen, das mit einem SLA verbunden ist, beginnt eine SLA-Stoppuhr zu laufen. Wenn die Arbeit auf dem Ticket erledigt ist, wird der Ticketstatus geändert. Wenn er zu einem Status geändert wird, der einem SLA-Ereignis zugeordnet ist, zeichnet Autotask die Zeit und die Ereignisart auf, sodass Sie erfassen können, wie lange es dauert, bis jedes SLA-Ereignis erreicht wird.
HINWEIS Wenn der Status dem Ereignis „Warten auf Kundenreaktion“ zugeordnet ist, wird die Stoppuhr pausiert und läuft erst bei der nächsten Statusänderung weiter.
Siehe Aufgaben- & Ticketstatus und Ticketstatus SLA-Ereignissen zuordnen.
SLA-Ereignis | Beschreibung | SLA-Uhr | Aufgezeichnetes Ereignis |
---|---|---|---|
Erstreaktion | Misst die zwischen dem Erstellen des Tickets und der Erstreaktion (oft eine Bestätigung, dass das Ticket erhalten wurde) an den Kunden verstrichene Zeit. | Läuft | Datum/Uhrzeit für SLA-Erstreaktion |
Lösungsplan | Misst die zwischen dem Erstellen des Tickets und einem Lösungsplan verstrichene Zeit. | Läuft | Datum/Uhrzeit für SLA-Lösungsplan |
Warten auf Kundenreaktion | Pausiert die Uhr während Sie auf eine Reaktion oder Informationen vom Kunden warten. | Pausiert | Es wird nichts aufgezeichnet. |
Gelöst | Misst die zwischen dem Erstellen des Tickets und der Lösung verstrichene Zeit. | Gestoppt | Datum/Uhrzeit für SLA-Lösung |
Handlung | Beschreibung der Zeit für ein SLA-Ereignis |
---|---|
Ein Ticket erstellen/bearbeiten und den Status ändern | Die Zeit für das SLA-Ereignis entspricht dem Datum/der Uhrzeit für die Erstellung/Bearbeitung auf dem Ticket. |
Eine Notiz auf einem Ticket eingeben und den Status ändern | Die Zeit für das SLA-Ereignis entspricht dem Datum/der Uhrzeit für die Statusänderung. |
Zeit auf einem Ticket eingeben und den Status ändern | Die Zeit für das SLA-Ereignis entspricht dem Datum/der Uhrzeit für den Zeiteintrag (damit können Sie nachträglich ein SLA-Ereignis auslösen, wenn Sie zum Beispiel vergessen haben, die geleistete Arbeit auf einem Ticket am vorherigen Tag zu aktualisieren). Bei Erstreaktionsereignissen entspricht das Datum/die Uhrzeit für das SLA-Ereignis dem Startdatum/der Startzeit des Zeiteintrags. Bei den SLA-Ereignissen „Lösungsplan“ und „Gelöst“ entspricht das Datum/die Uhrzeit für das SLA-Ereignis dem Enddatum/der Endzeit des Zeiteintrags. |
Ein Ticket weiterleiten/ändern und den Status ändern | Die Zeit für das SLA-Ereignis entspricht dem Datum/der Uhrzeit, zu dem/der das Ticket weitergeleitet und der Status geändert wurde. |
Eine Workflow-Regel ändert den Status | Die Zeit für das SLA-Ereignis entspricht dem Datum/der Uhrzeit, zu dem/der eine Workflow-Regel ausgelöst wird, die den Ticketstatus aktualisiert. |
HINWEIS Wenn ein SLA-Ereignis aufgezeichnet wird und noch keine vorherigen Ereignisse aufgezeichnet wurden, übernehmen diese Ereignisse automatisch das Datum/die Uhrzeit des aufgezeichneten Ereignisses.
Zum Beispiel: Wenn es das Ereignis „Lösungsplan“ nicht für ein Ticket gibt und Sie lösen das Ticket am 1.4. um 15:00 Uhr, dann wird das Ereignis „Lösungsplan“ ebenfalls auf 1.4. um 15:00 Uhr gesetzt.
HINWEIS Wenn die erste Statusänderung bei einem Ticket eintritt und der neue Status einem SLA-Ereignis außer dem Ereignis „Erstreaktion“ (d. h., „Lösungsplan“, „Warten auf Kundenreaktion“ oder „Gelöst“) zugeordnet wird oder wenn der Ticketstatus auf „Abgeschlossen“ gesetzt wird, bevor ein Erstreaktionsereignis aufgezeichnet wird, dann wird automatisch das Ereignis „Erstreaktion“ aufgezeichnet und dies übernimmt Datum/Uhrzeit des ersten aufgezeichneten Ereignisses. Der mit dem aufgezeichneten Ereignis verbundene Mitarbeiter wird als der Initiator der Erstreaktion gesetzt.
Ein SLA kann mehr als ein Ziel verwalten. Es kann mehrere Zielvorgaben enthalten, mit denen Sie trennen können, wie unterschiedliche Szenarien gehandhabt werden.
Eine SLA-Zielvorgabe definiert Folgendes:
- Die Kombination der Bedingungen (Priorität, Ticketart, Ticketrubrik, Ticketkategorie, Ticketunterkategorie), für die sie gilt.
- Die Anzahl der Stunden bevor jedes SLA-Ereignis (Erstreaktion, Lösungsplan und Gelöst) fällig wird.
- Den Zeitrahmen (Geschäftszeiten, verlängerte Geschäftszeiten oder Alle (24x7)), wann die SLA-Uhr läuft.
HINWEIS Eine bestimmte Kombination von Priorität, Ticketart, Ticketrubrik, Ticketkategorie und Ticketunterkategorie kann mit nur einer Zielvorgabe verknüpft werden.
Die Zielvorgabe muss 100 % mit dem Ticket übereinstimmen. Ein Ticket kann jedoch mit mehr als einer Zielvorgabe übereinstimmen, wie im nachfolgenden Beispiel dargestellt.
BEISPIEL In diesem SLA-Beispiel entspricht ein Ticket mit der Priorität „Kritisch“ der Ticketkategorie „IT:Hardware“ und der Ticketunterkategorie „Server“ beiden kritischen Zielvorgaben, jedoch ist die Übereinstimmung der ersten Zielvorgabe genauer.
Priorität | Ticketart | Ticketrubrik | Ticketkategorie | Ticketunterkategorie | Zeit für Erstreaktion | Lösungsplan | Gelöst | Zeitrahmen |
---|---|---|---|---|---|---|---|---|
Kritisch | [Alle] | [Alle] | IT:Hardware | Server | 0,25 Stunden | 4,00 Stunden | 8,00 Stunden | Alle (24x7) |
Kritisch | [Alle] | [Alle] | [Alle] | [Alle] | 1 Stunde | 16,00 Stunden | Verlängerte Geschäftszeiten | |
Hoch | [Alle] | [Alle] | [Alle] | [Alle] | 5 Stunden | 24,00 Stunden | Geschäftszeiten | |
[Alle] | [Alle] | [Alle] | [Alle] | [Alle] | 24 Stunden | 40 Stunden | Geschäftszeiten |
Wenn die Zielvorgabe zugewiesen wird, werden Tickets anhand der Bedingungsfelder in der Reihenfolge von links nach rechts beurteilt:
- Zuerst wird die Priorität beurteilt. Wenn mehrere übereinstimmende Prioritäten gefunden werden, dann werden Ticketart, Ticketrubrik, Ticketkategorie und Ticketunterkategorie in dieser Reihenfolge berücksichtigt.
- Ticketart und Ticketrubrik sind auf [Alle] gesetzt, sodass die Entscheidung anhand der Ticketkategorie gefällt wird: sie entspricht der ersten Zielvorgabe.
- Die Ticketunterkategorie trifft ebenfalls zu, daher ist die erste Zielvorgabe bestätigt.
HINWEIS Bei der Berichterstattung über die zum Erreichen der Zielvorgabe benötigten Zeit wird die Startzeit des Initiators auf das Ende der ersten aufgezeichneten Minute gerundet und die Uhr startet mit dem Beginn der nächsten Minute. Wenn beispielsweise ein Ticket um 9:59 Uhr erstellt wird und die Erstreaktion um 10:15 Uhr erfolgt, wird die Zeit für die Erstreaktion von 10:00 Uhr bis 10:15 Uhr gezählt und als 0,25 Stunden angezeigt.
Um mehr darüber zu erfahren, wie SLAs Zeitrahmen verwenden, beziehen Sie sich auf Geschäftszeiten für Service Level Agreements einrichten.
Ihre SLA-Ziele werden als Prozentzahl davon definiert, wie oft Ihre Firma erwartet, die SLA-Zielvorgabe zu erreichen.
BEISPIEL Eine Zielvorgabe gibt an, dass Sie auf eine bestimmte Art von Ticket innerhalb von 4 Stunden antworten werden (d. h., das SLA-Ereignis „Erstreaktion“ innerhalb von 4 Stunden erfüllen werden). Sie richten das Erstreaktionsziel als 90 % ein. Das heißt, Sie gehen davon aus, dass Sie 90 % der Zeit auf diese Art von Ticket innerhalb von 4 Stunden antworten werden. Sie erreichen dieses Ziel, selbst wenn Sie die Zielvorgabe für die Erstreaktion in einem von zehn Geschäftsfällen nicht erfüllen.
Diese Informationen sind im Bericht SLA -Leistung nach SLA enthalten. Siehe Berichte über Ticketmetriken und SLA-Leistung.
Service Level Agreements verwenden
Um SLAs zum Aufzeichnen der Zeit zu verwenden, die zum Erfüllen von Service Level-Zielvorgaben erforderlich ist, und Ihren Erfolg beim Erreichen von Service Level-Zielen zu erfassen, müssen Sie SLAs auf Tickets anwenden. Es gibt viele Möglichkeiten, um sicherzustellen, dass jedem Ticket das richtige SLA zugewiesen ist. Sie können SLAs manuell auf Tickets anwenden, wenn Sie das Ticket erstellen oder bearbeiten, oder automatisch anhand von Standardeinstellungen, Verträgen und Workflow-Regeln zuweisen. Siehe Service Level Agreements anwenden.
Wenn Sie an einem mit einem SLA verbundenen Ticket arbeiten, gibt es eine Reihe optimaler Vorgehensweisen, die Sie einhalten sollten, um Ihre SLA-Zielvorgaben und -Ziele nicht zu verfehlen. Siehe Tickets mit Service Level Agreements verwalten.
Wir empfehlen Ihnen, Workflow-Regeln zu verwenden, um Mitarbeiter über bevorstehende SLA-Ereignisse zu benachrichtigen. Siehe Autotask Workflow-Regeln.
Die Seite „Tickethistorie“ eignet sich am besten, um SLA-Daten für ein bestimmtes Ticket zu überprüfen. Benutzer mit Administrator- oder Managerzugriffsrechten können SLA-Daten rückwirkend bearbeiten.