Service Level Agreements (SLA) für SaaS-Startups in Deutschland – Ein Leitfaden zur Vertragsgestaltung

Service Level Agreements (SLAs) sind für SaaS-Startups ein zentrales Instrument, um Kunden klare Leistungsvorgaben zu geben und gleichzeitig die eigene Haftung in kontrollierbare Bahnen zu lenken. In diesem Leitfaden betrachten wir praxisnah, wie SLAs in Deutschland professionell und rechtssicher gestaltet werden können. Dabei beleuchten wir marktübliche Verfügbarkeitszusagen, die Definition von Wartungsfenstern, abgestufte Support-Level und Reaktionszeiten, Service Credits bzw. Vertragsstrafen bei SLA-Verletzungen sowie die Zulässigkeit solcher Klauseln nach deutschem AGB-Recht. Dieser Überblick richtet sich an juristisch und unternehmerisch interessierte Leserinnen und Leser, die für ein SaaS-Startup ein robustes SLA entwickeln möchten.

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 kaum garantiert, sondern meist Werte im Bereich 99 % bis 99,9 % pro Zeitraum. Solche Zahlen wirken klein, aber sie entsprechen beträchtlichen Unterschieden in der zulässigen Ausfallzeit (Downtime):

• 99 % Verfügbarkeit – erlaubt jährliche Ausfälle bis zu ~87,6 Stunden (ca. 7 Stunden pro Monat).
• 99,5 % Verfügbarkeit – erlaubt bis zu ~43,8 Stunden Ausfall pro Jahr (ca. 3,6 Stunden pro Monat).
• 99,9 % Verfügbarkeit – erlaubt maximal ~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 z. B. nur etwa 5 Minuten Ausfall pro Jahr, was nur bei hochverfügbaren Enterprise-Systemen realistisch ist. Für ein Startup genügen oft drei Ninen (99,9 %) als Ziel für geschäftskritische Dienste, während weniger kritische Anwendungen auch mit ~99 %–99,5 % Zusage betrieben werden können.

Wichtig ist, Werte und Bezugszeiträume genau zu definieren. Üblich ist eine Messung pro Kalendermonat (so wird verhindert, dass Ausfälle aus einem schlechten Monat durch gute Monate „verwässert“ werden). Eine SLA-Klausel könnte z. B. lauten: „Der SaaS-Dienst hat eine Verfügbarkeit von 99,5 % pro Monat.“ Dabei sollte klargestellt werden, wie Verfügbarkeit gemessen wird – etwa bezogen auf die Gesamtzeit minus definierte Wartungszeiten (siehe nächster Abschnitt). Es empfiehlt sich auch, festzulegen, was genau als Ausfall zählt (kompletter Dienstausfall vs. bloße Performance-Degradation). Manche Anbieter schließen „Teilstörungen“ oder Minderleistung ausdrücklich von der Downtime-Berechnung aus. Entscheidend ist, dass die Kennzahl Verfügbarkeit transparent und für beide Seiten nachvollziehbar geregelt ist.

Wartungsfenster: Geplante vs. ungeplante Wartung

Wartungsarbeiten sind unvermeidlich, sei es für Updates, Bugfixes oder Sicherheits-Patches. Im SLA sollten Wartungsfenster festgelegt werden, um planbare Downtime klar von echten Störungen zu trennen. Üblich ist die Unterscheidung zwischen geplanter Wartung (maintenance) und ungeplanter Wartung (Notfallmaßnahmen):

