Deprecated: mb_convert_encoding(): Handling HTML entities via mbstring is deprecated; use htmlspecialchars, htmlentities, or mb_encode_numericentity/mb_decode_numericentity instead in /var/www/vhosts/x-root.de/httpdocs/wp-content/plugins/wp_glossary/includes/class-wpg-linkify.php on line 345
Eine App zu entwickeln ist das eine. Sie zuverlässig zu betreiben, schnell auf Störungen zu reagieren und Ausfälle kalkulierbar zu halten – das ist das andere. Genau hier kommt das Service Level Agreement ins Spiel. Was viele Unternehmen erst nach dem Go-live vermissen, hätte längst vertraglich geregelt sein sollen: klare, messbare Zusagen darüber, wie gut und wie schnell ein Dienstleister seine Leistungen erbringt.
Dieser Artikel erklärt, was ein SLA ist, welche Bestandteile es umfasst und warum es gerade in der App-Entwicklung eine Schlüsselrolle spielt.
Was ist ein SLA?
Ein Service Level Agreement, kurz SLA, auf Deutsch auch Dienstgütevereinbarung – ist eine verbindliche Vereinbarung zwischen einem Dienstleister und seinem Auftraggeber. Es definiert, welche Leistungen in welcher Qualität und innerhalb welcher Zeitrahmen erbracht werden müssen. Der entscheidende Unterschied zu einem gewöhnlichen Vertrag: Ein SLA übersetzt abstrakte Versprechen in konkrete, messbare Kennzahlen.
Statt „wir reagieren schnell auf Probleme“ steht im SLA: „Bei einem kritischen Ausfall (P1) erfolgt die erste Reaktion innerhalb von 60 Minuten.“ Diese Präzision schafft für beide Seiten Klarheit und macht die Servicequalität objektiv überprüfbar.
SLAs sind ursprünglich aus dem Telekommunikations- und Hosting-Umfeld bekannt, sind heute jedoch oft Bestandteil einer IT-Dienstleistung – und damit auch der App-Entwicklung und dem anschließenden App-Betrieb.
Was gehört in ein SLA? Die 6 Kernbestandteile
Ein solides SLA besteht aus mehreren klar definierten Bausteinen. Fehlt einer davon, entstehen Graubereiche. Und genau dort passieren die meisten Missverständnisse zwischen Auftraggeber und Dienstleister.
Verfügbarkeit & Uptime legen fest, wie lange eine App pro Monat oder Jahr betriebsbereit sein muss. Üblich sind Werte wie 99,5 % oder 99,9 %, das klingt ähnlich, ist aber ein erheblicher Unterschied: 99,5 % erlaubt rund 3,6 Stunden Ausfall pro Monat, 99,9 % nur 43 Minuten. Zusätzlich wird geregelt, wie Ausfallzeiten gemessen werden und ob geplante Wartungsfenster eingerechnet werden oder nicht.
Je höher die Verfügbarkeit, desto teurer wird der Betrieb. Ab einem gewissen Punkt braucht man Redundanz, Bereitschaftsdienst, Monitoring, Runbooks, Failover und kleine Incident-Prozesse.
Reaktions- und Lösungszeiten definieren, wie schnell der Dienstleister auf eine gemeldete Störung reagieren und sie beheben muss. Dabei ist die Unterscheidung wichtig: Reaktionszeiten lassen sich zuverlässig garantieren, Lösungszeiten sind je nach Fehlerursache oft nur als Zielwert sinnvoll, da etwa ein Hardware-Defekt andere Zeitrahmen erfordert als ein Softwarefehler.
Servicefenster legen fest, wann der Support tatsächlich erreichbar ist. 24/7-Support ist nicht immer notwendig, eine interne Mitarbeiter-App mit Nutzung nur an Werktagen zum Beispiel braucht keinen Nachtdienst. Eine Kunden-App mit internationalem Publikum dagegen schon.
Eskalationswege regeln, wer bei welcher Störungsstufe benachrichtigt wird. Bei einem kritischen Ausfall sollte klar sein, dass nicht erst ein Ticket-System durchlaufen wird, sondern sofort der verantwortliche Ansprechpartner informiert wird.
Pönalen und Service Credits sind die vertraglichen Konsequenzen, wenn zugesicherte Werte nicht eingehalten werden. Ein Beispiel: Liegt die tatsächliche Verfügbarkeit unter dem zugesicherten Wert, erhält der Auftraggeber eine prozentuale Gutschrift auf die Monatspauschale. Diese Regelung ist kein Misstrauensvotum, sie ist ein Qualitätsanreiz.
Reporting und KPIs sorgen dafür, dass die Servicequalität nicht nur intern gemessen, sondern dem Auftraggeber regelmäßig transparent gemacht wird. Ein regelmäßiger SLA-Report gibt Planungssicherheit und ermöglicht frühzeitig, auf Trends zu reagieren.
Prioritätsstufen im SLA: P1 bis P4
Nicht jede Störung ist gleich dringend. Ein gutes SLA unterscheidet daher zwischen Prioritätsstufen – und definiert für jede davon verbindliche Reaktions- und Lösungszeiten.
Diese Staffelung ist besonders wichtig in der App-Entwicklung, weil eine mobile Anwendung selten entweder „komplett ausgefallen“ oder „völlig in Ordnung“ ist. Die meisten Störungen liegen im mittleren Bereich: Eine Funktion verhält sich unerwartet, eine Darstellung ist auf bestimmten Geräten fehlerhaft, eine Schnittstelle antwortet langsam. Ein differenziertes Prioritätsmodell stellt sicher, dass diese Fälle systematisch bearbeitet werden, ohne dass jedes kleinere Problem als kritischer Notfall behandelt wird.
Warum ist ein SLA in der App-Entwicklung besonders wichtig?
Mit dem Go-live ist eine App kein abgeschlossenes Projekt, vielmehr wird sie Teil des laufenden Geschäftsbetriebs. Sie ist häufig direkt mit Umsatz, Kundenbindung oder internen Prozessen verknüpft. Wenn eine Außendienst-App am Montagmorgen nicht funktioniert, kostet das nicht nur Nerven, sondern produktive Arbeitszeit. Wenn eine Kunden-App Login-Probleme hat, leidet nicht nur die Nutzung, sondern auch das Vertrauen in das Unternehmen.
Genau deshalb ist ein SLA nach dem Go-live kein optionales Add-on, sondern ein strategisches Instrument. Es stellt sicher, dass der Dienstleister nicht nur während der Entwicklung, sondern dauerhaft Verantwortung trägt. Wie eine App entlang der gesamten Wertschöpfungskette Unternehmensabläufe unterstützt, zeigt sich oft erst im Betrieb – und genau dort entscheidet das SLA darüber, ob diese Unterstützung zuverlässig funktioniert.
Ohne SLA hingegen entsteht ein Vakuum: Weder Auftraggeber noch Dienstleister wissen verbindlich, was im Störungsfall gilt. Reaktionen werden zur Ermessensfrage statt zur vertraglichen Pflicht. Das führt erfahrungsgemäß zu Frustration auf beiden Seiten und zu Projekten, die nach dem Launch langsam auseinanderdriften.
SLA, SLO und SLC: Was ist der Unterschied?
Diese drei Begriffe werden häufig verwechselt – dabei beschreiben sie klar verschiedene Dinge.
Ein SLA (Service Level Agreement) ist die übergeordnete, rechtsverbindliche Vereinbarung zwischen Auftraggeber und Dienstleister. Es regelt alle Rahmenbedingungen der Servicequalität.
Ein SLO (Service Level Objective) ist das konkrete, messbare Leistungsziel innerhalb eines SLA, zum Beispiel „99,9 % Verfügbarkeit pro Monat“ oder „Reaktionszeit P1 maximal 60 Minuten“. SLOs sind die technischen Kennzahlen, an denen der Erfolg des SLA gemessen wird.
Ein SLC (Service Level Commitment) ist eine einseitige Selbstverpflichtung des Dienstleisters, ohne gegenseitige vertragliche Bindung. Anders als ein SLA enthält ein SLC keine Pönalen und keine formellen Konsequenzen bei Nichteinhaltung.
Worauf Unternehmen beim SLA-Abschluss achten sollten
Wer zum ersten Mal ein SLA verhandelt, unterschätzt oft, wie viel Einfluss die eigene Vorbereitung auf das Ergebnis hat. Einige Punkte sind dabei besonders entscheidend.
Verfügbarkeitsanforderungen realistisch einschätzen: 99,99 % Uptime klingt gut, kostet aber exponentiell mehr als 99,5 %, weil redundante Infrastruktur, geclusterte Systeme und mehrere Standorte notwendig werden. Für die meisten Unternehmens-Apps ist 99,5 % bis 99,9 % der wirtschaftlich sinnvolle Bereich. Entscheidend ist, was das eigene Geschäftsmodell wirklich braucht.
Servicefenster am Nutzungsverhalten ausrichten: Eine App, die primär zwischen 8 und 18 Uhr genutzt wird, braucht keinen 24/7-Support, wohl aber einen garantierten Bereitschaftsdienst für kritische Vorfälle außerhalb der Kernzeiten. Das SLA sollte das realistische Nutzungsprofil widerspiegeln.
Eskalationswege namentlich festlegen: Allgemeine Formulierungen wie „der zuständige Ansprechpartner wird informiert“ reichen nicht. Ein gutes SLA nennt konkrete Rollen oder Personen auf beiden Seiten.
Reporting einfordern: Wer monatliche SLA-Reports vereinbart, hat einen objektiven Überblick über die tatsächliche Servicequalität und eine Grundlage für sachliche Gespräche, wenn Werte nicht eingehalten werden.
Fazit: Das SLA ist keine Absicherung gegen den Dienstleister – es ist die Grundlage für Vertrauen
Ein Service Level Agreement schafft keine Misstrauenskultur. Es schafft Klarheit. Beide Seiten wissen, was vereinbart ist, wie Qualität gemessen wird und was passiert, wenn Zusagen nicht eingehalten werden. Gerade in der App-Entwicklung, wo nach dem Go-live ein dauerhafter Betrieb beginnt, ist das SLA das Fundament für eine Zusammenarbeit, die nicht nach dem ersten Release endet.
Sie planen eine App oder suchen nach einem verlässlichen Partner für den laufenden Betrieb? Sprechen Sie mit uns – wir erklären Ihnen gerne, wie ein transparentes SLA bei x-root aussieht.
Häufige Fragen zum Service Level Agreement
Ja, gerade bei kleineren Apps wird das SLA oft vergessen, obwohl es genauso wichtig ist. Auch eine interne Mitarbeiter-App kann geschäftskritisch sein. Ein einfaches SLA mit klaren Reaktionszeiten und einem definierten Servicefenster ist schnell vereinbart und schützt beide Seiten vor unklaren Erwartungen.
Das hängt von den vereinbarten Pönalen ab. Üblich sind Service Credits, also prozentuale Gutschriften auf die Monatspauschale, wenn zugesicherte Verfügbarkeits- oder Reaktionszeitwerte nicht erreicht werden. In schwerwiegenden oder wiederholten Fällen kann das SLA auch Kündigungsrechte vorsehen. Entscheidend ist, dass diese Konsequenzen klar und schriftlich geregelt sind.
Ein Wartungsvertrag regelt, welche Leistungen erbracht werden, zum Beispiel regelmäßige Updates, Sicherheits-Patches oder Funktionserweiterungen. Das SLA ergänzt diesen Vertrag um die Qualitätsdimension: wie schnell, wie zuverlässig und mit welchen messbaren Standards diese Leistungen erbracht werden. Beide Dokumente zusammen bilden die vollständige Grundlage für einen professionellen App-Betrieb.
