Service Level Agreement (SLA) – Bedingungen
Dieses Dokument beschreibt Erreichbarkeit, Reaktionszeiten und die bevorzugte Bearbeitung im Rahmen der
gebuchten SLA-Level für IT-Services. Es ist bewusst klar und praxisnah gehalten – damit beide Seiten wissen,
was erwartet werden kann.
Hinweis: Das SLA ist eine Leistungszusage (Erreichbarkeit/Reaktionszeit/Bevorzugung),
aber keine Garantie für eine sofortige Lösung in jedem Fall. Ziel ist eine verlässliche, planbare Zusammenarbeit.
1. Begriffe & Definitionen
- Ticket: Dokumentierter Vorgang im Ticketsystem (Störung/Anfrage/Änderung).
- Reaktionszeit: Zeitraum zwischen Ticket-Eingang (korrekt übermittelt) und erster qualifizierter Rückmeldung/Arbeitsaufnahme durch den Dienstleister.
- Ziel-Lösungszeit: Angestrebter Zeitraum bis zur Wiederherstellung des Service oder Bereitstellung einer tragfähigen Lösung/Workaround. Abhängig von Komplexität, Drittanbietern, Verfügbarkeit.
- Servicezeit: Zeitraum, in dem Erreichbarkeit und SLA-Zeiten gelten (je nach SLA-Level).
- Workaround: Übergangslösung zur Aufrechterhaltung des Betriebs, bis die endgültige Lösung umgesetzt ist.
- Drittanbieter: Hersteller/Provider (z.B. Microsoft, Internetprovider, Hosting, Hardware-Hersteller). Deren Reaktionszeiten liegen außerhalb der direkten Steuerung.
2. Leistungsumfang & Kanäle
Das SLA gilt für die im Wartungsvertrag bzw. Leistungspaket enthaltenen IT-Services (z.B. Helpdesk, Remote-Support,
Microsoft 365 Administration, Monitoring, Backup-Management, Security-Basispaket, Netzwerk/Firewall-Betreuung),
soweit diese aktiv beauftragt und technisch angebunden sind.
Zulässige Kontaktkanäle (SLA-relevant)
- Ticketsystem / E-Mail (empfohlen): Vollständige Dokumentation, beste Nachverfolgbarkeit.
- Telefon: Für dringende Störungen; anschließend Ticket-Erstellung durch Dienstleister oder Kunde.
- Remote-Session: Nach Freigabe durch den Kunden oder per verwalteter Remote-Lösung.
Für eine SLA-konforme Bearbeitung muss ein Ticket mindestens enthalten: betroffener Service, kurze Fehlerbeschreibung,
Dringlichkeit/Impact, Rückrufnummer, ggf. Screenshots/Fehlermeldungen.
3. Prioritäten & Klassifizierung
Um fair und effizient zu arbeiten, werden Tickets nach Auswirkung (Impact) und Dringlichkeit (Urgency)
in Prioritäten eingestuft. Die Einstufung erfolgt gemeinsam: Kundenangabe als Orientierung, finale Priorität durch den Dienstleister
(transparent begründet).
| Priorität |
Beispiel |
Definition |
| P1 Kritisch |
Totalsystemausfall, zentrale Server/Internet down, produktionskritischer Dienst steht |
Geschäftsbetrieb erheblich beeinträchtigt oder steht still; kein zumutbarer Workaround |
| P2 Hoch |
Viele Nutzer betroffen, zentrale Funktion eingeschränkt, Security-Vorfall mit hohem Risiko |
Wesentliche Einschränkung; Workaround möglich, aber mit deutlichem Mehraufwand |
| P3 Mittel |
Einzelner Nutzer betroffen, Drucker/Client-Probleme, nicht-kritische App-Störung |
Begrenzte Auswirkung; Betrieb läuft weiter |
| P4 Niedrig |
How-to Fragen, kleine Änderungen, allgemeine Beratung, Terminwünsche |
Keine oder geringe Beeinträchtigung; planbar |
Wichtig: Security-relevante Tickets können unabhängig von der ursprünglichen Einstufung hochgestuft werden
(z.B. Verdacht auf kompromittiertes Konto, Malware, ungewöhnliche Anmeldeaktivität).
4. Servicezeiten & SLA-Level
Die SLA-Level definieren Erreichbarkeit und beschleunigte Bearbeitung innerhalb der jeweiligen Servicezeit.
Außerhalb der Servicezeit werden Tickets entgegengenommen und zum nächsten Servicezeitfenster bearbeitet (sofern kein höheres SLA gilt).
| SLA Level |
Servicezeit |
Typischer Einsatz |
| Level 1 (5×8) |
Montag–Freitag, 8 Stunden/Tag (z.B. 09:00–17:00, außer Feiertage) |
Klassische Bürozeiten, Standard-IT |
| Level 2 (7×8) |
Montag–Sonntag, 8 Stunden/Tag (z.B. 09:00–17:00) |
Betrieb auch am Wochenende (z.B. Gastro/Events) |
| Level 3 (5×24) |
Montag–Freitag, 24 Stunden/Tag |
Unter der Woche durchgehender Betrieb |
| Level 4 (7×24) |
24/7 – Montag–Sonntag, inkl. Wochenenden |
Kritische Systeme, hohe Verfügbarkeit |
Servicezeiten können im Vertrag konkretisiert werden (z.B. 08:00–16:00). Gesetzliche Feiertage gelten nach Sitz des Kunden,
sofern nicht anders vereinbart.
5. Reaktions- & Zielzeiten
Die folgenden Zeiten sind Zielwerte und gelten innerhalb der Servicezeit des gebuchten SLA-Levels.
Bei Tickets außerhalb der Servicezeit beginnt die Reaktionszeit mit dem nächsten Servicezeitfenster.
| Priorität |
Ziel-Reaktionszeit |
Ziel-Lösungsansatz |
| P1 |
≤ 60 Minuten |
sofortige Arbeitsaufnahme, Fokus auf Wiederherstellung/Workaround |
| P2 |
≤ 4 Stunden |
zeitnahe Analyse und priorisierte Bearbeitung |
| P3 |
≤ 1 Werktag |
Bearbeitung im regulären Ticketfluss |
| P4 |
≤ 3 Werktage |
Terminierung/Planung nach Aufwand und Verfügbarkeit |
Beschleunigte Bearbeitung (SLA-Feature)
- Tickets mit SLA werden im jeweiligen Servicezeitfenster vorrangig behandelt.
- Bei mehreren SLA-Tickets gilt Priorität P1 vor P2 vor P3 vor P4.
- Aufwände für Umsetzung/Changes/Projekte sind nicht automatisch inkludiert – es gilt das beauftragte Leistungspaket.
Realistisch und fair: Manche Ursachen liegen außerhalb unserer direkten Kontrolle (Provider-Störung, Hersteller-Bug,
defekte Hardware, Wartezeiten auf Freigaben). In solchen Fällen bleibt die Kommunikation proaktiv, aber die Ziel-Lösungszeit kann abweichen.
6. Ausnahmen & Ausschlüsse
SLA-Zeiten gelten nicht bzw. nur eingeschränkt bei:
- Drittanbieter-Abhängigkeiten (z.B. Provider, Cloud-Anbieter, Hersteller-Support).
- Geplanten Wartungsfenstern (vorab angekündigt), sofern notwendig.
- Höherer Gewalt (z.B. flächendeckende Strom-/Netzausfälle, Naturereignisse, behördliche Anordnungen).
- Nichteinhaltung von Mitwirkungspflichten (z.B. kein Zugriff, fehlende Freigaben, ausstehende Rückfragen).
- Unautorisierte Änderungen am System durch Dritte ohne Abstimmung, die Störungen verursachen.
- Alt-/Sonderumgebungen, die nicht dokumentiert/übergeben wurden oder Sicherheitsanforderungen nicht erfüllen.
Vor-Ort-Einsätze
Reaktionszeiten beziehen sich primär auf Remote-Bearbeitung. Vor-Ort-Termine erfolgen nach Verfügbarkeit,
Dringlichkeit und ggf. gebuchtem Vor-Ort-Kontingent. Bei P1 kann Vor-Ort sinnvoll sein, ist aber nicht immer schneller als Remote.
7. Mitwirkungspflichten des Kunden
Damit wir SLA-Zeiten zuverlässig halten können, braucht es ein paar praktische Grundlagen:
- Bereitstellung von aktuellen Kontaktdaten und mindestens eines erreichbaren Ansprechpartners.
- Freigaben (Remote-Zugriff, Admin-Rechte, MFA-Bestätigungen) zeitnah ermöglichen.
- Störungen möglichst mit konkreten Angaben melden (wer/was/wann/seit wann/Fehlermeldung).
- Bei Security-Vorfällen: sofortige Rückmeldung, ggf. Systeme isolieren nach Anleitung.
- Regelmäßige Pflege von Benutzer-/Lizenzänderungen, sofern nicht ausdrücklich im Paket enthalten.
Fairness-Prinzip: Wir behandeln Tickets schnell – im Gegenzug hilft eine schnelle Rückmeldung enorm,
um Ping-Pong zu vermeiden und die Lösung zu beschleunigen.
8. Sicherheit, Zugriff & Datenschutz
- Zugriffe erfolgen nach dem Prinzip „so viel wie nötig, so wenig wie möglich“ (Least Privilege).
- Remote-Zugriffe werden, soweit möglich, protokolliert.
- Passwörter werden nicht per E-Mail angefordert; bevorzugt sichere Übergabe (Passwortmanager/temporäre Tokens).
- Datenschutz/DSGVO: Verarbeitung personenbezogener Daten nur im Rahmen der Beauftragung; AVV nach Bedarf.
Security-Notfälle
Bei Verdacht auf kompromittierte Accounts/Malware kann es notwendig sein, kurzfristig Maßnahmen zu ergreifen
(z.B. Passwort-Reset, MFA-Reset, Konto-Sperrung, Quarantäne). Ziel ist Schadenbegrenzung – wir kommunizieren jeden Schritt transparent.
9. Eskalation & Kommunikation
Wenn sich eine Störung nicht wie erwartet entwickelt, eskalieren wir strukturiert – ohne Drama, aber mit Tempo.
- Operativ: Techniker/Support → Analyse/Workaround → Update im Ticket.
- Team-/Lead-Eskalation: Bei Blockern, komplexen Ursachen oder hohem Impact.
- Management-Eskalation: Bei länger andauernden P1/P2 oder relevanten Business-Risiken.
Update-Frequenz (Richtwert)
- P1: regelmäßige Statusupdates, typischerweise alle 60–120 Minuten (oder nach Meilensteinen).
- P2: Updates nach Fortschritt/Meilensteinen, typischerweise mindestens täglich innerhalb der Servicezeit.
- P3/P4: Updates nach Bearbeitungsschritten oder Terminabstimmung.
10. Reporting & Review
- Auf Wunsch liefern wir monatliche/vierteljährliche Übersichten: Ticketvolumen, Top-Themen, Reaktionszeiten, Empfehlungen.
- Regelmäßige Reviews helfen, wiederkehrende Störungen dauerhaft zu reduzieren (Root Cause statt Symptombehandlung).
Reporting-Umfang richtet sich nach dem gebuchten Paket und der Dokumentations-/Monitoring-Anbindung.
11. Servicegutschriften (optional)
Servicegutschriften sind optional und können im Vertrag aktiviert werden. Ohne ausdrückliche Vereinbarung besteht kein Anspruch.
Vorschlag (Beispielregel)
- Wenn die Ziel-Reaktionszeit in einem Monat bei P1 in mehr als 2 Fällen ohne berechtigte Ausnahme überschritten wird,
kann eine Gutschrift von 5% auf den SLA-Monatsbetrag gewährt werden.
- Maximale Gutschrift pro Monat: 10% des SLA-Monatsbetrags.
- Ausnahmen siehe Abschnitt 6 (Drittanbieter, fehlende Mitwirkung, höhere Gewalt, Wartungsfenster).
Empfehlung: Statt „Strafzahlungen“ setzen viele Kunden lieber auf Review/Optimierung (Monitoring, Patch, Backup, Security-Hardening),
weil das die Ausfälle nachhaltig reduziert.
12. Schlussbestimmungen
- Dieses SLA ist Bestandteil des Wartungsvertrags/Leistungspakets und gilt ergänzend zu dessen Regelungen.
- Bei Widersprüchen gilt die Rangfolge: individueller Vertrag → Angebot/Leistungsbeschreibung → dieses SLA.
- Änderungen dieses SLA bedürfen der Textform (z.B. E-Mail) oder einer aktualisierten Version mit Versionsstand.
Mini-Zusammenfassung: Wir reagieren innerhalb der gebuchten Servicezeiten schneller und priorisiert,
kommunizieren transparent und arbeiten lösungsorientiert – mit klaren Ausnahmen, damit es für beide Seiten fair bleibt.