• Geplante Wartungsfenster: Hierunter fallen regelmäßige, vorab angekündigte Arbeiten. Man definiert feste Zeitfenster, in denen der Service planmäßig nicht oder nur eingeschränkt verfügbar sein darf, ohne dass dies als SLA-Verstoß gilt. Viele Anbieter legen diese Fenster in verkehrsarme Zeiten, z. B. nachts oder am Wochenende. Ein Beispiel: „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 „max. 1 Stunde planmäßige Wartung pro Monat“. Wichtig ist die Vorankündigungsfrist: Geplante Downtimes müssen rechtzeitig mitgeteilt werden. Typisch sind mindestens 24 Stunden vorher, besser einige Tage. So bemüht sich z. B. Bynder, Wartungen 5 Tage im Voraus anzukündigen (mindestens jedoch 24 h vorher). Durch diese Kombination – beschränkte Häufigkeit/Dauer und rechtzeitige Ankündigung – können Kunden Wartungsfenster einplanen, ohne überraschende Ausfälle befürchten zu müssen.
• Ungeplante (außerplanmäßige) Wartung: Darunter fallen Notfälle – etwa sicherheitskritische Updates oder unvorhergesehene technische Probleme, die sofortiges Handeln erfordern. Auch hier sollte das SLA regeln, wie solche Fälle behandelt werden. Best Practice ist, dass der Anbieter nach Möglichkeit auch Notfall-Eingriffe zumindest kurz vorher ankündigt (z. B. per E-Mail oder Status-Seite) und auf die geringstmögliche Beeinträchtigung achtet. In manchen SLA wird festgelegt, dass ungeplante Wartung außerhalb der definierten Wartungsfenster als Downtime zählt, falls nicht mindestens z. B. 24 h vorher informiert wurde. Damit soll verhindert werden, dass der Anbieter einfach spontane Wartungen durchführt und sie im Nachhinein als „geplant“ deklariert. Für absolute Notfälle (z. B. akute Security-Lücke) wird man trotzdem Ausnahmen zulassen – allerdings sind solche Fälle selten und sollten als Force-Majeure oder ähnliche Klausel separat behandelt werden.

Als Faustregeln für Wartungsklauseln gelten: Geplante Wartungen klar definieren (Zeiten, Dauer) und von der Verfügbarkeitsberechnung ausnehmen, diese Wartungen frühzeitig ankündigen, und ungeplante Eingriffe nur im Notfall zulassen. So behält der Anbieter die nötige Flexibilität für Betrieb und Updates, ohne dass Kunden die vereinbarte Uptime anzweifeln müssen.

Support-Level und Reaktionszeiten nach Priorität

Neben der technischen Verfügbarkeit sollte ein SLA auch den Support abdecken: Wie schnell reagiert der Anbieter, wenn der Kunde ein Problem meldet? Gerade für B2B-Kunden ist eine professionelle Support-Vereinbarung wichtig, um Betriebsstörungen zügig zu beheben. Üblich ist es, Störungsmeldungen nach Dringlichkeit zu priorisieren und für jede Prioritätsstufe bestimmte Reaktionszeiten festzulegen:

• 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, z. B. 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: Bedeutende Funktionseinschränkungen, bei denen jedoch ein Workaround existiert oder das System noch eingeschränkt läuft. Reaktionszeiten sind hier etwas länger, z. B. innerhalb 4 Stunden.
• Priorität 3 – Mittlere/Niedrige Priorität: Kleinere Bugs, allgemeine Anfragen oder nicht dringliche Probleme. Hier genügen längere Reaktionszeiten, z. B. innerhalb von 24 Stunden oder bis zum nächsten Geschäftstag.

Diese Beispiele zeigen ein mögliches Schema (oft auch in P1/P2/P3 kategorisiert). Wichtig: Das SLA sollte auch definieren, wann die Uhr läuft. Häufig gelten Reaktionszeiten nur innerhalb definierter Supportzeiten – etwa Montag bis Freitag, 8:00–18:00 Uhr. Beispielsweise bedeutet „Reaktionszeit 1 Stunde“ unter Geschäftszeit-Bedingungen, dass eine kritische Störung, die Freitag um 22:00 Uhr gemeldet wird, erst am nächsten Werktag um 9:00 Uhr bearbeitet werden muss. Wer 24/7-Support bieten möchte, muss dies ausdrücklich zusagen (für Startups oft eine Kostenfrage). Alternativ kann man Premium-Support mit erweiterten Zeiten gegen Aufpreis anbieten.

Zusätzlich zur Reaktionszeit wird manchmal eine Lösungszeit (Time-to-Resolve) vereinbart – z. B. dass bei P1-Störungen innerhalb von 4 oder 8 Stunden eine Lösung oder zumindest ein Workaround bereitgestellt sein muss. Dies ist aber 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, dass Support-Prozesse klar beschrieben werden: Wie meldet der Kunde Störungen (Ticketsystem, Hotline?), und wie wird priorisiert. Ein transparentes Verfahren erhöht das Kundenvertrauen und verhindert falsche Erwartungen.

