Typische SLA-Fehler – und wie man sie vermeidet – Service Level Agreements (SLAs) gelten als Rückgrat professioneller IT-Services, Cloud-Angebote und Managed Services. Dennoch erleben viele Unternehmen, dass genau diese Vereinbarungen im Ernstfall wenig helfen, Konflikte eher verschärfen und selten als praktische Steuerungsinstrumente dienen.
Das liegt selten am Konzept des SLA an sich, sondern fast immer an typischen Fehlern in Definition, Formulierung und Governance. In diesem Artikel lesen Sie, welche Stolperfallen besonders häufig auftreten – und wie Sie SLAs so gestalten, dass sie im Alltag wirklich funktionieren.

Was ist ein SLA – und warum es so oft scheitert
Ein SLA beschreibt, welche Services ein Anbieter in welcher Qualität, zu welchen Zeiten und mit welchen Reaktions- und Lösungsfristen erbringt. Es schafft damit einen gemeinsamen Referenzrahmen für beide Seiten:
- Was wird geliefert?
- Wie gut wird geliefert?
- Wie wird gemessen und berichtet?
- Was passiert, wenn Ziele verfehlt werden?
In der Praxis scheitern SLAs jedoch oft aus drei Gründen:
- Sie werden zu spät erstellt.
Statt das SLA frühzeitig als Teil des Service-Designs zu nutzen, schreiben viele es am Ende „hinterher“, wenn technische und organisatorische Fakten längst feststehen. - Sie sind zu vage oder zu juristisch.
Häufig dominieren Rechtsabteilungen den Text, während operative Teams kaum eingebunden sind. Dadurch klingt das SLA zwar „wasserdicht“, taugt aber kaum als Steuerungsinstrument. - Sie werden nicht gelebt.
Obwohl viel Mühe in die Erstellung fließt, verschwindet das Dokument oft in einem Ordner. Reports werden zwar erzeugt, jedoch nicht ausgewertet, und Review-Meetings finden selten statt.
Damit Sie es besser machen, schauen wir uns die typischen SLA-Fehler im Detail an.
Die häufigsten SLA-Fehler im Überblick
1. Unklare Leistungsbeschreibungen
Einer der größten Klassiker: Der SLA-Text beschreibt den Service nur grob, während operative Details fehlen oder unpräzise bleiben.
Typische Formulierungen:
- „Der Dienst wird hochverfügbar bereitgestellt.“
- „Störungen werden schnell behoben.“
- „Support steht jederzeit zur Verfügung.“
Solche Aussagen klingen auf den ersten Blick überzeugend, aber sie lassen viel Interpretationsspielraum.
Risiken:
- Unterschiedliche Erwartungen zwischen Anbieter und Kunde
- Streit über den „Scope“ des Services
- Schwierigkeiten bei der Abgrenzung von Change vs. Incident
Wie Sie es besser machen:
- Beschreiben Sie den Service konkret (z. B. Funktionsumfang, Plattformen, unterstützte Standorte).
- Definieren Sie klar, was nicht zum Service gehört.
- Arbeiten Sie mit Service-Katalogen und Referenzen auf technische Anhänge, statt alles in einen einzigen Fließtext zu pressen.
2. Fehlende oder ungeeignete KPIs
Ohne passende Kennzahlen bleibt jedes SLA zahnlos. Dennoch werden KPIs oft zu oberflächlich gewählt, weil sie „bekannt“ klingen.
Typische Fehler:
- Nur eine Verfügbarkeitskennzahl (z. B. „99,5 % Uptime“)
- Keine Trennung von Reaktionszeit und Lösungszeit
- Verzicht auf Qualitätskennzahlen (z. B. Erstlösungsquote, Ticket-Qualität)
Konsequenzen:
- Der Service wirkt auf dem Papier gut, obwohl Nutzer stark unzufrieden sind.
- Probleme im Prozess bleiben lange unentdeckt.
- Beide Seiten diskutieren über Einzelfälle, statt faktenbasiert zu steuern.
Besser:
- Kombinieren Sie technische und prozessuale Kennzahlen.
- Definieren Sie wenige, aber aussagekräftige KPIs, die Sie wirklich messen und berichten können.
- Dokumentieren Sie Messmethodik, Messpunkte und Datenquellen explizit.
3. Unrealistische Zielwerte
Viele SLA-Ziele werden politisch statt fachlich festgelegt. Der Kunde fordert „99,99 %“, der Anbieter stimmt widerwillig zu, und beide hoffen auf das Beste.
Anzeichen für unrealistische Ziele:
- Zielwerte orientieren sich an Marketingversprechen statt an der bestehenden Infrastruktur.
- Es gibt keinen Abgleich mit Wartungsfenstern, Release-Zyklen oder Abhängigkeiten.
- Die Organisation verfügt nicht über die Ressourcen, um die Ziele dauerhaft zu erfüllen.
Folgen:
- Dauerhafte Zielverfehlung und permanente Rechtfertigungsrunden
- Frustration auf beiden Seiten
- Umgehung von Regeln, etwa durch kreative Ticket-Klassifikation
Gute Praxis:
- Ziele anhand von historischen Messdaten und Proof-of-Concepts ableiten.
- Stufenmodelle definieren (z. B. Bronze/Silber/Gold), statt eine starre Linie festzulegen.
- Klare Roadmaps vereinbaren, wie sich Zielwerte Schritt für Schritt erhöhen lassen.
4. Grauzonen bei Rollen und Verantwortlichkeiten
Ein SLA beschreibt nicht nur Zahlen, sondern auch, wer was tut. Trotzdem bleiben Schnittstellen zwischen Kunde, Provider und Drittanbietern häufig unklar.
Typische Grauzonen:
- Wer eröffnet kritische Tickets – nur der Kunde oder auch das Monitoring?
- Wer priorisiert Tickets, wenn mehrere Geschäftsbereiche betroffen sind?
- Wer informiert Endanwender bei größeren Störungen?
Risiken:
- Verzögerte Reaktionen, obwohl „offiziell“ alles eingehalten wird
- Zuständigkeitsdiskussionen im Störungsfall
- Schattenprozesse, die am SLA vorbei entstehen
Vermeidung:
- RACI-Matrizen (Responsible, Accountable, Consulted, Informed) nutzen.
- Übergabepunkte und Eskalationsstufen klar definieren.
- Kommunikationswege (z. B. Hotline, Portal, E-Mail) verbindlich festhalten.
5. Vernachlässigte Schnittstellen und Abhängigkeiten
Moderne Services hängen selten nur von einem System oder einem Anbieter ab. Trotzdem ignorieren viele SLAs diese Abhängigkeiten oder behandeln sie nur am Rand.
Typische Versäumnisse:
- Externe Provider (z. B. Netzwerk, Hosting, SaaS-Komponenten) werden nicht berücksichtigt.
- Interne Teams (z. B. Fachbereiche, Security, Change Management) fehlen in der Betrachtung.
- Komplexe Prozessketten werden nicht durchgängig beschrieben.
Konsequenz:
Der Gesamtservice versagt, obwohl jeder Teilbereich „sein“ SLA einhält.
Besser:
- End-to-End-Sicht einnehmen und die kritischen Pfade identifizieren.
- Abhängigkeiten offenlegen und in einer Service-Architektur dokumentieren.
- Übergeordnete Business-SLAs definieren, die sich aus mehreren technischen SLAs zusammensetzen.
6. Keine klaren Regelungen für Ausnahmen und Changes
Services verändern sich, und Ausnahmefälle gehören zum Alltag. Trotzdem fehlen in vielen SLAs belastbare Regelungen dazu.
Typische Lücken:
- Wartungsfenster sind nur grob umrissen oder völlig offen.
- Notfallmaßnahmen werden nicht sauber beschrieben.
- Änderungen am Service (z. B. Funktionsumfang) sind vertraglich nicht mit dem SLA verknüpft.
Folgen:
- Diskussionen darüber, ob ein Ausfall „geplant“ war oder nicht
- Unklare Lage bei Sicherheitsvorfällen und Major Incidents
- SLA-Ziele verlieren ihre Verbindlichkeit, weil jede Seite Ausnahmen anders auslegt
Empfehlung:
- Wartungsfenster mit Zeitfenstern, Häufigkeit und Ankündigungsfristen definieren.
- Prozesse für Major Incidents und Security Incidents im SLA oder in Anhängen ausformulieren.
- Einen formalen Change-Prozess festlegen, der SLA-Anpassungen explizit vorsieht.
7. Sanktionen ohne Anreize
Viele SLAs konzentrieren sich stark auf Vertragsstrafen, Gutschriften oder Kündigungsrechte. Dadurch entsteht schnell ein rein strafender Charakter, statt eine Partnerschaft auf Augenhöhe.
Probleme bei einseitigen Sanktionen:
- Der Provider optimiert nur auf das Minimieren von Strafzahlungen.
- Innovationen und Verbesserungen geraten in den Hintergrund.
- Die Beziehung verlagert sich von der Zusammenarbeit hin zur reinen Vertragsverwaltung.
Besser ist eine ausgewogene Struktur:
- Malus-Regelungen für wiederholte oder grobe Zielverfehlungen
- Bonus-Regelungen oder variable Vergütung für übertroffene Serviceziele
- Gemeinsame Continuous-Improvement-Ziele, die nicht sofort monetär sanktioniert werden
8. SLA ohne Business-Bezug
Ein SLA, das sich nur auf Technik konzentriert, verfehlt sein eigentliches Ziel. Der Service soll schließlich ein Geschäftsmodell unterstützen, nicht nur Server betreiben.
Typische Anzeichen:
- Fokus auf CPU-Auslastung, Storage oder Netzwerk-Latenz, während Geschäftsprozesse kaum erwähnt werden.
- Keine Priorisierung von Services nach Business-Kritikalität.
- Fehlende Verknüpfung zu KPIs aus Vertrieb, Produktion oder Kundenservice.
Risiko:
IT und Business sprechen aneinander vorbei, obwohl beide „gute Arbeit“ leisten.
Besser:
- Services entlang von Business-Prozessen definieren (z. B. „Bestellabwicklung“, „Filial-POS“).
- Kritikalitätsklassen (z. B. A/B/C) einführen, aus denen sich SLAs ableiten.
- SLA-Reports mit geschäftsrelevanten Kennzahlen anreichern (z. B. Ausfallkosten pro Stunde).
9. Einmal erstellt, nie wieder aktualisiert
Viele SLAs altern schlecht. Sie bleiben jahrelang unverändert, während sich Technologien, Prozesse und Geschäftsanforderungen massiv verändern.
Folgen:
- SLAs spiegeln den realen Service nicht mehr wider.
- KPIs passen nicht mehr zu heutigen Anforderungen oder technischen Möglichkeiten.
- Diskussionen über Zielerreichung werden zunehmend theoretisch.
Vermeidung:
- Regelmäßige Review-Zyklen festschreiben (z. B. halbjährlich oder jährlich).
- In jedem Review technische Änderungen, Business-Anforderungen und Erfahrungswerte aus Incidents berücksichtigen.
- Gemeinsame Roadmaps definieren, die SLA-Weiterentwicklung fest einplanen.
10. Zu juristisch – zu wenig operativ
SLAs müssen rechtlich belastbar sein, allerdings brauchen sie ebenso einen starken operativen Kern. Wenn Juristen allein den Ton angeben, entsteht oft ein schwer verständliches, abstraktes Dokument.
Typische Symptome:
- Lange, verschachtelte Sätze mit vielen Verweisen
- Kaum Beispiele oder konkrete Szenarien
- Fehlende Anhänge mit klaren Checklisten oder Prozessbeschreibungen
Risiken:
- Operative Teams ignorieren das SLA oder verstehen es nur teilweise.
- Missverständnisse im Alltag, obwohl der Vertrag „sauber“ formuliert ist.
- Hohe Abhängigkeit von Einzelpersonen, die das SLA interpretieren.
Lösung:
- SLA-Erstellung als interdisziplinäres Projekt angehen (Fachbereich, IT, Operations, Legal).
- Juristisch saubere Rahmentexte mit operativen Anhängen kombinieren.
- Wo immer möglich mit Beispielen, Flussdiagrammen und Tabellen arbeiten.
Wie Sie typische SLA-Fehler systematisch vermeiden
Statt nur an einzelnen Formulierungen zu feilen, sollten Sie einen strukturierten Ansatz wählen. Dadurch sinkt das Risiko, dass wesentliche Aspekte übersehen werden.
1. Vorbereitung: Ziele und Scope klären
Bevor der erste Satz geschrieben wird, sollten Sie beantworten:
- Welche geschäftlichen Ziele soll der Service unterstützen?
- Welche Prozesse hängen daran?
- Welche Nutzergruppen sind betroffen?
- Wie kritisch ist der Service für das Tagesgeschäft?
Aus diesen Antworten leiten Sie Scope, Kritikalität und Prioritäten ab. Erst danach gehen Sie in die technische Tiefe.
2. Stakeholder einbinden
Ein gutes SLA entsteht nie im stillen Kämmerlein. Binden Sie deshalb früh:
- Fachbereiche / Business-Owner
- IT-Operations und Service-Desk
- Informationssicherheit / Compliance
- Einkauf und Rechtsabteilung
- Gegebenenfalls zentrale Provider-Manager
Nutzen Sie Workshops, um Erwartungen zu sammeln, Annahmen zu hinterfragen und gemeinsame Definitionen zu entwickeln.
3. KPIs gezielt auswählen
Starten Sie nicht mit einer langen Liste potenzieller Kennzahlen, sondern mit der Frage:
„Woran erkennen wir, dass der Service seinen Zweck erfüllt?“
Dann leiten Sie Kennzahlen ab, etwa:
- Verfügbarkeit (z. B. pro Monat, pro Service-Komponente)
- Reaktionszeit (Zeit bis zur Bearbeitung)
- Lösungszeit (Zeit bis zur Entstörung)
- Qualität (Erstlösungsquote, Ticket-Qualität, Nutzerzufriedenheit)
- Stabilität (Anzahl Major Incidents, Wiederholungsstörungen)
Achten Sie darauf, dass alle Kennzahlen:
- Messbar sind
- Technisch umsetzbar sind
- Verstanden werden
- Regelmäßig berichtet werden
4. Messbarkeit und Reporting definieren
Ein KPI ist nur so gut wie seine Messung. Deshalb sollten Sie im SLA festhalten:
- Messmethodik (z. B. Monitoring-Tool, Ticket-System, Umfragen)
- Messzeitraum (monatlich, quartalsweise, rollierende 3 Monate)
- Reporting-Formate (Dashboards, PDF-Reports, Präsentationen)
- Adressaten (Management, operative Teams, Steuerungsgremien)
- Review-Termine (z. B. monatliches Service-Review, quartalsweises Strategiemeeting)
Je klarer diese Punkte beschrieben sind, desto weniger Raum bleibt später für Diskussionen über Zahlen.
5. Struktur und Lesbarkeit des SLA
Eine klare Struktur erleichtert sowohl Erstellung als auch Nutzung. Bewährt hat sich etwa:
- Management Summary
- Geltungsbereich und Begriffe
- Servicebeschreibung
- Servicezeiten und Erreichbarkeit
- KPIs, Zielwerte und Messung
- Incident- und Problem-Management
- Change-, Release- und Wartungsprozesse
- Sanktionen, Anreize und Eskalationen
- Schnittstellen und Abhängigkeiten
- Governance, Reporting und Review-Zyklen
- Anhänge (Service-Kataloge, RACI-Matrizen, technische Details)
Halten Sie den Hauptteil bewusst kompakt, während Sie operative Details in Anhänge auslagern. So bleibt das Dokument auch bei Änderungen beherrschbar.
6. Betrieb und kontinuierliche Verbesserung
Ein SLA entfaltet seine Wirkung erst im Alltag. Daher brauchen Sie neben dem Papiervertrag:
- Regelmäßige Service-Review-Meetings, in denen Kennzahlen und Vorfälle besprochen werden
- Gemeinsame Maßnahmenpläne, um Schwachstellen gezielt zu adressieren
- Einen Change-Mechanismus, mit dem KPIs und Zielwerte angepasst werden können
- Einen klaren Prozess für SLA-Verletzungen inklusive Root-Cause-Analysen
Wenn beide Seiten das SLA als lebendes Steuerungsinstrument verstehen, entsteht eine echte Partnerschaft, statt einer reinen Vertragsbeziehung.
Beispiel: Elemente eines „gesunden“ SLA
Zur Orientierung finden Sie hier einige Formulierungsansätze, die Sie an Ihre Situation anpassen können:
- Servicezeiten:
„Der Service ‚Kundenportal‘ steht an 365 Tagen im Jahr von 06:00–23:00 Uhr MEZ für Endkunden zur Verfügung.“ - Verfügbarkeit:
„Die monatliche Serviceverfügbarkeit beträgt mindestens 99,5 % im definierten Servicezeitfenster, exklusive genehmigter Wartungsfenster.“ - Reaktions- und Lösungszeit:
„Für Störungen der Priorität 1 (Service vollständig ausgefallen) beginnt die Bearbeitung innerhalb von 15 Minuten, und der Service wird in der Regel innerhalb von 4 Stunden wiederhergestellt.“ - Wartungsfenster:
„Regelmäßige Wartungen finden sonntags zwischen 00:00 und 04:00 Uhr statt. Geplante Unterbrechungen, die länger als 30 Minuten dauern, werden mindestens 5 Werktage im Voraus angekündigt.“ - Reporting:
„Die Service-Performance wird monatlich in einem schriftlichen Bericht zusammengefasst und im Rahmen eines gemeinsamen Review-Meetings analysiert.“
Solche klaren und zugleich konkreten Aussagen reduzieren Missverständnisse deutlich und erleichtern tägliche Entscheidungen.
Checkliste: Vor der Unterschrift eines SLA
Bevor Sie ein SLA final freigeben, sollten Sie sich folgende Fragen stellen:
- Sind Serviceumfang und Ausschlüsse eindeutig beschrieben?
- Existieren KPIs, die sowohl Technik als auch Business-Perspektive abdecken?
- Sind alle Kennzahlen messbar und technisch umsetzbar?
- Sind Rollen, Verantwortlichkeiten und Eskalationswege klar zugeordnet?
- Wurden Schnittstellen, Drittanbieter und Abhängigkeiten berücksichtigt?
- Gibt es einen klaren Change- und Review-Prozess für das SLA?
- Sind Sanktionen und Anreize ausgewogen gestaltet?
- Haben alle relevanten Stakeholder das Dokument tatsächlich gelesen und verstanden?
Wenn Sie diese Fragen solide beantworten können, haben Sie einen wichtigen Schritt hin zu belastbaren, praxistauglichen SLAs gemacht.
Fazit Typische SLA-Fehler – und wie man sie vermeidet: Gute SLAs schaffen Vertrauen statt Streit
Ein gut gemachtes SLA ist mehr als eine Versicherung gegen den Ernstfall. Es bildet die Grundlage für eine professionelle, transparente und langfristig tragfähige Zusammenarbeit.
Indem Sie typische SLA-Fehler gezielt vermeiden, erhöhen Sie nicht nur die Servicequalität, sondern stärken auch das Vertrauen zwischen Kunde und Anbieter. Wo Erwartungen klar, Ziele realistisch und Prozesse sauber beschrieben sind, entstehen weniger Konflikte – und deutlich mehr Raum für gemeinsame Weiterentwicklung.