IT Service Level Agreement erklärt
Wer schon einmal im laufenden Betrieb auf eine kritische IT-Störung gewartet hat, kennt das Problem: Ohne klare Vereinbarung bleibt unklar, wie schnell reagiert werden muss, wann ein Ticket eskaliert und was überhaupt als Leistung geschuldet ist. Genau hier lässt sich ein IT Service Level Agreement erklären – als verbindlicher Rahmen, der Erwartungen zwischen Unternehmen und IT-Dienstleister sauber festlegt.
Was ein SLA im Kern regelt
Ein Service Level Agreement übersetzt allgemeine Aussagen wie „schneller Support" oder „hohe Verfügbarkeit" in messbare Zusagen. Erst dadurch wird aus einem guten Vorsatz ein steuerbarer Service. Im Kern regelt jedes SLA drei Dinge:
Leistungsumfang
Welche IT-Services sind enthalten – Helpdesk, Monitoring, Patch-Management, Netzwerk, Security?
Reaktions- & Lösungszeiten
Wann wird reagiert, wann eskaliert, wann ist ein Problem behoben – je nach Kritikalität des Systems?
Servicequalität messen
Wie wird Leistung nachgewiesen – durch Reporting, KPIs und regelmäßige Servicegespräche?
Was in ein belastbares SLA gehört
Ein belastbares SLA ist konkret. Es benennt nicht nur Leistungen, sondern auch Grenzen, Zuständigkeiten und Voraussetzungen:
-
📋Genaue Leistungsbeschreibung „IT-Support" reicht nicht. Gemeint sein muss: Helpdesk, Vor-Ort-Service, Netzwerkbetreuung, Firewall-Betrieb, Monitoring, Security, Patch-Management.
-
🕐Servicezeiten klar definiert Nur werktags 8–17 Uhr oder mit Rufbereitschaft außerhalb? Für manche Unternehmen ist ein Samstagsausfall unkritisch – für andere ein unmittelbares Geschäftsrisiko.
-
🚨Incident-Klassifizierung Kritisch, hoch, mittel, niedrig – klare Kriterien, wann welche Kategorie gilt. Ohne diese Logik verlieren Reaktionszeitvorgaben in der Praxis ihren Wert.
-
📈Reporting und Servicegespräche Regelmäßige Berichte und Reviews sind kein Zusatznutzen, sondern Pflicht. Entscheider brauchen belastbare Aussagen zur Servicequalität – keine Rohdaten.
-
🚪Klar benannte Grenzen Was ist nicht enthalten: Projekte, Herstellersupport, Einsätze außerhalb der Servicezeiten. Seriöse SLAs versprechen nicht alles – sie grenzen sauber ab.
Reaktionszeit ist nicht gleich Lösungszeit
Einer der häufigsten Irrtümer beim Lesen eines SLA: Viele Unternehmen lesen eine kurze Reaktionszeit und gehen davon aus, dass damit auch die Störung schnell behoben ist.
⚡ Reaktionszeit
Wann der Dienstleister nach Eingang einer Meldung aktiv wird – Ticketannahme, erste Analyse oder Rückmeldung an den Kunden. Diese Zeit lässt sich verbindlich zusagen und messen.
✅ Lösungszeit
Wann das Problem tatsächlich behoben oder in einen akzeptablen Betriebszustand überführt wird. Bei komplexen Systemen, Herstellerabhängigkeiten oder Sicherheitsvorfällen hängt sie von mehreren Faktoren ab.
Garantierte Reaktionszeiten, klare Eskalationswege und realistische Zielwerte für die Behebung – je nach Prioritätsstufe des Incidents unterschiedlich geregelt.
Prioritäten und typische Reaktionszeiten
Ein SLA sollte sauber definieren, wann ein Incident als kritisch, hoch, mittel oder niedrig eingestuft wird. Typische Beispiele aus der Praxis:
| Priorität | Beispiel | Reaktionszeit | Ziel Behebung |
|---|---|---|---|
| Kritisch P1 | Firewall-Ausfall, kompletter Serverausfall, Sicherheitsvorfall | ≤ 1 Stunde | 4 Stunden |
| Hoch P2 | Microsoft 365 nicht erreichbar, Telefonanlage ausgefallen | ≤ 2 Stunden | 8 Stunden |
| Mittel P3 | Einzelner Arbeitsplatz gestört, Druckerprobleme Hauptbüro | ≤ 4 Stunden | Nächster Werktag |
| Niedrig P4 | Allgemeine Anfragen, Benutzeranpassungen, Nebendrucker | ≤ 1 Werktag | 3 Werktage |
Verfügbarkeit sinnvoll einordnen
Verfügbarkeitsangaben klingen auf dem Papier ähnlich – im Alltag bedeuten sie sehr unterschiedliche Ausfallzeiten pro Jahr:
Gilt die Verfügbarkeit rund um die Uhr oder nur innerhalb der Servicezeiten? Sind Wartungsfenster und Providerausfälle herausgerechnet? Entscheidend ist nicht die Zahl allein, sondern wie sie ermittelt wird.
SLA-Beratung anfragen
Wir helfen Ihnen, ein SLA zu entwickeln, das zu Ihrer IT-Umgebung passt – mit realistischen Reaktionszeiten, klaren Prioritäten und echtem Reporting.
Jetzt Beratung anfragen →Typische Schwachstellen in SLAs
Viele SLAs scheitern nicht an mangelnder Absicht, sondern an unklarer Formulierung oder unrealistischen Erwartungen:
Woran ein gutes SLA erkennbar ist
Ein gutes SLA ist verständlich formuliert, passt zum tatsächlichen Geschäftsbetrieb und lässt sich im Alltag anwenden. Qualität zeigt sich oft an Details:
- Feste Ansprechpartner – keine anonyme Hotline
- Systeme werden aktiv überwacht, nicht nur auf Zuruf betreut
- Eskalationsstufen sind dokumentiert und bekannt
- Transparente Reports – verständlich für kaufmännische Entscheider
- Regelmäßige Servicegespräche fest vereinbart
- Geschäftskritische Systeme enger geregelt als Peripherie
- Grenzen und Ausschlüsse klar benannt
Ein SLA ist kein Selbstzweck und keine juristische Nebensache. Es ist ein Werkzeug zur Steuerung von Verfügbarkeit, Reaktionsfähigkeit und Verantwortung. Je klarer diese Basis ist, desto ruhiger läuft der Betrieb – und desto besser lässt sich IT als verlässliche Grundlage für weiteres Wachstum nutzen.