Ein Service Level Agreement (kurz SLA), ist eine Vereinbarung zwischen Deinen Kunden und Deinem Support Team. Oder zwischen der Chefetage und Deiner IT-Abteilung. Oder auch zwischen Lieferanten und Dir.
In der Regel ist darin der Zeitrahmen festgelegt, den die eine Partei (z.B. Kunde, Lieferant, Abteilungsleiter etc.) für die Lösung eines Problems oder zumindest für die Antwort darauf erwarten kann, wenn er sich über das Redmine Ticketsystem mit Dir und Deinem Team in Verbindung setzt.
Du verpflichtest Dich also bei einer bestimmten Aktion entsprechend zu reagieren. Mit dem Ziel den Ersteller zeitnah zufrieden zu stellen.
Was beim Nichteinhaltung der Verpflichtung passiert, legen die beiden Parteien in einer schriftlichen Vereinbarung fest. Das muss normal niemand aus dem Team wissen. Wichtig ist, jedoch, dass man vorab entsprechende Eskalationsmaßnahme definiert und seine Mitarbeiter auf die Einhaltung der festgelegten Zeitrahmen trimmt.
SLA in Redmine verwalten mit Redmine Reporting Plugin
Das Redmine Reporting Plugin ist mit einer projektbezogenen SLA-Funktion ausgestattet um Dein Team bei einfachen SLA-Tätigkeiten die auf Tickets in Redmine Anwendung finden, zu unterstützen.
SLAs müssen dabei nicht immer nach außen hin angezeigt werden. Dafür sorgt im Bereich Rollen und Rechte die Möglichkeit einer entsprechenden Rechteverteilung für ausgewählte Rollen. Du bestimmst wer in einem Projekt:
- SLA verwalten kann
- SLA anzeigen kann
- SLA Ausführung festlegen kann
SLAs projektbezogen aktivieren
Wer SLAs für bestimmte Projekte aktiviert erhält dadurch eine gute Möglichkeit seine Supportleistungen klar zu definieren und sein Team bei der Lösung zu unterstützen. Denn so ist jedem im Team klar worum es geht, wenn er eine bestimmte Aufgabe zugewiesen bekommt hinter der mittels SLA Funktionalität ein Zeitrahmen für eine Reaktions- oder Lösungszeit festgelegt ist.
SLAs mit Hilfe des Redmine Reportin Plugins sind immer Prioritätsbezogen. Dadurch kann man für jede Priorität eine Stundenangabe machen bis zur Reaktion und / oder zur Lösung einer Aufgabe. Abhängig von der ausgewählten Ticket-Priorität.
Beispielsweise kannst Du festlegen, dass eine Verpflichtung für ein Fehler-Ticket mit der Priorität hoch darin besteht, dass der Empfänger auf das Ticket spätestens nach 2 Stunden reagieren muss und innerhalb von 6 Stunden eine Lösung für das Problem finden sollte.
Die SLA-Konfiguration findet in der jeweiligen Projektkonfiguration statt und kann damit für jedes Projekt individuell und auf den Workflow abgestimmt, festgelegt werden.
SLA Tickets überwachen
Mit Hilfe von zusätzlichen Filteroptionen lassen sich SLA Tickets über individuell erstellte Ticketabfragen gut überwachen. Nützliche Filter hierfür sind:
- Ticket Lebenszeit
- SLA Reaktionszeit überschritten
- SLA Lösungszeit überschritten
Außerdem kann man durch den Einsatz der Zählerboxen ebenfalls dafür sorgen, dass Dein Supportteam auf der Startseite oder der Projektübersicht rechtzeitig auf neue, auslaufende oder bereits abgelaufene SLA Tickets hingewiesen wird.
Warum SLAs wichtig sind
Unabhängig davon, ob man mit einem Kunden oder Stakeholder SLA Vereinbarungen getroffen hat oder nicht, kann der Einsatz von SLAs im Projekt generell Vorteile haben:
SLAs für Tickets zeigen erstmals auf, wie groß der Zeitrahmen für die Beatwortung von Anfragen und / oder auch wie hoch das Volumen von bestimmten SLA-Anfragen ist. So lässt sich leichter eine Kundenbewertung durchführen. Denn man erkennt besser, wo der Aufwand für bestimmte Supportanfragen besonders hoch ist und kann hier entsprechend gegensteuern (z.B. durch festlegen spezieller Gebühren für bestimmte Anfragetypen).
Wer SLAs einsetzt, gibt einen Zeitrahmen für die Beantwortung von Tickets vor. Das hilft auch dem Support-Team zu einem besseren Überblick über anstehende Tickets. Was für eine bessere Konsistenz sorgt. Der Kunde weiß, wann er mit einer Antwort rechnen kann und der Supportmitarbeiter kann seine Arbeit entsprechend besser planen.
SLAs helfen bei der Priorisierung. Da die SLAs in Redmine Reporting auf Grundlage der Priorität basieren ist es leichter zu entscheiden welche Anfrage zuerst bearbeitet werden soll. Viele tun sich ohne SLA schwer Tickets zu priorisieren. Diese Arbeit wird in diesem Sinn erleichtert. Denn wenn man die Wahl zwischen niedrig, normal und hoch hat, entscheidet man sich auf jeden Fall für die Tickets mit hoher Priorität und entsprechend kurzer Reaktions- / Lösungszeit. Bevor man sich an Tickets mit anderen Prioritäten darunter macht. Wer jedoch dazu tendiert immer nur hoch priorisierte Tickets zu erledigen und die “normalen” ständig zur Seite schiebt, kann hier mit entsprechend anderen Reaktions- / Lösungszeiten gegensteuern und bleibt dadurch maximal flexibel.
Wenn Deine Supportmitarbeiter SLAs nach Prioritäten sortieren können Sie sicher stellen, dass alles rechtzeitig beantwortet wird. Kein Ticket fällt durch ein Raster oder geht verloren. Nicht beantwortete SLA Tickets sind leicht identifizierbar, sowohl für den Kunden als auch für den Supportmitarbeiter.
SLAs helfen dabei die Leistung des Supports zu messen und innerhalb der SLA-Richtlinien besser zu beurteilen. Das trägt nicht nur für Kundenzufriedenheit bei, sondern auch dazu, dass Du besser erkennen kannst, was Dein Team leistet.
Gut zu wissen
- SLAs in Redmine Reporting sind pro Projekt konfigurierbar
- Die Grundlage für die Reaktions- / Lösungszeit ist die Ticketpriorität
- SLAs haben diverse Vorteile für Dich und Dein Team
Warum Priority Support
Vielleicht fragst Du Dich, warum unser Reporting Plugin SLAs nach dem Ticketprioritätsprinzip unterstützt?
Die meisten Agenturen oder mittelständischen Betriebe arbeiten nach dem First-in / First-out Prinzip. Tickets in der Warteschlange werden in der Regel der Reihe nach abgearbeitet.
Das Prinzip funktioniert so lange gut, solange das Ticketvolumen in einem überschaubaren Rahmen bleibt. Nehmen die Supportanfragen überhand. Oder hat man nicht genug Mitarbeiterkapazität für die Anfragenbearbeitung, dann nimmt die Ticketlebenszeit und dadurch die Wartezeit des Erstellers deutlich zu.
Stattdessen sollte sich die Reaktionszeit Deines Teams nach dem Grad der Unterstützung Deines Kunden und der Dringlichkeit des Problems richten. Prioritärer Support hebt diese Kunden hervor und hilft Deinem Team, deren Probleme rechtzeitig zu lösen.
Die SLA-Funktion ist nur eines von zahlreichen Features des Redmine Reporting Plugins. Lerne alle Plugin-Funktionen kennen: Featureliste.
Beispiele für die Setzung von Prioritäten
Wer in den SLA keine konkrete Lösungs- oder Reaktionszeit vereinbart hat. Oder für ein Projekt gar keinen SLA nutzt, aber dennoch entsprechend seinem Team die Arbeit erleichtern will, kann sich an folgende Richtlinien orientieren wenn es um den Support eines Produkts oder einer Leistung nach dem Prioritätsprinzip geht:
Priorität Niedrig: Anfragen von Personen, die keine aktiven Kunden sind und nichts konkretes zu einem Produkt oder Service wissen wollen. Also nur allgemeine Fragen stellen. Im Idealfall an die Kundenakquise weiterleiten.
Priorität Normal: Fragen oder Probleme von Kunden, die jedoch nicht so gravierend sind, dass der Kunde das Produkt oder den Service aktuell nicht verwenden kann. Aber dennoch eine zügige Antwort erfordern.
Priorität Hoch: Fragen oder Probleme von Kunden, die verhindern, dass dieser das Produkt oder den Service effektiv nutzen kann. Sie erfordern eine sofortige Antwort.
Priorität Dringend: Fragen oder Probleme von Kunden die aufgrund dessen das Produkt oder den Service überhaupt nicht nutzen können (blockierter Einsatz). Sie erfordern eine sofortige Antwort. Diese Probleme sollten immer die oberste Priorität sein.
In unserer Online-Demo kann die aktuelle Version von Redmine getestet werden. Die hier beschriebene SLA Funktion des Reporting Plugins steht dort zur Ansicht bereit. Probier es aus. Fragen beantworten wir Dir gerne via E-Mail. Weitere informationen zum Umgang mit SLAs in Redmine gibt es in folgendem Beitrag unseres Blog.