Schlüsselpunkte
- SLA-Verletzungen können durch langsame Arbeit der Techniker:innen, externe Wartezeiten oder falsch gezählte Nicht-Arbeitszeiten entstehen, und jede Ursache verlangt eine andere Lösung.
- Wer aktive Arbeitszeit von Wartezeit trennt, kann als IT-Team unterscheiden, ob die Leistung der Techniker:innen das Problem ist oder Verzögerungen durch Benutzer:innen, genehmigende Personen, Anbieter oder Abhängigkeiten.
- Genehmigungsschritte gehören mit benannten Verantwortlichen, Fristen und Eskalationswegen ins Ticket, damit blockierte Entscheidungen sichtbar und zuordenbar bleiben.
- SLA-Timer sollten konfigurierte Supportzeiten und Feiertagskalender berücksichtigen, damit Nächte, Wochenenden oder regionale Unterschiede keine falschen Verletzungen auslösen.
- Alarmierungen vor der Verletzung geben Support-Teams Zeit, Tickets neu zuzuweisen oder zu eskalieren, bevor Service-Ziele gerissen werden.
- Werden verletzte Tickets nach Ursache ausgewertet, verbessern MSPs und interne IT-Abteilungen ihre Service-Erbringung, ohne die Geschwindigkeit der Techniker:innen fälschlich verantwortlich zu machen.
Sie öffnen den Verletzungsbericht dieser Woche, und zwei Tickets sehen identisch aus: dieselbe rote Markierung, dasselbe gerissene Ziel, dieselbe Zeile in der Monatsübersicht. Schaut man genauer hin, haben die beiden Tickets nichts gemeinsam. Das eine lag drei Tage in der Warteschlange, weil es niemand übernommen hat. Das andere war in zwanzig Minuten diagnostiziert und wartete dann zwei Tage auf den Gerätebesitzer, der die Genehmigungs-E-Mail nie geöffnet hat. Ein SLA ist ein Versprechen, das lange vor dem Ticket gegeben wurde. Es nicht einzuhalten, ist mehr als nur eine Kennzahl. Es kostet Sie Vertrauen, bei Kund:innen, bei einer Abteilungsleitung oder bei Endbenutzer:innen.
Wenn Sie das Service Level Agreement (SLA) in Arbeitszeit und Wartezeit aufteilen, können Sie deutlich klarer zeigen, wo Sie SLAs einhalten und wo nicht. Dafür müssen Sie nichts Neues erfassen. Jede einzelne dieser Minuten steckt bereits als Statuswechsel mit Zeitstempel in Ihrer Ticket-Historie. Was fehlt, ist die Trennung: Arbeitszeit auf der einen Seite, Wartezeit auf der anderen. Ohne sie klingt „wir reißen unsere SLAs“ nach einem Problem der Techniker:innen, selbst in den Wochen, in denen Ihr Team der schnellste Teil des Prozesses war.
Teilen Sie die Uhr in Arbeitszeit und Wartezeit auf
Die Zeitspanne zwischen „eröffnet“ und „gelöst“ besteht aus zwei grundverschiedenen Dingen, die übereinanderliegen. Ein Teil davon ist aktive Arbeit am Ticket durch Techniker:innen. Der Rest ist ein geparktes Ticket, das auf eine genehmigende Person, einen Anbieter oder Endbenutzer:innen ohne Antwort wartet.
Beides lohnt sich zu beheben, aber nicht auf dieselbe Weise. Arbeitszeit reagiert auf Kontext. Techniker:innen, die bei jedem Ticket die ersten fünfzehn Minuten damit verbringen, Gerätehistorien und Asset-Daten zu suchen, bevor die Fehlersuche überhaupt beginnt, sind nicht langsam, das Setup ist langsam. Geben Sie ihnen diesen Kontext von Anfang an, und das Ticket, das früher eine Stunde Suche gekostet hat, startet mit bereits erledigter Suche. Dieser Gewinn fällt vollständig auf die Seite der Arbeitszeit.
An der Wartezeit ändert noch so viel Tempo der Techniker:innen nichts. Definieren Sie einen Status, oder einige wenige, die bedeuten: „wartet auf jemanden, der nicht wir ist“. Sorgen Sie dafür, dass Ihr Lösungsziel in diesem Status entweder pausiert oder die dort verbrachte Zeit getrennt ausweist. Diese eine Änderung macht aus einer einzigen Gesamtzahl zwei Zahlen, mit denen Sie arbeiten können.
Behandeln Sie die Freigabe als nachverfolgten Schritt
Die Change-Enablement-Praktik der Information Technology Infrastructure Library stellt klar: Eine Änderung braucht die Autorisierung durch jemanden, der für das Risiko verantwortlich ist. Diese Autorisierung haben Sie mit großer Wahrscheinlichkeit bereits, nur passiert sie in einer Slack-DM oder einer einzeiligen E-Mail, meist außerhalb des Tickets. Für eine Konfigurationsänderung an einem Laptop ist das genau das richtige Maß an Prozess.
Wenn Sie aber eine Support-Funktion betreiben, ist eine unbeantwortete Genehmigungs-E-Mail unsichtbar. Das Ticket steht auf blockiert, Ihre Techniker:innen werden gefragt, warum, und die ehrliche Antwort lautet: Jemand müsste sein Postfach aufräumen. Für ein Audit gilt: Eine Genehmigung, die niemand protokolliert hat, hat nie stattgefunden. Hängen Sie die Freigabe als expliziten Schritt an das Ticket, mit benannter genehmigender Person, einer Führungskraft, einem Gerätebesitzer, einer Rolle oder einer Ad-hoc-Liste. Damit wird aus einer weichen Abhängigkeit eine zuordenbare. Sie sehen genau, wer Ihnen eine Entscheidung schuldet und seit wann. Geben Sie dem Genehmigungsschritt außerdem ein Zeitlimit und einen Eskalationsweg. Eine begrenzte Wartezeit ist ein bekannter Kostenfaktor, eine unbegrenzte eine Blackbox.
Lassen Sie den Timer nach Ihren Supportzeiten laufen, nicht nach der Wanduhr
Ein Lösungsziel von acht Stunden, gemessen an der realen Uhrzeit, wird jeden Freitagabend pünktlich verletzt, ganz gleich, ob jemand etwas falsch gemacht hat. Dasselbe passiert an Feiertagen, und es passiert ungleichmäßig, sobald Ihr Team über Regionen verteilt ist, die keinen gemeinsamen Kalender haben.
Falsche Verletzungen kosten mehr, als es den Anschein hat. Sie blähen Ihre Zahlen auf, und sobald Techniker:innen zum ersten Mal merken, dass der Bericht Stunden zählt, in denen niemand gearbeitet hat, vertrauen sie dem Bericht nicht mehr. Damit erhalten auch die echten Verletzungen keine Aufmerksamkeit mehr. Konfigurieren Sie Supportzeiten und Feiertagskalender, pro Unternehmen oder global, und der Timer misst endlich etwas, das Handeln rechtfertigt.
Legen Sie Ihre Eskalationsschwelle vor der Verletzung fest. Eine Alarmierung bei 80 % der zugeteilten Zeit verschafft Ihnen ein Zeitfenster zum Umverteilen. Eine Alarmierung bei der Verletzung verschafft Ihnen eine Nachbetrachtung.
Und das ist nicht nur eine interne Zahl. Als MSP sind Reaktionszeiten eine kommerzielle Zusage, die sich je nach Kund:in und Tarifstufe unterscheidet. Bleibt die Wartezeit unerfasst, gehen Sie in ein Verlängerungs- oder Abrechnungsgespräch, ohne belegen zu können, auf wessen Uhr die Zeit tatsächlich lief. Wenn Sie statt eines Kundenstamms einen internen Help-Desk betreiben, sieht der Einsatz anders aus, das Risiko ist aber dasselbe: Niemand stellt Ihnen ein verletztes SLA bei der Patch-Bereitstellung in Rechnung. Aber die Sicherheitsverantwortliche, die fragt, warum dieselben drei Endpunkte ihr Patch-Fenster in diesem Quartal zweimal verpasst haben, führt exakt dasselbe Gespräch, nur ohne Rechnungsposten.
Womit Sie anfangen
Holen Sie sich die verletzten Tickets der letzten 90 Tage und sortieren Sie sie auf drei Stapel: zu langsam bearbeitet, auf eine Person gewartet und hätte nie zählen dürfen. Der zweite und dritte Stapel sind meist größer als der erste, und keiner von beiden lässt sich beheben, indem jemand schneller arbeiten soll.
NinjaOne Ticketing verfolgt Reaktions- und Lösungsziele nach Priorität anhand Ihrer konfigurierten Supportzeiten und zeigt SLA-Status und Restzeit als Board-Spalten, nach denen Sie filtern und sortieren können, inklusive Alarmierungen bei 80 % der zugeteilten Zeit und bei der Verletzung. Genehmigungsschritte gehen an eine Führungskraft, einen Gerätebesitzer, eine Rolle oder eine Ad-hoc-Liste, werden per E-Mail erledigt und protokollieren die Entscheidung direkt am Ticket. Starten Sie Ihre kostenlose Testversion.
