Modulkonfiguration
SLA
Zeitzusagen für Tickets und Aufgaben — messen, überwachen und eskalieren, wenn Durchlaufzeiten zu reißen drohen.
Aktualisiert am 23. Jan. 2026
Konfiguration · Module · 4.4
Ein SLA (Service Level Agreement) ist eine Zeitzusage auf einem Ticket oder einer Aufgabe. Das SLA-Modul erfasst, was Sie zusagen, für welche Fälle es gilt, und prüft, ob Sie die Zusage einhalten — mit einem Timer, der nur während der Geschäftszeiten läuft.
Warum das für das Business zählt
„Zusagen nicht messbar“
Time-to-First-Response und Time-to-Resolution explizit — monatlich berichtfähig.
„Warten auf den Kunden zählt“
Bedingungen pausieren den Timer bei bestimmten Status — faire Messung.
„Uhr läuft außerhalb der Bürozeiten weiter“
Kalender wird an das SLA gehängt → Timer läuft nur in Geschäftszeiten.
„Zu spät eskaliert“
Benachrichtigungssequenz auf SLA-Prozentsatz → Erinnerung, Manager, Lenkungsausschuss automatisch.
Vier Aspekte jedes SLA
| Aspekt | Was er festlegt |
|---|---|
| Klasse | Time to First Response oder Time to Resolution. Zwei verschiedene Messstrategien. |
| Kriterien | Wann das SLA gilt: Organisation, Klassifikation, Priorität, Art (Ticket/Aufgabe), Vorlage, Typ. |
| Zielzeit | Maximal zulässige Durchlaufzeit in Stunden/Minuten + der Kalender, der die Geschäftszeiten definiert. |
| Bedingungen | Wann der Timer startet, pausiert oder stoppt (z. B. Status „Warten auf Kunde“ pausiert). |
Die Kombination Klasse + Kriterien ist eindeutig — dasselbe Setup zweimal anzulegen, löst einen Fehler aus.
Zwei SLA-Klassen
Time to First Response
Wie schnell antwortet jemand auf das Ticket? Stoppt mit der ersten Rückmeldung.
Time to Resolution
Wie schnell ist es gelöst? Stoppt im Abschlussstatus.
Verhalten bei Änderungen
Ändert sich etwas am Ticket (Organisation, Priorität, Klassifikation), prüft Gfacility erneut, ob ein SLA zutrifft. Ein neues SLA wird aktiv, oder ein bestehendes wird ausgeblendet, wenn kein Kriterium mehr passt.
Ändert sich die SLA-Konfiguration selbst, bleiben bereits aktive SLAs intakt — das alte tickt weiter, bis das Ticket geschlossen ist. Erst wenn sich am Ticket etwas ändert, bewertet Gfacility neu.
Welche Entscheidungen treffen Sie?
Welche Prioritätsstufen?
Kritisch · hoch · normal · niedrig — jeweils mit eigener Zielzeit. Zu viele Stufen = unnötige Komplexität.
Geschäftszeiten vs. 24/7?
Welchen Kalender hängen Sie an? Ein Kalender je Service-Team genügt meist.
Welche Status pausieren?
„Warten auf Kunde“, „On Hold“ — sonst tickt externes Warten weiter und Sie reißen unfair.
SLA auf Ticket oder Aufgabe?
Beides möglich, aber pro Use Case wählen — sonst berichten Sie doppelt.