SLA vs OLA: Der Unterschied, der Ihr Servicemanagement trägt

Das SLA ist das externe Leistungsversprechen an Ihren Kunden. Das OLA ist die interne Vereinbarung, die dieses Versprechen erst möglich macht. Wer beide verwechselt oder eines davon einfach weglässt, baut ein Servicemanagement, das auf dem Papier gut aussieht und in der Praxis bei der ersten Störung zusammenbricht. Der Unterschied zwischen SLA und OLA liegt also nicht in der Bürokratie, sondern in der Frage: Wer schuldet wem was, und wie wird das intern eingelöst?

Kurz gesagt:

Ein SLA ist rechtsverbindlich und nach außen gerichtet, während ein OLA eine interne, meist informelle Vereinbarung ohne juristische Wirkung ist.

OLAs legen Verantwortlichkeiten, Übergabepunkte und Eskalationswege fest, um die Erfüllung des SLA im Unternehmen sicherzustellen.

Beim Outsourcing sind klare interne OLAs ebenso wichtig wie das SLA, um die Einhaltung der Kundenversprechen zu garantieren.

Die Zusammenarbeit von SLA, OLA, SLO und UC sorgt für eine abgestimmte, zuverlässige Serviceerbringung und erleichtert die Identifikation von Verbesserungsbedarf.

Ein gut formuliertes OLA basiert auf konkreten Verantwortlichkeiten, festen Zeiten und regelmäßigen Überprüfungen, um die operative Umsetzung zu sichern.

Sla vs Ola: Was Genau Ist Ein Service Level Agreement?

Ein Service Level Agreement ist die formale, nach außen gerichtete Vereinbarung zwischen einem Dienstleister und seinem Kunden. Es beschreibt, welche Leistung erwartet werden darf, in welcher Qualität und mit welchen Konsequenzen bei Nichterfüllung. SLAs regeln Umfang, Verfügbarkeit, Reaktions- und Lösungszeiten sowie Sanktionen bei Nichterfüllung und sind damit das rechtlich relevante Dokument in der Kundenbeziehung.

Ein SLA besteht aus wenigen, aber entscheidenden Bausteinen:

Geltungsbereich (Scope): Welche Services, Standorte oder Systeme sind eingeschlossen, welche ausdrücklich nicht?
Messbare Kennzahlen: Verfügbarkeit in Prozent, Reaktionszeit nach Priorität, Lösungszeit, oft auch Kundenzufriedenheit (CSAT).
Ausnahmen: Wartungsfenster, Force-Majeure-Klauseln, Drittanbieter-Ausfälle.
Sanktionen: Gutschriften, Vertragsstrafen oder Kündigungsrechte bei wiederholter Verletzung.

Ob ein SLA rechtsverbindlich ist, hängt vom Vertragstyp ab. In vielen Outsourcing-Verträgen ist das SLA fester Bestandteil des Hauptvertrags und damit einklagbar. Bei internen Rahmenwerken ohne separate Vertragsunterschrift bleibt es oft eine Absichtserklärung. Typische Metriken sehen oft hohe Verfügbarkeitswerte im Monat vor sowie schnelle Erstreaktions- und Lösungszeiten bei kritischen Prioritäten. Diese Zahlen wirken auf den ersten Blick technisch, entscheiden aber über Vertragsstrafen und am Ende über die Kundenbindung. Wie stark solche Strafen ausfallen können, zeigt ein Blick auf typische SLA-Vertragsstrafen im Callcenter.

Was Ist Ein Operational Level Agreement?

Ein Operational Level Agreement regelt, was intern passieren muss, damit das nach außen gegebene Versprechen überhaupt eingehalten werden kann. Es richtet sich nicht an den Kunden, sondern an Teams, Abteilungen oder einzelne Rollen im eigenen Haus. OLAs legen Rollen, Übergabepunkte, Kommunikationswege und interne Bearbeitungsziele fest, damit SLAs erreichbar bleiben.

