Das Wichtigste in Kürze
- SLAs sind zentrale Instrumente für SaaS-Startups zur Leistungsdefinition und Haftungsbegrenzung.
- Verfügbarkeitszusagen (Uptime) müssen präzise definiert werden, oft im Bereich von 99 % bis 99,9 % pro Monat.
- Wartungsfenster sollten klar zwischen geplanten und ungeplanten Arbeiten unterscheiden und frühzeitig angekündigt werden.
- Support-Level und Reaktionszeiten werden nach Priorität gestaffelt, wobei die Messung innerhalb definierter Supportzeiten erfolgt.
- Service Credits sind übliche Sanktionen bei SLA-Verletzungen, die als pauschalierter Schadensersatz dienen und die Haftung begrenzen.
Service Level Agreements (SLAs) für SaaS-Startups: Praxisnahe und rechtssichere Gestaltung in Deutschland
Service Level Agreements (SLAs) sind für SaaS-Startups ein zentrales Instrument. Sie geben Kunden klare Leistungsvorgaben und lenken gleichzeitig die eigene Haftung in kontrollierbare Bahnen. Dieser Leitfaden beleuchtet praxisnah, wie SLAs in Deutschland professionell und rechtssicher gestaltet werden können.
Wir betrachten dabei verschiedene Aspekte. Dazu gehören marktübliche Verfügbarkeitszusagen, die Definition von Wartungsfenstern, abgestufte Support-Level und Reaktionszeiten. Ebenso werden Service Credits bzw. Vertragsstrafen bei SLA-Verletzungen sowie die Zulässigkeit solcher Klauseln nach deutschem AGB-Recht behandelt. Der Überblick richtet sich an juristisch und unternehmerisch interessierte Leser, die für ein robustes SaaS-Startup ein robustes SLA entwickeln möchten.
SLA-Verfügbarkeitszusagen in der SaaS-Branche
Ein Kernbestandteil jedes SLA ist die verfügbare Betriebszeit der Cloud-Software (Uptime). Branchenüblich sind sehr hohe Verfügbarkeitszusagen. Absolute 100 % werden dabei kaum garantiert.
Stattdessen werden meist Werte im Bereich von 99 % bis 99,9 % pro Zeitraum vereinbart. Diese Zahlen wirken auf den ersten Blick klein. Sie entsprechen jedoch beträchtlichen Unterschieden in der zulässigen Ausfallzeit (Downtime):
- 99 % Verfügbarkeit – erlaubt jährliche Ausfälle bis zu circa 87,6 Stunden (circa 7 Stunden pro Monat).
- 99,5 % Verfügbarkeit – erlaubt bis zu circa 43,8 Stunden Ausfall pro Jahr (circa 3,6 Stunden pro Monat).
- 99,9 % Verfügbarkeit – erlaubt maximal circa 8,8 Stunden Ausfall im Jahr, das sind nur etwa 44 Minuten pro Monat.
Je höher der Prozentwert, desto geringer die tolerierte Downtime. „Five Nines“ (99,999 %) entsprechen zum Beispiel nur etwa 5 Minuten Ausfall pro Jahr. Dies ist nur bei hochverfügbaren Enterprise-Systemen realistisch. Für ein Startup genügen oft drei Neunen (99,9 %) als Ziel für geschäftskritische Dienste, während weniger kritische Anwendungen auch mit circa 99 %–99,5 % Zusage betrieben werden können.
Es ist wichtig, die Werte und Bezugszeiträume genau zu definieren. Üblich ist eine Messung pro Kalendermonat. Dies verhindert, dass Ausfälle aus einem schlechten Monat durch gute Monate „verwässert“ werden.
Eine beispielhafte SLA-Klausel könnte lauten: „Der SaaS-Dienst hat eine Verfügbarkeit von 99,5 % pro Monat.“ Dabei muss klargestellt werden, wie die Verfügbarkeit gemessen wird. Dies erfolgt oft bezogen auf die Gesamtzeit minus definierte Wartungszeiten.
Ferner empfiehlt es sich, festzulegen, was genau als Ausfall zählt. Hierbei ist zwischen einem kompletten Dienstausfall und einer bloßen Performance-Degradation zu unterscheiden. Manche Anbieter schließen „Teilstörungen“ oder Minderleistung ausdrücklich von der Downtime-Berechnung aus. Entscheidend ist eine transparente und nachvollziehbare Regelung der Kennzahl Verfügbarkeit für beide Seiten.
SLA-Regelungen zu Wartungsfenstern: Geplante vs. ungeplante Wartung
Wartungsarbeiten sind unvermeidlich, sei es für Updates, Bugfixes oder Sicherheits-Patches. Im SLA sollten Wartungsfenster festgelegt werden. So lassen sich planbare Downtime und echte Störungen klar voneinander trennen.
Üblich ist die Unterscheidung zwischen geplanter Wartung (maintenance) und ungeplanter Wartung (Notfallmaßnahmen):
Geplante Wartungsfenster
Hierunter fallen regelmäßige, vorab angekündigte Arbeiten. Es werden feste Zeitfenster definiert, in denen der Service planmäßig nicht oder nur eingeschränkt verfügbar sein darf. Dies gilt nicht als SLA-Verstoß.
Viele Anbieter legen diese Fenster in verkehrsarme Zeiten, zum Beispiel nachts oder am Wochenende. Ein Beispiel für eine Klausel: „Wartungsarbeiten finden in der Regel werktags zwischen 01:00 und 08:00 Uhr morgens oder am Wochenende statt.“
Häufig wird auch die Dauer begrenzt, etwa auf „maximal 1 Stunde planmäßige Wartung pro Monat.“ Besonders wichtig ist die Vorankündigungsfrist. Geplante Downtimes müssen rechtzeitig mitgeteilt werden, typischerweise mindestens 24 Stunden vorher, besser einige Tage.
Bynder kündigt Wartungen beispielsweise 5 Tage im Voraus an, mindestens jedoch 24 Stunden vorher. Diese Kombination aus beschränkter Häufigkeit/Dauer und rechtzeitiger Ankündigung ermöglicht es Kunden, Wartungsfenster einzuplanen, ohne überraschende Ausfälle befürchten zu müssen.
Ungeplante (außerplanmäßige) Wartung
Dieser Punkt umfasst Notfälle wie sicherheitskritische Updates oder unvorhergesehene technische Probleme, die sofortiges Handeln erfordern. Das SLA sollte regeln, wie solche Fälle behandelt werden.
Eine bewährte Praxis ist, dass der Anbieter Notfall-Eingriffe nach Möglichkeit zumindest kurz vorher ankündigt. Dies kann per E-Mail oder über eine Status-Seite geschehen. Gleichzeitig sollte auf die geringstmögliche Beeinträchtigung geachtet werden.
Manche SLAs legen fest, dass ungeplante Wartung außerhalb der definierten Wartungsfenster als Downtime zählt. Dies gilt, falls nicht mindestens 24 Stunden vorher informiert wurde. Dadurch wird verhindert, dass der Anbieter spontane Wartungen durchführt und diese nachträglich als „geplant“ deklariert.
Für absolute Notfälle, etwa eine akute Security-Lücke, werden jedoch Ausnahmen zugelassen. Solche Fälle sind selten und sollten als Force Majeure oder ähnliche Klausel separat behandelt werden.
Faustregeln für Wartungsklauseln
Für Wartungsklauseln gelten folgende Faustregeln:
- Geplante Wartungen sollten klar definiert (Zeiten, Dauer) und von der Verfügbarkeitsberechnung ausgenommen werden.
- Diese Wartungen müssen frühzeitig angekündigt werden.
- Ungeplante Eingriffe sind nur im Notfall zulässig.
Der Anbieter behält somit die nötige Flexibilität für Betrieb und Updates. Kunden müssen die vereinbarte Uptime nicht anzweifeln.
Support-Level und Reaktionszeiten nach Priorität
Ein SLA sollte neben der technischen Verfügbarkeit auch den Support abdecken. Hierbei geht es um die Frage, wie schnell der Anbieter auf ein Problem des Kunden reagiert. Eine professionelle Support-Vereinbarung ist besonders für B2B-Kunden wichtig, um Betriebsstörungen zügig zu beheben.
Üblich ist es, Störungsmeldungen nach Dringlichkeit zu priorisieren. Für jede Prioritätsstufe werden bestimmte Reaktionszeiten festgelegt:
- Priorität 1 – Kritische Störung: Hierunter fallen gravierende Incidents, etwa ein Totalausfall der SaaS-Plattform oder ein sicherheitsrelevanter Vorfall, der keinen Aufschub duldet. Die Reaktionszeit (Time-to-Respond) sollte sehr kurz sein, zum Beispiel innerhalb 1 Stunde ab Eingang der Störungsmeldung (oft sogar 30 Minuten bei hohen Ansprüchen). In dieser Zeit muss zumindest die Bearbeitung begonnen werden, etwa durch einen Rückruf oder erste Maßnahmen.
- Priorität 2 – Hohe Störung: Dies sind bedeutende Funktionseinschränkungen, bei denen jedoch ein Workaround existiert oder das System noch eingeschränkt läuft. Reaktionszeiten sind hier etwas länger, zum Beispiel innerhalb 4 Stunden.
- Priorität 3 – Mittlere/Niedrige Priorität: Dies betrifft kleinere Bugs, allgemeine Anfragen oder nicht dringliche Probleme. Hier genügen längere Reaktionszeiten, zum Beispiel innerhalb von 24 Stunden oder bis zum nächsten Geschäftstag.
Diese Beispiele zeigen ein mögliches Schema, das oft in P1/P2/P3 kategorisiert wird. Wichtig ist, dass das SLA auch definiert, wann die Uhr für die Reaktionszeit läuft. Häufig gelten Reaktionszeiten nur innerhalb definierter Supportzeiten, etwa Montag bis Freitag, 8:00–18:00 Uhr.
Dies bedeutet beispielsweise, dass eine kritische Störung mit einer „Reaktionszeit von 1 Stunde“, die am Freitag um 22:00 Uhr gemeldet wird, erst am nächsten Werktag um 9:00 Uhr bearbeitet werden muss. Wer 24/7-Support anbieten möchte, muss dies ausdrücklich zusagen. Für Startups ist dies oft eine Kostenfrage.
Alternativ kann man Premium-Support mit erweiterten Zeiten gegen Aufpreis anbieten.
Manchmal wird zusätzlich zur Reaktionszeit eine Lösungszeit (Time-to-Resolve) vereinbart. Dies könnte bedeuten, dass bei P1-Störungen innerhalb von 4 oder 8 Stunden eine Lösung oder zumindest ein Workaround bereitgestellt sein muss. Eine solche Vereinbarung ist jedoch heikel, da nicht jeder Fehler in fester Zeit gelöst werden kann.
Oft begnügt man sich damit, Reaktions- bzw. Wiederherstellungszeiten als Zielgrößen (Service Level Objectives) zu definieren, ohne Garantien im engen Sinne. Wichtig ist eine klare Beschreibung der Support-Prozesse. Der Kunde sollte wissen, wie er Störungen meldet (z. B. über ein Ticketsystem oder eine Hotline) und wie diese priorisiert werden.
Ein transparentes Verfahren erhöht das Kundenvertrauen und verhindert falsche Erwartungen.
Vertragsstrafen und Gutschriften bei SLA-Verletzungen
Ein SLA ist ohne Regelungen für den Fall, dass der Anbieter die zugesagten Service Levels nicht einhält, unvollständig. Hier kommen vertragliche Sanktionen ins Spiel, die von Vertragsstrafen bis zu Service Credits reichen.
Im SaaS-Umfeld haben sich vor allem Service Credits (Gutschriften) als gängige Lösung etabliert. Dies ist quasi eine Geld-zurück-Garantie in Form einer Gutschrift, die der Kunde bei Nichterreichen des SLA anfordern kann.
Typische Modelle für Service Credits
Oft vereinbaren Provider und Kunde einen bestimmten Prozentsatz der monatlichen Gebühr, der gutgeschrieben wird. Dieser hängt davon ab, wie stark das SLA verfehlt wurde.
Ein Beispiel: Bei Unterschreitung der garantierten Verfügbarkeit gewährt der Anbieter pro x Stunden Ausfall eine Gutschrift von y % der Monatsgebühr. Ein konkretes Modell aus der Praxis könnte lauten: „Je angefangene 30 Minuten Ausfallzeit erhält der Kunde eine Gutschrift in Höhe einer Tagesmiete (1/30 der Monatsgebühr), maximal jedoch 50 % der Monatsgebühr.“
Damit wird der Ausfallschaden pauschaliert. Der Kunde erhält einen finanziellen Ausgleich, meist verrechnet auf zukünftige Rechnungen, ohne jeden einzelnen Schadenersatzanspruch kompliziert nachweisen zu müssen. Gleichzeitig begrenzt der Anbieter seine Haftung nach oben, beispielsweise auf höchstens die Hälfte eines Monatsentgelts.
Dieses Modell soll einen Anreiz zur Leistung schaffen. Es soll den Anbieter jedoch nicht übermäßig bestrafen.
Grenzen und rechtliche Einordnung von Service Credits
Es ist wichtig, dass solche Gutschriften automatisch oder auf einfachen Antrag des Kunden gewährt werden. Üblich ist eine Frist, innerhalb derer der Kunde den SLA-Verstoß melden und die Gutschrift einfordern muss, beispielsweise „innerhalb von 5 Werktagen nach Monatsende“. Versäumt der Kunde diese Frist, verfällt der Anspruch. Dies sollte deutlich im Vertrag stehen.
Eine Barauszahlung der Credits ist meist ausgeschlossen; stattdessen werden sie mit künftigen Zahlungen verrechnet. Zudem wird in vielen SLAs festgelegt, dass Service Credits das exklusive Rechtsmittel des Kunden sind. Sie werden also anstelle anderer Gewährleistungs- oder Schadensersatzansprüche gewährt.
Der Anbieter versucht so zu verhindern, dass der Kunde trotz Gutschrift noch weitere Ansprüche, wie entgangenen Gewinn, geltend macht. Allerdings ist Vorsicht geboten: Eine solche Haftungsbeschränkung muss im Rahmen des deutschen Rechts zulässig sein.
Juristisch gesehen sind Service Credits eine Form von pauschaliertem Schadensersatz oder Vertragsstrafe, je nach Ausgestaltung. Eine Vertragsstrafe, auch „Konventionalstrafe“ genannt, hat primär Sanktionscharakter. Sie setzt den Anbieter unter Druck, die Leistungspflicht zu erfüllen und erleichtert dem Kunden den Erhalt eines Ausgleichs ohne Schadensnachweis.
Im Unterschied dazu dient eine echte Schadensersatz-Pauschale vor allem der Beweiserleichterung und orientiert sich an einem typischen Schaden. In der Praxis verschwimmen die Begriffe. „Service Credits“ werden gerne verwendet, um das Konzept kundenfreundlich klingen zu lassen. Letztlich handelt es sich um eine vertraglich festgelegte Kompensation bei Minderleistung.
Die Höhe und Voraussetzungen der Gutschriften sollten im Vertrag eindeutig bestimmt sein. Sie sollten am besten objektiv messbar sein, zum Beispiel über Prozentsätze oder Zeiten. Kein Anbieter wird einer unbegrenzten Strafzahlung zustimmen, daher sind Kappungsgrenzen (Ceiling) gängig, wie im obigen Beispiel 50 % der Monatsgebühr.
Darüber hinaus können Sonderkündigungsrechte vereinbart werden. Bei schwerwiegenden SLA-Verletzungen, etwa wenn die Verfügbarkeit über längere Zeit weit unter dem zugesagten Wert liegt, erhält der Kunde das Recht zur fristlosen Kündigung aus wichtigem Grund. Diese „Exit-Klausel“ wirkt zwar dramatisch, ist aber ein wichtiges Druckmittel für Kunden und erhöht die Glaubwürdigkeit des SLA.
AGB-rechtliche Zulässigkeit und Haftungsbegrenzung in SLAs
Für deutsche SaaS-Startups ist es entscheidend, dass die SLA-Klauseln mit dem AGB-Recht (§§ 305 ff. BGB) im Einklang stehen. SLAs gelten meist als vorgefertigte Vertragsbedingungen.
Eine vermeintlich clevere Klausel nützt nichts, wenn sie vor Gericht unwirksam ist. Daher sollten folgende Punkte beachtet werden:
-
AGB-Konformität von SLA-Klauseln
Keine „überraschenden“ Klauseln: Vertragsbedingungen, die so ungewöhnlich sind, dass der Kunde vernünftigerweise nicht mit ihnen rechnen musste, werden nicht Vertragsbestandteil (§ 305c BGB). Wichtige SLA- und Haftungsklauseln sollten daher transparent und deutlich formuliert sein und nicht im Kleingedruckten versteckt werden. - Haftung für grobes Verschulden nicht ausschließen: Der Ausschluss oder die Begrenzung der Haftung für Vorsatz und grobe Fahrlässigkeit ist in AGB unzulässig. Ebenso nicht abdingbar sind Schäden aus der Verletzung von Leben, Körper, Gesundheit sowie Haftung wegen Arglist.
- Solche Haftungsausschlüsse wären unangemessen benachteiligend (§ 307 BGB) und damit unwirksam.
- Eine SLA-Klausel darf nie den Eindruck erwecken, der Anbieter hafte auch bei eigenem Vorsatz oder grober Fahrlässigkeit nicht. Dies wäre rechtlich nicht haltbar.
- „Garantie“ vorsichtig verwenden: Wird im SLA eine Leistung ausdrücklich als Garantie zugesagt, kann die Haftung bei Nichteinhaltung nicht durch andere Klauseln begrenzt werden. Wenn der Anbieter beispielsweise „garantiert, dass die Verfügbarkeit 99,9 % beträgt“, könnte dies als selbstständige Garantieverpflichtung ausgelegt werden.
- In diesem Fall griffe die gesetzliche Garantieliabilität (§ 444 BGB analog) und ein Haftungsausschluss dafür wäre unwirksam.
- Juristen raten daher, stattdessen Begriffe wie „zusichern“ oder „vereinbaren“ zu verwenden.
- Die Rechtsfolgen der Nichteinhaltung sollten explizit im SLA geregelt werden, zum Beispiel durch Service Credits.
- Haftung bei leichter Fahrlässigkeit: Für Fälle einfacher (leichter) Fahrlässigkeit kann die Haftung in AGB grundsätzlich beschränkt werden, jedoch nicht unbegrenzt. Eine wichtige Schranke sind die Kardinalpflichten, also wesentliche Vertragspflichten, deren Verletzung die Erreichung des Vertragszwecks gefährden würde.
- Verletzt der Anbieter solche Kardinalpflichten, verlangt die Rechtsprechung, dass er zumindest den vorhersehbaren, vertragstypischen Schaden ersetzen muss.
- Ein vollständiger Haftungsausschluss für leichte Fahrlässigkeit bei essentiellen Leistungen, wie der Hauptleistung der SaaS-Bereitstellung, hält einer AGB-Kontrolle nicht stand.
- Das bedeutet, eine Klausel wie „Bei Ausfall des Dienstes ist jegliche Haftung des Anbieters ausgeschlossen“ wäre unwirksam. Der Kunde hätte trotz AGB im Ernstfall Anspruch auf Ersatz des typischen Schadens, wie etwa eine Mietminderung.
- Zulässig ist es jedoch, die Haftung der Höhe nach zu begrenzen, beispielsweise auf einen bestimmten Betrag oder auf die Summe der gezahlten Entgelte. Dies gilt, sofern die Kernpflichten nicht gänzlich aus der Haftung genommen werden.
- Keine pauschalen Ausschlüsse für bestimmte Schadenstypen, wenn diese den Kunden stark beeinträchtigen: Anbieter versuchen oft, in AGB die Haftung für indirekte Schäden, entgangenen Gewinn, Betriebsunterbrechung oder Datenverlust generell auszuschließen. Solche pauschalen Ausschlüsse sind jedoch rechtlich riskant.
- Nach deutschem Recht können sie als unangemessen angesehen werden, insbesondere wenn sie typischerweise zu erwartende Schäden betreffen.
- Ein völliger Ausschluss für Datenverlust ist beispielsweise problematisch, wenn der SaaS-Anbieter per Vertrag Datensicherheit schuldet. Ein Totalhaftungsausschluss würde den Kunden unzumutbar benachteiligen.
- Besser ist es, die Haftung für solche Folgeschäden auf Vorsatz und grobe Fahrlässigkeit zu begrenzen. Sie sollte nicht für jede Fahrlässigkeit ausgeschlossen werden.
- Zudem sollten Kunden vertraglich auf Backup-Pflichten hingewiesen werden, um die Risikoverteilung fair zu gestalten. Dies ist relevant im Thema Datensicherung.
- Vertragsstrafen moderat halten: Falls im SLA eine Vertragsstrafe bei SLA-Verstößen vereinbart wird, etwa ein fester Geldbetrag pro Ausfallstunde, muss diese angemessen sein. In Verbraucherverträgen sind Vertragsstrafen in AGB nach § 309 Nr. 6 BGB generell unzulässig.
- In B2B-Verträgen sind sie zwar zulässig, die Höhe unterliegt jedoch Grenzen.
- Der BGH hat entschieden, dass in AGB vereinbarte Vertragsstrafen, die 5 % des Auftragswertes übersteigen, in der Regel unwirksam sind.
- Eine Klausel, die dem SaaS-Kunden beispielsweise 10 % Monatsgebühr als Strafe pro Ausfallstunde zuspricht, würde diese Schwelle sprengen und könnte kassiert werden.
- Daher gilt: Wenn Strafen vereinbart werden, sollten diese niedrig dimensioniert und besser individuell ausgehandelt werden, statt sie in AGB fix zu hoch anzusetzen.
- Mietminderung und gesetzliche Gewährleistung: Da SaaS rechtlich oft als Mietvertrag eingeordnet wird, steht dem Kunden bei Mängeln grundsätzlich das Recht zur Mietminderung nach § 536 BGB zu. Die Bereitstellung der Software gegen Entgelt entspricht einer Gebrauchsüberlassung.
- Eine Unterverfügbarkeit der Software, also eine Downtime über das vertraglich zulässige Maß hinaus, könnte als Mietmangel gelten. Dies würde eine Gebührenminderung oder sogar Schadensersatz ermöglichen.
- Viele Anbieter versuchen, dieses gesetzliche Minderungsrecht durch die SLA-Regelung zu ersetzen. Sie legen beispielsweise fest, dass Service Credits die exklusiven Ansprüche des Kunden sind.
- Eine solche Klausel muss jedoch so gestaltet sein, dass sie den Kunden nicht unangemessen benachteiligt (§ 307 BGB).
- Praktisch bedeutet das: Die Kompensation im SLA (Gutschriften) sollte in etwa dem Wert der gesetzlichen Minderung entsprechen. Wäre die vertragliche Gutschrift viel geringer als das, was der Kunde nach Gesetz verlangen könnte, riskiert man die Unwirksamkeit der Klausel.
- Im Zweifel sollte dem Kunden zumindest vorbehalten bleiben, weitergehende Schäden geltend zu machen. Dies gilt, falls der tatsächliche Schaden größer ist als die pauschale Gutschrift, zumindest für Fälle, die der Anbieter zu vertreten hat. Eine sorgfältige juristische Formulierung ist hier empfehlenswert.
Balance zwischen Zusagen und Haftungsbegrenzungen
Zusammenfassend muss eine rechtssichere SLA-Gestaltung eine Balance wahren. Sie muss klar definierte, für Kunden hilfreiche Zusagen bieten und gleichzeitig wirksame Haftungsbegrenzungen für den Anbieter enthalten. Überraschungen und Einseitigkeiten sind zu vermeiden.
Im Zweifel sollten SLA-Klauseln einfach und fair gehalten werden. So haben sie im Ernstfall Bestand und werden nicht vor Gericht gekippt.
Fazit
Ein gut formuliertes SLA ist für ein SaaS-Startup Gold wert. Es schafft Vertrauen bei Kunden, indem es Verfügbarkeit, Support und Reaktionszeiten verbindlich zusagt. Gleichzeitig gibt es dem Anbieter einen Rahmen zur Risikokontrolle.
Marktübliche Verfügbarkeitszusagen, wie 99 % oder 99,9 % Uptime, stellen sicher, dass Kunden auf die Zuverlässigkeit des Dienstes vertrauen können. Klar definierte Wartungsfenster lassen dem Betreiber genügend Raum für Updates und Pflege, ohne versteckte Ausfälle.
Gestufte Support-Level mit schnellen Reaktionszeiten für kritische Probleme zeigen Professionalität und Kundennähe. Im Falle von Leistungsstörungen sorgen Service Credits als vertragliche Kompensation dafür, dass Kunden fair entschädigt werden, ohne dass gleich der Rechtsweg beschritten werden muss.
All dies trägt zu einer professionellen Kundenkommunikation bei und begrenzt die Haftung des Anbieters auf planbare Weise.
Bei der Ausarbeitung eines SLA sollten Startups stets den rechtlichen Rahmen im Blick behalten. Die beste SLA-Klausel nützt nichts, wenn sie vor Gericht keinen Bestand hat. Indem man die AGB-rechtlichen Leitplanken einhält, wird das SLA rechtssicher.
Dazu gehören keine unzulässigen Haftungsausschlüsse und angemessene Regelungen bei Pflichtverletzungen. Im Zweifel lohnt es sich, juristischen Rat einzuholen oder an bewährten Branchenvorbildern Maß zu nehmen.
Ein SLA ist letztlich mehr als nur ein Vertrag. Es ist ein Leistungsversprechen an die Kunden. Wenn es gut gemacht ist, profitieren beide Seiten: Der Kunde weiß, worauf er sich verlassen kann, und das Startup setzt klare Grenzen für seine Verpflichtungen.
Die Zusammenarbeit wird verlässlich, Streitigkeiten werden vorgebeugt, und das SaaS-Startup kann sich darauf konzentrieren, seinen Service stetig zu verbessern, ohne im Haftungsdschungel zu stranden. Eine klare SLA-Gestaltung zahlt sich langfristig aus – sowohl in Kundenzufriedenheit als auch in Rechtssicherheit.
Häufig gestellte Fragen
Was ist ein Service Level Agreement (SLA) für SaaS-Startups?
Welche Verfügbarkeitszusagen sind in der SaaS-Branche üblich?
Wie werden Wartungsarbeiten in einem SLA geregelt?
Was sind Service Credits und wie funktionieren sie bei SLA-Verletzungen?
Wie werden Support-Anfragen in einem SLA priorisiert?
| Merkmal | Geplante Wartung | Ungeplante Wartung |
|---|---|---|
| Definition | Regelmäßige, vorab angekündigte Arbeiten (Updates, Bugfixes, Patches). | Notfälle wie sicherheitskritische Updates oder unvorhergesehene technische Probleme. |
| Ankündigung | Feste Zeitfenster, rechtzeitige Mitteilung (typischerweise 24h-einige Tage vorher). | Nach Möglichkeit kurz vorher (E-Mail, Status-Seite), bei Notfällen sofort. |
| Zeitpunkt | Verkehrsarme Zeiten (nachts, Wochenende). | Jederzeit, wenn erforderlich. |
| SLA-Relevanz | Gilt nicht als SLA-Verstoß, von Verfügbarkeitsberechnung ausgenommen. | Zählt als Downtime, falls nicht mindestens 24h vorher informiert (Ausnahme: absolute Notfälle/Force Majeure). |
| Dauer/Häufigkeit | Oft begrenzt (z.B. max. 1 Stunde pro Monat). | So kurz wie möglich. |
| Priorität | Beschreibung | Reaktionszeit (Beispiel) |
|---|---|---|
| Priorität 1 (Kritisch) | Gravierende Incidents (Totalausfall, sicherheitsrelevant), kein Aufschub. | Innerhalb 1 Stunde (oft 30 Minuten). |
| Priorität 2 (Hoch) | Bedeutende Funktionseinschränkungen, Workaround existiert oder System läuft eingeschränkt. | Innerhalb 4 Stunden. |
| Priorität 3 (Mittel/Niedrig) | Kleinere Bugs, allgemeine Anfragen, nicht dringliche Probleme. | Innerhalb 24 Stunden oder bis zum nächsten Geschäftstag. |