Vertragsstrafen und Gutschriften bei SLA-Verletzungen

Kein SLA ist vollständig ohne Regelungen, was passiert, wenn der Anbieter die zugesagten Service Levels nicht einhält. 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 – quasi eine Geld-zurück-Garantie in Form einer Gutschrift, die der Kunde bei Nichterreichen der SLA anfordern kann.

Typische Modelle für Service Credits: Oft vereinbaren Provider und Kunde einen bestimmten Prozentsatz der monatlichen Gebühr, der gutgeschrieben wird, abhängig davon, wie stark das SLA verfehlt wurde. 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: „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 bekommt 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 (z. B. auf höchstens die Hälfte eines Monatsentgelts). Dieses Modell soll einen Anreiz zur Leistung schaffen, den Anbieter aber nicht übermäßig bestrafen.

Grenzen von Service Credits: Wichtig ist, 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 (z. B. „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. Außerdem wird in vielen SLAs festgelegt, dass **Service Credits das exklusive Rechtsmittel des Kunden sind, also anstelle anderer Gewährleistungs- oder Schadensersatzansprüche gewährt werden. So versucht der Anbieter zu verhindern, dass der Kunde trotz Gutschrift noch weitere Ansprüche (wie entgangenen Gewinn etc.) geltend macht. Allerdings ist Vorsicht geboten: Diese Haftungsbeschränkung muss im Rahmen des deutschen Rechts zulässig sein (siehe nächster Abschnitt).

Vertragsstrafe vs. pauschalierter Schadensersatz: Juristisch gesehen sind Service Credits eine Form von pauschaliertem Schadensersatz oder Vertragsstrafe, je nach Ausgestaltung. Eine Vertragsstrafe („Konventionalstrafe“) 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. Wichtig: Höhe und Voraussetzungen der Gutschriften sollten im Vertrag eindeutig bestimmt sein (am besten objektiv messbar, z. B. Prozentsätze, Zeiten). Und: Kein Anbieter wird einer unbegrenzten Strafzahlung zustimmen – daher sind Kappungsgrenzen (ceiling) gängig, wie im obigen Beispiel 50 % der Monatsgebühr. Darüber hinaus kann man Sonderkündigungsrechte vereinbaren: Bei schwerwiegenden SLA-Verletzungen (z. B. Verfügbarkeit fällt über längere Zeit weit unter zugesagten Wert) 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, da die SLAs meist als vorgefertigte Vertragsbedingungen gelten. Eine vermeintlich clevere Klausel nützt nichts, wenn sie vor Gericht unwirksam ist. Folgende Punkte sollten beachtet werden:

• Keine „überraschenden“ Klauseln: Vertragsbedingungen, die so ungewöhnlich sind, dass der Kunde vernünftigerweise nicht mit ihnen rechnen musste, werden nicht Vertragsbestandteil (§ 305c BGB). Daher sollten wichtige SLA- und Haftungsklauseln transparent und deutlich formuliert sein, nicht im Kleingedruckten versteckt.
• Haftung für grobes Verschulden nicht ausschließen: In AGB unzulässig ist der Ausschluss oder die Begrenzung der Haftung für Vorsatz und grobe Fahrlässigkeit. Ebenso nicht abdingbar sind Schäden aus 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 also nie den Eindruck erwecken, der Anbieter hafte auch bei eigenem Vorsatz oder grober Fahrlässigkeit nicht – das wäre rechtlich nicht haltbar.
• „Garantie“ vorsichtig verwenden: Wird im SLA eine Leistung ausdrücklich als Garantie zugesagt, hat das zur Folge, dass bei Nichteinhaltung die Haftung nicht durch andere Klauseln begrenzt werden kann. Beispiel: Wenn der Anbieter „garantiert, dass die Verfügbarkeit 99,9 % beträgt“, könnte dies als selbständige Garantieverpflichtung ausgelegt werden – dann greift die gesetzliche Garantieliabilität (§ 444 BGB analog) und ein Haftungsausschluss dafür wäre unwirksam. Daher raten Juristen, stattdessen Begriffe wie „zusichern“ oder „vereinbaren“ zu verwenden und die Rechtsfolgen der Nichteinhaltung explizit im SLA zu regeln (eben durch Service Credits etc.), anstatt unbedacht das Wort Garantie zu nutzen.
• Haftung bei leichter Fahrlässigkeit: Für Fälle einfacher (leichter) Fahrlässigkeit kann die Haftung in AGB grundsätzlich beschränkt werden – allerdings 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. Mit anderen Worten: 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 z. B., eine Klausel „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 (etwa Mietminderung, siehe unten). Zulässig ist aber, die Haftung der Höhe nach zu begrenzen (etwa auf einen bestimmten Betrag oder auf die Summe der gezahlten Entgelte), sofern eben die Kernpflichten nicht gänzlich aus der Haftung genommen werden.
• Keine pauschale Ausschlüsse für bestimmte Schadenstypen, wenn diese den Kunden stark beeinträchtigen: Oft versuchen Anbieter, 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. Beispielsweise ist ein völliger Ausschluss für Datenverlust problematisch, wenn der SaaS-Anbieter per Vertrag Datensicherheit schuldet – ein Totalhaftungsausschluss würde den Kunden unzumutbar benachteiligen. Besser ist, die Haftung für solche Folgeschäden auf Vorsatz und grobe Fahrlässigkeit zu begrenzen, aber nicht für jede Fahrlässigkeit auszuschließen. Zudem sollten Kunden vertraglich auf Backup-Pflichten hingewiesen werden, um die Risikoverteilung fair zu gestalten (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 Verbraucher-Verträgen sind Vertragsstrafen in AGB nach § 309 Nr. 6 BGB generell unzulässig. In B2B-Verträgen sind sie zulässig, aber die Höhe unterliegt Grenzen: Der BGH hat entschieden, dass in AGB vereinbarte Vertragsstrafen, die 5 % des Auftragswertes übersteigen, in der Regel unwirksam sind. Das heißt, eine Klausel, die dem SaaS-Kunden z. B. 10 % Monatsgebühr als Strafe pro Ausfallstunde zuspricht, würde diese Schwelle sprengen und könnte kassiert werden. Daher: Wenn Strafen, dann niedrig dimensioniert und besser individuell aushandeln, statt in AGB fix zu hoch anzusetzen.
• Mietminderung und gesetzliche Gewährleistung: Da SaaS rechtlich oft als Mietvertrag eingeordnet wird (Bereitstellung der Software gegen Entgelt entspricht Gebrauchsüberlassung), steht dem Kunden bei Mängeln grundsätzlich das Recht zur Mietminderung nach § 536 BGB zu. Eine Unterverfügbarkeit der Software (Downtime über das vertraglich zulässige Maß hinaus) könnte als Mietmangel gelten, der eine Gebührenminderung oder sogar Schadenersatz ermöglicht. Viele Anbieter versuchen, dieses gesetzliche Minderungsrecht durch die SLA-Regelung zu ersetzen – z. B. indem sie festlegen, dass Service Credits die exklusiven Ansprüche des Kunden sind. Eine solche Klausel muss aber 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, 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.

Zusammengefasst: Eine rechtssichere SLA-Gestaltung muss die Balance wahren zwischen klar definierten, für Kunden hilfreichen Zusagen und wirksamen Haftungsbegrenzungen für den Anbieter. Überraschungen und Einseitigkeiten gilt es zu vermeiden. Im Zweifel sollten SLA-Klauseln einfach und fair gehalten werden, damit sie im Ernstfall Bestand haben und nicht vor Gericht gekippt werden.

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, und es gibt gleichzeitig 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, während klar definierte Wartungsfenster dem Betreiber genügend Raum für Updates und Pflege lassen – ohne versteckte Ausfälle. Gestufte Support-Level mit schnellen Reaktionszeiten für kritische Probleme zeigen Professionalität und Kundennähe. Und im Falle der Fälle 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: Was nützt die beste SLA-Klausel, wenn sie vor Gericht nicht hält? Indem man die AGB-rechtlichen Leitplanken einhält – keine unzulässigen Haftungsausschlüsse, angemessene Regelungen bei Pflichtverletzungen – wird das SLA rechtssicher. 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. Damit wird die Zusammenarbeit 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.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.