Ein gut geschriebenes OLA enthält typischerweise:

Klare Rollen: Wer ist für welchen Schritt im Prozess verantwortlich, wer entscheidet bei Eskalationen?
Übergabepunkte: Wann genau geht ein Ticket vom First-Level-Support an das Second-Level-Team über?
Interne Reaktionsziele: Zeitfenster, die enger sind als das externe SLA, damit ein Puffer bleibt.
Eskalationspfade: Wer wird informiert, wenn eine Frist zu kippen droht?

Der wichtigste Unterschied zum SLA liegt in der Durchsetzbarkeit. OLAs sind normalerweise nicht rechtlich bindend, sie dienen der internen Koordination, nicht der juristischen Absicherung. Das macht sie nicht unwichtig, im Gegenteil: Ein OLA ist der eigentliche Motor, der das SLA am Laufen hält, nur eben ohne Gerichtsvollzieher im Hintergrund. Genau deshalb scheitert so mancher Betrieb daran, OLAs überhaupt schriftlich zu fixieren, weil diese „ja eh keine Konsequenzen haben“. Das ist ein Trugschluss, den Sie sich nicht leisten sollten.

Sla Vs Ola: Die Wichtigsten Unterschiede Im Überblick

Der direkte Vergleich zeigt, warum beide Vereinbarungen nebeneinander existieren müssen und keine die andere ersetzen kann.

Adressat: Ein SLA richtet sich an den Kunden, ein OLA an interne Teams oder Abteilungen.
Rechtswirkung: SLAs sind häufig Vertragsbestandteil und einklagbar, OLAs bleiben interne Absprachen ohne juristische Bindung.
Messgrößen: SLAs messen kundenrelevante Ergebnisse wie Verfügbarkeit oder Gesamtlösungszeit, OLAs messen interne Teilschritte wie Reaktionszeit einer bestimmten Abteilung.
Sichtbarkeit: Das SLA ist öffentlich, oder zumindest vertraglich bekannt. Das OLA bleibt intern und wird dem Kunden normalerweise nicht gezeigt.
Typische Inhalte: SLAs enthalten Sanktionen und Ausnahmeregelungen, OLAs enthalten Übergabepunkte und Eskalationslogik.

Ein Beispiel macht den Unterschied greifbar. Bei einem P1-Incident, einem kompletten Systemausfall, verspricht das SLA dem Kunden eine Lösung innerhalb von vier Stunden. Das Kundenversprechen bleibt eine Zahl. Die interne Choreografie dahinter besteht aus mehreren kleineren Zahlen, die zusammen die große Zahl ergeben.

Der Anwendungskontext unterscheidet sich ebenfalls deutlich. Beim Outsourcing von Support-Funktionen, etwa an einen externen Callcenter-Partner, wird das SLA zwischen Auftraggeber und Dienstleister verhandelt. Die interne Steuerung beim Dienstleister selbst läuft weiterhin über OLAs, die der Kunde nie zu Gesicht bekommt. Bei rein interner IT ohne Outsourcing verschmelzen SLA und OLA optisch oft, weil derselbe IT-Leiter beide Seiten verantwortet, inhaltlich bleibt die Trennung trotzdem sinnvoll.

Wie Sla, Ola, Slo Und Uc Zusammenwirken

Um SLAs und OLAs richtig einzuordnen, braucht es zwei weitere Begriffe: SLO und UC. Ein Service Level Objective ist ein einzelnes, messbares technisches Ziel, etwa 99,95 % Verfügbarkeit eines bestimmten Servers. Ein Underpinning Contract ist der Vertrag mit einem externen Lieferanten, der eine Teilleistung für Ihr eigenes SLA beisteuert, etwa ein Cloud-Anbieter oder ein Netzwerkprovider. SLA, OLA und UC müssen aufeinander abgestimmt sein, damit das Kundenversprechen tatsächlich haltbar ist.

Die vier Ebenen bauen aufeinander auf:

SLA: Das Versprechen an den Kunden, formuliert als Geschäftsergebnis.
OLA: Die interne Vereinbarung, die dieses Versprechen operationalisiert.
SLO: Das einzelne technische Ziel, das intern gemessen wird, um zu wissen, ob man auf Kurs ist.
UC: Der Vertrag mit externen Zulieferern, deren Leistung Sie selbst nicht kontrollieren, aber vertraglich einfordern können.

In der ServiceNow-Community wird das Zusammenspiel gerne am Beispiel einer Pizza-Lieferung erklärt: Das SLA verspricht dem Kunden eine Pizza in kurzer Lieferzeit. Das OLA regelt, dass der Koch und der Fahrer jeweils bestimmte interne Zeitfenster für ihre Aufgaben haben. Der UC ist der Vertrag mit dem Käselieferanten, der garantieren muss, pünktlich zu liefern, sonst reißt die ganze Kette. Übertragen auf IT: Ein Kunde meldet einen kritischen Ausfall um 09:00 Uhr. Das SLA verspricht Lösung bis 13:00 Uhr. Läuft die Ursache auf einen Cloud-Anbieter zurück, greift der UC mit diesem Anbieter, der seinerseits bis 11:30 Uhr reagieren muss, damit am Ende noch Puffer bis 13:00 Uhr bleibt.

Profi-Tipp: Setzen Sie SLOs immer enger an als das eigentliche SLA. Wenn der Kunde vier Stunden erwartet, sollte Ihr internes Ziel bei drei Stunden liegen. Der Puffer ist kein Luxus, er ist die einzige Reserve, die Sie haben, wenn ein UC-Partner mal nicht liefert.

SLA, SLO und UC mit zeitlichem Spielraum

So Formulieren Sie Ein OLA, Das Ihr SLA Trägt

Ein OLA, das nur aus guten Absichten besteht, hilft niemandem. Es braucht konkrete Formulierungen, Verantwortliche und einen festen Rhythmus zur Überprüfung.

Verantwortlichkeiten benennen: Legen Sie namentlich oder rollenbasiert fest, wer für jeden Prozessschritt zuständig ist, nicht „das Team“, sondern „der diensthabende Second-Level-Techniker“.
Zeiten definieren: Setzen Sie für jede Übergabe eine harte Zeitgrenze, formuliert als „Übergabe an Team B innerhalb von 10 Minuten nach Eingang“, nicht als „zeitnah“.
Eskalationspfade festlegen: Bestimmen Sie, wer nach Ablauf einer Frist automatisch informiert wird, etwa der Teamleiter nach 20 Minuten ohne Reaktion.
Reporting einplanen: Definieren Sie, welche Kennzahlen wöchentlich oder monatlich an Business- oder Customer-Success-Verantwortliche gehen.

Konkrete Beispielformulierungen helfen mehr als abstrakte Prinzipien:

„Das Infrastruktur-Team bestätigt den Eingang eines P1-Tickets innerhalb von 5 Minuten.“
„Bei Nichterreichbarkeit des zuständigen Technikers eskaliert das System automatisch an den Bereichsleiter.“
„Der wöchentliche OLA-Bericht enthält durchschnittliche Übergabezeit, Anzahl der Eskalationen und Einhaltungsquote pro Team.“

Der Review-Rhythmus entscheidet darüber, ob ein OLA lebendig bleibt oder nach drei Monaten in der Schublade verstaubt. Ein monatlicher Check gegen die tatsächlichen SLA-Ergebnisse zeigt schnell, ob die internen Zeitfenster realistisch sind oder ob ständig nachjustiert werden muss. Eine gute Eskalationsmatrix im Kundenservice liefert dafür die strukturelle Grundlage, auf der sich OLA-Formulierungen leicht aufbauen lassen.

Welche Fehler Passieren Am Häufigsten Bei SLA Und OLA?

