SLA, Kalender & Eskalationen

Fristen richtest du unter „Settings → SLA" ein. Die Seite sagt dir oben selbst, wenn keine Regel aktiv ist. Eine Regel besteht aus drei Teilen: einem Namen, den Bedingungen und den Zielen. Neue Regeln werden bewusst inaktiv angelegt. Du kannst sie in Ruhe fertig einstellen, bevor sie etwas bewirken.

Bedingungen sind „Team", „Priority", „Main category" und „Subcategory". Leer heißt „Any", also „gilt für alles" und nicht „gilt für nichts". Passen mehrere Regeln, gewinnt die mit der kleinsten Zahl unter „Order". Deshalb steht die enge Regel oben und die allgemeine darunter.

Die beiden Kategoriefelder sind nach Team gruppiert, weil Kategorien einem Team gehören. Angeboten werden dir trotzdem alle, auch die anderer Teams. Das ist Absicht: Bei einer Abgabe wandert das Ticket, die Kategorie nicht. Ein Ticket, das das Helpdesk an das Netzwerk-Team abgegeben hat, trägt weiterhin die Einordnung des Helpdesks, und eine Regel darf genau darauf zeigen. Wählst du eine Hauptkategorie, bietet dir das Feld darunter nur noch die Unterkategorien an, die mit ihr verknüpft sind. Ein Paar, das es am Ticket nicht geben kann, wird beim Speichern abgelehnt.

Jede Regel hat zwei Ziele. „Time to first response" endet mit der ersten öffentlichen Antwort eines Bearbeiters. Eine automatische Empfangsbestätigung und ein interner Kommentar zählen ausdrücklich nicht. „Time to resolution" endet, sobald das Ticket einen Status erreicht, der als gelöst gilt. Welcher das ist, legst du unter „Settings → General → Status" fest. Beide Ziele haben eigene Minuten, einen eigenen Kalender und eine eigene Reaktion auf die Überschreitung.

Am Ticket stehen die Fristen rechts in der Karte „Details", darunter „Show deadline history". Dieses Buch schreibt jeden Schritt mit: gestartet, pausiert, fortgesetzt, eingehalten, überschritten. Zu jedem Schritt stehen der Grund und die verbrauchte Arbeitszeit dabei. Das sehen nur Bearbeiter und Administratoren, für Kunden ist es nicht abrufbar.

Ändert später jemand Priorität oder Team, wechselt die Uhr auf die dann passende Regel. Die bisher verbrauchte Zeit wird noch mit dem alten Kalender abgerechnet, danach gelten die neuen Werte. Passt gar keine Regel mehr, endet die Uhr ohne Urteil. Sie zählt weder als eingehalten noch als überschritten.

Passte bei der Anlage keine Regel, startet die Uhr, sobald nach einer Änderung zum ersten Mal eine passt. Ein Beispiel ist eine höhere Priorität. Gezählt wird ab diesem Moment. Die Uhr für die erste Antwort startet nur, wenn noch niemand geantwortet hat.

Neue Uhren entstehen erst wieder, wenn ein Ticket wieder geöffnet wird. Andere Statuswechsel erzeugen keine neuen Uhren.

Ein Kalender sagt, wann die Uhr läuft. Er hat einen Namen, eine eigene Zeitzone und je Wochentag beliebig viele Zeitfenster. Eine Mittagspause ist also einfach ein Tag mit zwei Fenstern. Ein Fenster darf über Mitternacht hinausgehen. Dann steht daneben „ends next day".

Welcher Kalender für ein Team gilt, stellst du unter „Settings → Teams" am Team ein. Am einzelnen Ziel einer Regel kannst du ihn übersteuern: „From the team" nimmt den des Teams, oder du wählst einen anderen. So entsteht der übliche Fall: Störungen zählen rund um die Uhr, alles andere nur während der Bürozeit.

Gezählt wird die tatsächlich verstrichene Zeit im Fenster, nicht die Differenz der Uhrzeiten. Bei der Zeitumstellung macht das einen Unterschied: Ein 24/7-Tag im Oktober hat 25 Stunden, eine Nachtschicht von 22 bis 6 Uhr im Frühjahr sieben statt acht. Ein Bürofenster von 9 bis 17 Uhr ist nie betroffen, weil in der EU nachts umgestellt wird.

Findet sich kein Kalender mit offenen Zeiten, entsteht keine Frist. Am Ticket steht dann ein Hinweis statt eines Datums.

Unter jedem Kalender steht die Liste „Closed days". Ein Klick auf „Import holidays (.ics)" nimmt eine Kalenderdatei entgegen und meldet danach vier Zahlen: wie viele Tage übernommen, wie viele ersetzt, wie viele unlesbar und wie viele schon vorhanden waren. Einzelne Tage kannst du auch von Hand eintragen.

Das Zeichen ↻ hinter einem Tag heißt „wiederholt sich jährlich". Es ist nur für feste Termine richtig: Der 3. Oktober liegt jedes Jahr auf demselben Datum, Karfreitag und Pfingstmontag hängen am Osterdatum und wandern. Wandernde Feiertage stehen deshalb mit ihrem konkreten Datum je Jahr in der Liste. Im Bild ist das „Good Friday" ohne das Zeichen.

Ein geschlossener Tag schluckt das ganze Fenster dieses Tages, auch den Teil, der in den Folgetag hineinreicht. Kennt ein Kalender für die nächsten zwölf Monate keinen einzigen geschlossenen Tag, sagt die Seite das ausdrücklich. Sonst rechnet das System über Feiertage hinweg und liefert falsche Fristen.

