Service Level Agreement (SLA)

Stand: 7. April 2026

§ 1 – Geltungsbereich

(1) Dieses Service Level Agreement (nachfolgend „SLA") ergänzt die Allgemeinen Geschäftsbedingungen der aleduwa GmbH (nachfolgend „Anbieter") für die SaaS-Plattform „Workosy" und beschreibt die angestrebten Verfügbarkeits-, Support- und Reaktionsniveaus.

(2) Bei Widersprüchen zwischen diesem SLA und den AGB gilt die in § 1 Abs. 3 der AGB festgelegte Rangfolge.

(3) Das SLA gilt ausschließlich für kostenpflichtige Tarife. Für kostenlose Test-, Free- oder Beta-Tarife gelten die Zusagen dieses SLA nicht; der Anbieter erbringt diese Leistungen nach bestem Bemühen ohne Verfügbarkeits- oder Supportzusagen.

(4) Individuelle Vereinbarungen (z. B. Enterprise-SLAs) gehen den Regelungen dieses SLA vor.

§ 2 – Verfügbarkeitsziel

(1) Der Anbieter strebt eine Verfügbarkeit der Plattform-Kernfunktionen von 99,5 % im Monatsmittel (Kalendermonat) an, gemessen an der Erreichbarkeit der vom Anbieter betriebenen Server-Infrastruktur (HTTP-Statuscode 2xx/3xx auf den Health-Check-Endpunkt).

(2) Das Verfügbarkeitsziel ist ein Richtwert. Ein Unterschreiten begründet ausschließlich einen Anspruch auf Gutschriften gemäß § 9 und keine weitergehenden Ansprüche des Kunden, insbesondere nicht auf Schadensersatz, soweit nicht zwingendes Recht entgegensteht.

(3) Kernfunktionen im Sinne dieses SLA sind:

• Anmeldung und Authentifizierung,
• CRM-Modul (Kontakte, Unternehmen, Deals),
• Aufgabenverwaltung,
• Dokumenten-Editor (Lesen und Bearbeiten),
• Dateispeicherung (Upload und Download).

(4) Nicht als Kernfunktionen gelten insbesondere: Echtzeit-Kollaboration (Co-Editing), Kalender-Synchronisation, KI-Assistent, In-App-Suche, Benachrichtigungen, API-Endpunkte für Drittintegrationen sowie alle als „Beta" oder „Experimentell" gekennzeichneten Funktionen. Für diese Funktionen wird eine Verfügbarkeit nach bestem Bemühen angestrebt, jedoch weder zugesagt noch garantiert.

§ 3 – Berechnung der Verfügbarkeit

(1) Die Verfügbarkeit wird wie folgt berechnet:

Verfügbarkeit (%) = ((Gesamtminuten − Ausfallminuten) / Gesamtminuten) × 100

(2) „Gesamtminuten" entspricht der Anzahl der Minuten des jeweiligen Kalendermonats. „Ausfallminuten" sind die Minuten, in denen die Kernfunktionen für die Mehrheit der Nutzer nachweislich nicht erreichbar waren, abzüglich der ausgenommenen Zeiten nach § 4 und § 5.

(3) Kurzzeitige Unterbrechungen von weniger als zehn (10) aufeinanderfolgenden Minuten gelten nicht als Ausfallzeit.

(4) Leistungseinbußen (verlangsamte Antwortzeiten), die die grundsätzliche Nutzbarkeit der Kernfunktionen nicht verhindern, gelten nicht als Ausfallzeit.

(5) Maßgeblich für die Messung ist ausschließlich das Monitoring-System des Anbieters. Abweichende Messungen des Kunden oder Dritter werden zur Kenntnis genommen, sind jedoch nicht bindend.

§ 4 – Geplante Wartung

(1) Geplante Wartungsfenster werden in der Regel mindestens 48 Stunden im Voraus per E-Mail oder In-App-Benachrichtigung angekündigt. Der Anbieter behält sich vor, in dringenden Fällen kürzere Ankündigungsfristen zu wählen.

(2) Geplante Wartung wird nach Möglichkeit außerhalb der Geschäftszeiten (werktags 08:00–18:00 Uhr MEZ/MESZ) durchgeführt.