Der häufigste Fehler ist simpel: Ein SLA existiert, aber kein passendes OLA dahinter. Das SLA verspricht dann etwas, das intern niemand konkret einlösen muss, weil keine Rolle, keine Frist und kein Eskalationspfad definiert wurden. Solche Lücken zeigen sich meist erst beim ersten größeren Incident, wenn zwei Abteilungen sich gegenseitig für zuständig halten und wertvolle Minuten verstreichen.

Ein zweiter, oft unterschätzter Fehler: technische SLOs werden ungefiltert als Kunden-SLA kommuniziert. Praktiker warnen davor, weil technische Schwankungen dadurch zum Vertragsrisiko werden, ein kurzer interner Messausschlag wird plötzlich zur vertraglich relevanten Verletzung. Die Lösung ist, SLAs bewusst auf Geschäftsergebnis-Ebene zu formulieren, „System verfügbar“ statt „Antwortzeit des Datenbankservers unter 200 Millisekunden“, und die granularen technischen Ziele als interne SLOs zu behandeln, die nie direkt beim Kunden landen.

Auch bei den Kennzahlen selbst schleichen sich Fehler ein:

Falsche KPI-Wahl: Verfügbarkeit allein sagt wenig, wenn die Reaktionszeit bei kritischen Fällen ignoriert wird.
Fehlende Gewichtung nach Priorität: Ein P1-Fall braucht andere Zielwerte als ein P4-Fall, ein einheitliches SLA für alle Prioritäten verschleiert echte Probleme.
Zu seltenes Reporting: Monatsberichte allein decken akute Fehlentwicklungen zu spät auf.

Profi-Tipp: Prüfen Sie einmal im Quartal, ob Ihre OLA-Zeiten noch zur tatsächlichen Teamgröße passen. Ein OLA, das vor zwei Jahren mit doppelt so vielen Mitarbeitern kalkuliert wurde, ist heute nur noch Wunschdenken auf Papier.

Praxisbeispiel: Wie Ausgelagerter Support SLAs Operational Absichert

Wer Support-Funktionen auslagert, verlagert das SLA-Versprechen nach außen, muss die interne OLA-Logik beim Dienstleister aber genauso ernst nehmen wie im eigenen Haus. Ein Omnichannel-Anbieter bündelt Telefon, E-Mail, Live-Chat und Social-Messaging-Kanäle wie WhatsApp oder Facebook in einer Struktur, die genau diese Übergaben nachvollziehbar macht.

Das funktioniert über mehrere Bausteine, die auch Sie bei einem externen Anbieter einfordern sollten:

Kanalübergreifendes Ticket-Tracking, damit eine Anfrage nicht zwischen Chat und Telefon verloren geht.
Metrikbasierte Steuerung, die Reaktionszeiten pro Kanal und Priorität sichtbar macht statt nur eine Gesamtzahl zu liefern.
Klar definierte interne Eskalationsstufen, die dem Kunden-SLA vorgeschaltet sind.

Wenn Sie Support auslagern, sollten Sie beim Anbieter aktiv nach dessen OLA-Struktur fragen, nicht nur nach dem SLA im Angebot. Ein Dienstleister, der keine belastbare interne Übergabelogik nachweisen kann, wird das versprochene SLA irgendwann reißen, unabhängig davon, wie gut die Vertragszahlen auf dem Papier aussehen.

Warum Interne OLAs Der Eigentliche Hebel Sind

In vielen Projekten liegt der Fokus fast ausschließlich auf dem SLA, weil es das Dokument ist, das Vertriebler unterschreiben lassen und Juristen prüfen. Das OLA bleibt dabei oft eine Fußnote, dabei entscheidet genau dieses Dokument, ob am Ende überhaupt eingehalten wird, was versprochen wurde. Meine Beobachtung aus zahlreichen Servicemanagement-Projekten: Teams, die ihre OLAs in einfachen, klaren Sätzen formulieren, halten SLAs zuverlässiger ein als Teams mit dickeren Vertragswerken.