Der häufigste Streit um Fristen ist der: Das Ticket wartet seit drei Tagen auf eine Antwort des Kunden, und die Uhr läuft trotzdem. Deshalb hat jedes Ziel den Schalter „Pause while waiting for the requester". Er gilt je Ziel und nicht für die ganze Regel.

Ob gewartet wird, entscheidet der Status. Unter „Settings → General → Status" trägt jeder Status eine Marke dafür, ob er als „wartet auf den Anfragenden" gilt. Steht der Schalter an, ruht die Frist, solange das Ticket in einem solchen Status steht. Die Wanduhr läuft dabei weiter. In der Liste steht deshalb „Paused" statt einer Restzeit, und im Ereignisbuch stehen „Paused" und „Resumed" mit Zeitpunkt. Die Wartezeit zählt auch dann nicht, wenn das Ticket direkt aus einem solchen Status gelöst wird.

Für die erste Antwort lässt man den Schalter üblicherweise aus: Die erste Antwort schuldest du unabhängig davon, worauf gerade gewartet wird. Für die Lösung steht er meist an. Im Bild ist genau das eingestellt.

Sobald eine Regel aktiv ist, bekommt die Ticketliste die Spalte „Deadline". Sie zeigt die Restzeit der nächsten offenen Frist, zum Beispiel „14h 53m". Läuft am Ticket keine Frist mehr, steht dort das Urteil: die Marke „In time" für eingehalten, das rote „Breached" für überschritten. Ein Ticket ganz ohne Uhr bekommt einen neutralen Strich, und der ist Absicht: Ein Ticket aus der Zeit vor der Regel ist kein Versäumnis.

Ist keine Regel aktiv, fehlt die Spalte ganz. Sie steht nicht leer da. Dasselbe gilt für den Filter: Unter „Filter" erscheint das Kästchen „Breached only" nur dann, wenn es überhaupt Fristen gibt.

Ein Ticket hat zwei Uhren, die Spalte hat aber nur einen Platz. Sie zeigt die dringlichste OFFENE Frist. Ist die erste Antwort überschritten und die Lösung läuft noch, steht in der Spalte die Restzeit der Lösung, daneben ein rotes „!". Das Zeichen sagt, dass an diesem Ticket bereits eine Frist gerissen ist. Genau darüber findet der Filter „Breached only" das Ticket, denn er fragt nach jeder überschrittenen Frist, auch nach einer längst abgeschlossenen. Welche der beiden es getroffen hat, steht im Ticket selbst.

Sortieren kannst du danach ebenfalls. Unter demselben Punkt „Deadline" steht ein Feld mit „Due soonest first" und „Due latest first". Tickets ohne laufende Uhr stehen dabei immer am Ende. Sie sind nicht am wenigsten dringend, sie sind schlicht nicht betroffen. Die Sortierung nach Frist hat Vorrang vor der nach „Updated at", denn zwei Reihenfolgen auf einmal kann keine Liste erfüllen.

Je Ziel legst du unter „When breached" fest, was beim Überschreiten passiert. „Record only" vermerkt es nur. „Notify assignee and observers" schickt eine Mail an den Bearbeiter und die Beobachter, aber nicht an das ganze Team. „Hand over to another team" gibt das Ticket ab. Bei der Weitergabe musst du ein Zielteam wählen. Eine Regel ohne Zielteam wird beim Speichern abgelehnt, denn sie sähe eingerichtet aus und täte nichts.

Die Aktion läuft genau einmal je Uhr. Ohne diesen Riegel würde ein Neustart des Servers dieselbe Mail noch einmal verschicken. Der Vermerk „schon erledigt" wird auch dann gesetzt, wenn das Verschicken fehlgeschlagen ist. Sonst ginge jede Minute eine neue Mail hinaus.

Der Bruch selbst wird auf den Zeitpunkt der Fälligkeit datiert und nicht auf den Prüflauf. Sonst hinge die Auswertung am Takt des Prüfdienstes. Gemessen wird an der verbrauchten Arbeitszeit: Eine pausierte Uhr kann nicht reißen, auch wenn das Fälligkeitsdatum längst vorbei ist.

Die Weitergabe setzt den Status auf „Open" zurück. Die Zeilen dazu im Verlauf sind intern. Der Kunde sieht am Ticket nur den neuen Status und das neue Team.

Unter „Reports" wählst du den Zeitraum und drückst „Generate report". Ohne diesen Klick bleibt die Seite leer. Im Bericht steht dann der Block „Service level agreements" mit einer Zeile je Ziel: eingehalten, überschritten, noch laufend, Erfüllungsgrad und die durchschnittlich verbrauchte Zeit.

Gezählt wird je Ziel und nicht je Ticket. Das steht auch unter der Tabelle. Ein Ticket mit beiden Zielen erscheint also zweimal, einmal in jeder Zeile.

Der Erfüllungsgrad zählt nur entschiedene Uhren. Laufende gehören nicht in den Nenner, sonst sähe jede frisch eingeschaltete SLA erst schlecht aus und würde von selbst besser. Gibt es noch keine einzige entschiedene Uhr, steht dort ein Strich und nicht „0 %".

Arbeitest du mit Sammelstörungen, gibt es zusätzlich die Zeile „Achieved without group incidents": Eine einzige Sammelstörung mit hundert angehängten Tickets würde die Quote sonst in beide Richtungen verzerren. Sie lässt jedes Ticket weg, das mit einer Sammelstörung verknüpft ist.

Bearbeiter sehen in diesem Block nur ihre eigenen Teams. Ohne Professional erscheint der Block nur, wenn es Daten zu Fristen aus der Zeit davor gibt. Dann bleibt er lesbar.