(3) Geplante Wartungszeiten zählen nicht als Ausfallzeit im Sinne von § 3, unabhängig von ihrer Dauer.

§ 5 – Ausnahmen

Von der Verfügbarkeitszusage ausgenommen und nicht als Ausfallzeit gewertet werden:

• Störungen durch höhere Gewalt gemäß § 21 der AGB,
• Ausfälle, Leistungseinschränkungen oder Änderungen bei Drittanbietern (insbesondere Microsoft Graph API, Clerk, Pusher, Anthropic, Cloudflare, Hetzner-Netzwerkinfrastruktur),
• Störungen, die vom Kunden oder seinen Nutzern verursacht oder mitverursacht wurden (z. B. Fehlkonfiguration, übermäßige oder missbräuchliche API-Nutzung, fehlerhaft konfigurierte Automatisierungen),
• DNS-Propagierungszeiten und Netzwerkprobleme außerhalb der Infrastruktur des Anbieters,
• Notfall-Wartung zur Behebung von Sicherheitslücken oder zur Abwehr akuter Bedrohungen, auch ohne vorherige Ankündigung,
• Datenmigration, Schema-Änderungen und Feature-Rollouts, die kurzfristige Nichterreichbarkeit einzelner Funktionen verursachen,
• Störungen, die auf nicht unterstützte Browser, Betriebssysteme oder Endgeräte des Kunden zurückzuführen sind,
• Zeiträume, in denen der Anbieter den Zugang gemäß § 20 der AGB berechtigt gesperrt hat.

§ 6 – Störungskategorien

(1) Die Einordnung einer Störung in eine Kategorie erfolgt ausschließlich durch den Anbieter nach pflichtgemäßem Ermessen. Die Kategorisierung ist für die Bestimmung der Reaktionszeiten nach § 7 maßgeblich.

(2) Der Anbieter kann die Kategorisierung während der Bearbeitung anpassen, wenn sich neue Erkenntnisse zum Umfang oder zur Ursache der Störung ergeben.

§ 7 – Reaktions- und Behebungszeiten

(1) Die folgenden Zeiten sind unverbindliche Richtwerte und gelten ausschließlich innerhalb der Supportzeiten (§ 8). Aus einer Überschreitung der Richtwerte entstehen keine eigenständigen Ansprüche des Kunden.

(2) „Erstreaktion" bedeutet die Bestätigung des Eingangs und eine erste Einschätzung, nicht den Beginn der technischen Behebung.

(3) Die endgültige Behebung erfolgt nach pflichtgemäßem Ermessen des Anbieters. Der Anbieter ist berechtigt, statt einer Fehlerbehebung einen zumutbaren Workaround bereitzustellen, wenn dies den wesentlichen Funktionsumfang wiederherstellt.

(4) Der Anbieter bemüht sich, bei kritischen Störungen auch außerhalb der regulären Supportzeiten zu reagieren, sofern das automatisierte Monitoring auf die Störung aufmerksam macht. Ein Anspruch des Kunden hierauf besteht nicht.

§ 8 – Supportkanäle und Supportzeiten

(1) Der Support ist über folgende Kanäle erreichbar:

• E-Mail: [email protected]
• In-App: Hilfe-Widget innerhalb der Plattform

(2) Die regulären Supportzeiten sind Montag bis Freitag, 09:00–17:00 Uhr MEZ/MESZ, ausgenommen gesetzliche Feiertage in Baden-Württemberg.

(3) Der Anbieter behält sich vor, Supportkanäle zu ändern oder weitere Kanäle hinzuzufügen. Änderungen werden mit angemessener Frist mitgeteilt.

(4) Telefonischer Support ist nicht Bestandteil des Standard-SLA und kann separat vereinbart werden.

§ 9 – Gutschriften (Service Credits)

(1) Unterschreitet die monatliche Verfügbarkeit das in § 2 Abs. 1 genannte Ziel und ist dies nicht auf Ausnahmen nach § 4 oder § 5 zurückzuführen, kann der Kunde eine Gutschrift gemäß folgender Staffelung beantragen:

(2) Die maximale Gutschrift pro Kalendermonat ist auf 15 % der monatlichen Nettovergütung begrenzt.

(3) Gutschriften werden ausschließlich auf schriftlichen Antrag des Kunden in Textform gewährt. Der Antrag muss innerhalb von vierzehn (14) Tagen nach Ende des betroffenen Kalendermonats beim Anbieter eingehen. Verspätete Anträge sind ausgeschlossen.

(4) Gutschriften werden mit der nächsten Rechnung verrechnet. Eine Barauszahlung, Übertragung auf andere Abrechnungsperioden oder Anrechnung auf andere Verträge ist ausgeschlossen.

(5) Gutschriften werden nicht gewährt, wenn der Kunde zum Zeitpunkt des Ausfalls mit fälligen Zahlungen in Verzug war, gegen seine Mitwirkungspflichten nach § 5 der AGB verstoßen hat oder die Störung durch den Kunden oder seine Nutzer mitverursacht wurde.

(6) Der Anspruch auf Gutschriften nach diesem § 9 stellt den ausschließlichen und abschließenden Rechtsbehelf des Kunden bei Unterschreitung des Verfügbarkeitsziels dar. Weitergehende Ansprüche – gleich aus welchem Rechtsgrund – sind ausgeschlossen, soweit nicht § 16 Abs. 1 der AGB (Haftung für Vorsatz, grobe Fahrlässigkeit, Leben, Körper, Gesundheit) entgegensteht.

§ 10 – Pflichten des Kunden bei Störungen

(1) Der Kunde meldet Störungen über die in § 8 genannten Supportkanäle unter Angabe folgender Informationen:

• Beschreibung des Fehlverhaltens,
• betroffene Funktion(en) und URL(s),
• Zeitpunkt des ersten Auftretens,
• Reproduktionsschritte (soweit möglich),
• Screenshots oder Bildschirmaufnahmen (soweit hilfreich),
• eingesetzte Browser-Version und Betriebssystem.

(2) Unvollständige oder unklare Störungsmeldungen können die Bearbeitungszeit verlängern. Der Anbieter ist berechtigt, die Bearbeitung auszusetzen, bis der Kunde die erforderlichen Informationen nachliefert.

(3) Der Kunde ist verpflichtet, bei der Störungsanalyse angemessen mitzuwirken (z. B. Testen von Workarounds, Bereitstellen von Zugangsdaten zu betroffenen Workspaces auf Anfrage). Unterlässt der Kunde die Mitwirkung, verlängern sich die Bearbeitungszeiten entsprechend.

§ 11 – Eskalation

(1) Wird eine kritische oder hohe Störung nicht innerhalb der in § 7 genannten Richtwerte gelöst, kann der Kunde eine Eskalation über den Supportkanal beantragen.

(2) Der Anbieter entscheidet nach eigenem Ermessen über die geeignete Eskalationsstufe und den zuständigen Ansprechpartner.

(3) Ein Anspruch auf Bearbeitung durch eine bestimmte Person oder Hierarchiestufe besteht nicht.

§ 12 – Berichterstattung

(1) Der Anbieter kann auf Anfrage einen Verfügbarkeitsbericht für einen abgelaufenen Kalendermonat zur Verfügung stellen. Der Anbieter bestimmt Form und Umfang des Berichts.

(2) Bei kritischen Störungen kann der Anbieter nach eigenem Ermessen einen Post-Incident-Report erstellen. Ein Anspruch des Kunden auf Erstellung oder Einsicht besteht nicht.

§ 13 – Änderung des SLA

(1) Der Anbieter ist berechtigt, dieses SLA mit einer Ankündigungsfrist von dreißig (30) Tagen in Textform zu ändern.

(2) Die Änderungen werden dem Kunden per E-Mail oder innerhalb der Plattform mitgeteilt. Widerspricht der Kunde nicht innerhalb von dreißig (30) Tagen nach Zugang, gelten die Änderungen als akzeptiert.

(3) Bei wesentlichen Verschlechterungen des Verfügbarkeitsziels oder der Gutschriftenregelungen findet § 19 der AGB (Sonderkündigungsrecht) entsprechend Anwendung.