IT-Leitern, die gerade OLAs einführen, würde ich raten, nicht mit einem juristischen Regelwerk zu starten. Fangen Sie mit drei bis vier kritischen Übergabepunkten an, messen Sie diese vier Wochen lang und passen Sie erst danach die Zeitfenster an die Realität an. Komplexität kommt später von selbst, Klarheit müssen Sie von Anfang an einbauen. Ein OLA ist kein Vertrag, den Sie gewinnen müssen. Es ist eine Verabredung, an die sich Menschen halten wollen, weil sie verstehen, warum sie wichtig ist.

— Markus

Wie Alive Ihre SLA-Erfüllung Praktisch Absichert

Alive ist die Alternative zur reinen Inhouse-Lösung, wenn Ihr Team an der Kanalvielfalt oder an fehlender Reportingtiefe scheitert: statt SLA-Zahlen im Nachhinein zu erklären, liefert ein externer Partner mit fest definierten OLAs die Übergabelogik gleich mit.

Der Anbieter bündelt Telefon, E-Mail, Live-Chat und Social-Messaging-Kanäle in einer gemeinsamen Struktur und macht Reaktionszeiten pro Kanal und Priorität sichtbar, statt sie in einer einzigen Durchschnittszahl zu verstecken. Für Support-Verantwortliche bedeutet das: SLA-Reporting und Eskalationsmanagement liegen nicht mehr verteilt in mehreren Tools, sondern folgen einer nachvollziehbaren internen Logik, die sich direkt mit vertraglichen Zusagen abgleichen lässt. Wer gerade ein SaaS-Tool ohne große IT-Projekte einführen will, findet bei SzopaLabs eine praktische Checkliste zum SaaS-Rollout, die sich gut mit der OLA-Einführung kombinieren lässt.

Wenn Sie prüfen wollen, ob Ihr aktuelles SLA überhaupt durch belastbare interne Prozesse gedeckt ist, lohnt sich ein Blick auf das Leistungsangebot von Alive und ein unverbindliches Gespräch über Ihre konkrete Kanalstruktur.

Quellen

Für eine tiefere Einordnung von SLA, OLA und UC lohnen sich drei Quellen besonders. Der Invgate-Blog zu SLA vs. OLA erklärt die Rechtswirkung beider Vereinbarungen kompakt. Die ServiceNow-Community-Diskussion zu SLA, OLA und UC liefert das anschauliche Pizza-Beispiel. Der Beitrag von PURE Consultant zu SLA, OLA und UC ordnet alle drei Ebenen strukturiert nebeneinander an.

FAQ

Was Ist Der Unterschied Zwischen SLA, OLA Und Underpinning Contract?

Das SLA ist das Versprechen an den Kunden, das OLA die interne Vereinbarung zur Erfüllung dieses Versprechens, und der Underpinning Contract regelt die Leistung externer Zulieferer, die zum SLA beitragen.

Wofür Steht SLA?

SLA steht für Service Level Agreement, eine vereinbarte Definition der erwarteten Servicequalität zwischen Anbieter und Kunde.

Was Bedeuten SLA, OLA Und UC In ServiceNow?

In ServiceNow-Kontexten beschreiben SLA, OLA und UC dieselben drei Ebenen wie im klassischen ITSM: Kundenversprechen, interne Koordination und externe Lieferantenverträge, oft direkt in Ticketing-Workflows abgebildet.

Welche Drei Arten Von SLAs Gibt Es?

Üblich ist die Unterscheidung zwischen kundenbasierten SLAs (für einen einzelnen Kunden), servicebasierten SLAs (für einen bestimmten Service, unabhängig vom Kunden) und mehrstufigen SLAs, die beide Ebenen kombinieren.

Kann Ein Anbieter Wie Alive OLAs Für Mich Übernehmen?

Ja, ein Omnichannel-Anbieter wie Alive kann interne Übergabe- und Eskalationslogik als eigenes OLA-Gerüst führen und Ihnen darüber die Einhaltung des vereinbarten SLA nachvollziehbar berichten.