Erstellen Sie eine App für eine Klauselbibliothek, um genehmigte Klauseln zu speichern, zu taggen und zu durchsuchen sowie schneller Entwürfe mit einheitlicher Sprache und weniger Fehlern zusammenzustellen.
Vertragsprüfungen ziehen sich oft nicht hin, weil die Arbeit schwer ist, sondern weil die Formulierungen verstreut sind. Wenn Klauseln in E‑Mail‑Threads, auf gemeinsamen Laufwerken und in „final‑final“ Word‑Dateien leben, verschwenden Prüfer Zeit damit, die richtige Version zu suchen. Und sie zweifeln sie trotzdem an, weil sie nicht erkennen können, was zuletzt verwendet wurde.
Nacharbeit bremst als Nächstes. Wenn zwei Personen von unterschiedlichen Vorlagen starten, kann dasselbe Thema (z. B. Haftung, Zahlungsbedingungen oder Kündigung) dreifach anders formuliert sein. Legal muss dann Unterschiede ausgleichen, erklären, warum eine Version sicherer ist, und kleine Änderungen korrigieren, die gar nicht hätten passieren dürfen. Dieses Hin und Her kostet Tage, vor allem wenn Sales, Procurement und Legal jeweils verschiedene Drafts markieren.
Wenn Teams von „genehmigter Sprache“ sprechen, meinen sie meist etwas Spezifisches: Text, der geprüft wurde, für einen bekannten Anwendungsfall akzeptiert ist und mit Leitplanken verknüpft ist. Dazu gehört, wann er verwendet werden darf, welche Jurisdiktion passt und welche Teile nicht bearbeitet werden dürfen. Ohne diesen Kontext kopiert jemand eine Klausel, die richtig klingt, aber veraltet ist oder eine wichtige Definition vermissen lässt.
Eine Klauselbibliothek‑App lohnt sich, wenn dieselben Probleme Woche für Woche auftauchen:
Sobald diese Symptome auftreten, ist eine gemeinsame Klauselbibliothek kein Nice‑to‑have mehr. Sie wird zum einfachsten Weg, Suchzeit zu reduzieren, Formulierungen konsistent zu halten und Reviews von Umschreiben hin zu prüfen der wenigen deal‑spezifischen Änderungen zu verlagern, die wirklich zählen.
Eine Klauselbibliothek‑App ist ein gemeinsamer Ort, an dem Ihr Team die Klauseln speichert, denen es vertraut, plus den Kontext, der nötig ist, sie korrekt zu nutzen. Statt in alten Deals zu wühlen, suchen, vergleichen und wiederverwenden Sie Texte, die bereits geprüft wurden.
Die meisten Teams verwalten praktisch vier Bausteine:
Ein guter Klausel‑Eintrag ist mehr als Text. Er enthält Details, die Fehler verhindern: eine kurze Erklärung, warum die Klausel existiert, wann sie sicher ist, für welche Deals sie passt, wer sie besitzt (Legal, Procurement, Security) und Basis‑Metadaten wie Jurisdiktion, Risikoniveau, letzte Prüfung und Genehmigungsstatus.
Das unterscheidet sich von einem Ordner voller Vorlagen. Vorlage‑Ordner speichern ganze Dokumente, oft ohne klare Zuständigkeit oder Änderungshistorie. Eine Klauselbibliothek speichert wiederverwendbare Teile, sodass Sie mixen und matchen können und dennoch im Playbook bleiben.
Im Alltag sieht „Entwürfe aus Bausteinen zusammenstellen“ so aus: Ein Sales‑Mitarbeiter übermittelt Deal‑Basics (Land, Laufzeit, Vertragswert). Der Prüfer wählt eine Basisvereinbarung, tauscht dann passende Zahlungsbedingungen, Datenschutz‑Variante und Haftungs‑Fallback gemäß Playbook ein. Der Entwurf wird mit konsistenter Sprache erstellt und die Bibliothek protokolliert, welche genehmigten Klauseln verwendet wurden.
Wenn Sie das in einem Tool wie AppMaster bauen, halten Sie es einfach: eine Klausel‑Detailseite, eine Such‑ und Filteransicht und ein Draft‑Builder, der genehmigte Textblöcke in ein Dokument zieht.
Eine Klauselbibliothek‑App spart nur Zeit, wenn sie dem tatsächlichen Prüfverhalten entspricht. Die besten Lösungen fühlen sich an wie ein gut organisiertes Aktenschränkchen mit schneller Suche, nicht wie eine komplizierte juristische Datenbank.
Beginnen Sie mit Kategorien, die reale Arbeit widerspiegeln. Viele Teams denken zuerst in Dokumenttypen, wie NDA, MSA, DPA und SOW. Wenn Kategorien zur Anfrage passen, verbringen Prüfer weniger Zeit damit, zu raten, wo eine Klausel liegen sollte.
Tags sind die zweite Ebene, die alles zusammenbringt. Verwenden Sie Tags für Dinge, die sich von Deal zu Deal ändern, wie Jurisdiktion, Risikoniveau, Kundentyp oder ob eine Klausel „Fallback“ vs. „Preferred“ ist. Halten Sie Tags konsistent (ein Format, eine Bedeutung), sonst wird Filtern chaotisch.
Die Suche sollte sich so verhalten, wie Menschen es erwarten:
Klauseln brauchen zudem einen einfachen Status‑Lebenszyklus. „Draft“ für Arbeit in Arbeit. „Approved“ für die standardmäßig zu nutzende Fassung. „Deprecated“ bewahrt alte Formulierungen zur Referenz, ohne zur Wiederverwendung zu ermutigen.
Ein Notizfeld sollte schnelle Hinweise geben. Ein oder zwei Sätze wie „Für Enterprise‑Kunden in den USA verwenden“ oder „Nicht verwenden, wenn Zahlungsbedingungen > 30 Tage“ verhindern viele Fehlgriffe.
Wenn Sie das in AppMaster bauen, zielen Sie auf ein sauberes Datenmodell (Klauseln, Kategorien, Tags, Status) und eine UI, die Suche und Klarheit über zusätzliche Bildschirme stellt.
Eine Klauselbibliothek bleibt nur nutzbar, wenn das Datenmodell langweilig und vorhersehbar bleibt. Starten Sie mit fünf Objekten: Clauses (der Text), Categories (wie Leute browsen), Tags (wie Leute suchen), Templates (Standard‑Vereinbarungen oder Abschnitte) und Drafts (ein Arbeitsdokument aus ausgewählten Klauseln).
Behalten Sie Categories als Einzelwahl pro Klausel (one‑to‑many). Das vermeidet endlose Debatten darüber, wo etwas „wirklich“ hingehört. Nutzen Sie Tags für alles Flexible: Jurisdiktion, Risikoniveau, Business Unit, Kundentyp und ähnliche Dimensionen.
Tags sind natürlich many‑to‑many. Der saubere Ansatz ist eine Join‑Tabelle (z. B. ClauseTag mit clause_id und tag_id). So vermeiden Sie doppelte Tags, unordentliche Benennungen und „fast gleiche“ Labels. In Tools wie AppMaster lässt sich das im Data Designer auf PostgreSQL leicht einrichten.
Behandeln Sie Klauseltext als etwas, das sich über die Zeit ändert. Speichern Sie Versionen, damit Sie beantworten können, was sich geändert hat, wer es getan hat und wann. Ein einfaches Muster ist ein Clause‑Datensatz (aktueller Status, Kategorie) plus ClauseVersion‑Datensätze (Text, Änderungsnotiz, created_by, created_at).
Speichern Sie außerdem die Verhandlungsrealität, nicht nur die ideale Formulierung. Eine Haftungs‑Klausel kann Fallback‑Optionen und Hinweise wie „Preferred“, „Acceptable“ und „Do not accept“ sowie eine kurze Begründung enthalten.
Machen Sie einige Felder verpflichtend, damit Suche und Governance funktionieren:
Den Rest leichtgewichtig und optional halten (Jurisdiktionsnotizen, Fallback‑Wording, Verhandlungsposition, Quelle, interne Kommentare).
Beispiel: Wenn Sales eine schnellere NDA braucht, kann ein Prüfer „NDA – Vertraulichkeit“ ziehen, die genehmigte Version wählen und das akzeptable Fallback sehen, falls die Gegenpartei Druck macht.
Eine Klauselbibliothek spart nur Zeit, wenn Leute den richtigen Text in Sekunden finden. Das liegt an ordentlichen Tags und einer fehlertoleranten Suche.
Starten Sie mit Tagging‑Regeln, die sich Leute merken können. Wenn Nutzer stehen bleiben müssen, um nachzudenken, werden sie Tags überspringen oder neue erfinden.
Halten Sie die Tag‑Sets klein und stabil in Version eins (z. B. Jurisdiktion, Risikoniveau, Klauseltyp, Fallback‑Position). Verwenden Sie klare Begriffe statt interner Spitznamen. Vermeiden Sie Tag‑Kombinationen, sofern Sie sie nicht wirklich brauchen. Weisen Sie jeder Tag‑Gruppe einen Owner zu, damit Änderungen überlegt sind, und prüfen Sie neue Tags in den ersten Wochen wöchentlich, um Duplikate früh zu entdecken.
Die Suche sollte Teil‑Treffer und gängige Variationen abfangen. Nutzer erinnern selten den exakten Klausel‑Titel und fügen oft einen Satz aus einer E‑Mail oder einem Redline ein. Hervorhebungen in den Ergebnissen helfen sofort zu verstehen, warum ein Treffer erschien.
Gespeicherte Filter sind ein unterschätztes Feature. Sie verwandeln eine zweiminütige Suche in einen zehnsekündigen Klick für wiederkehrende Aufgaben. Typische Beispiele: EU + hohes Risiko + Zahlungen oder US + niedriges Risiko + Standard‑Fallback.
Tag‑Wucher beginnt meist mit Duplikaten („NDA“ vs. „Confidentiality") und überlappenden Konzepten („Jurisdiction“ vs. „Governing law"). Wenn Sie Überschneidungen sehen, mergen Sie schnell und leiten alte Tags um, damit nichts bricht.
Schließlich: Vorschaukarten in der Ergebnisliste. Zeigen Sie Klauselname, Schlüssel‑Tags, Datum der letzten Genehmigung und einen kurzen Ausschnitt. So öffnen Prüfer nicht zehn Einträge, nur um kleine Unterschiede zu vergleichen.
Wenn Sie das in AppMaster bauen, reicht oft eine Kombination aus Tag‑Gruppen, gespeicherten Views und einer Suchergebnis‑Seite mit Vorschau‑Feldern, damit die Bibliothek sich am ersten Tag schnell anfühlt.
Eine Klauselbibliothek ist dann am nützlichsten, wenn sie hilft, einen sauberen ersten Entwurf schnell zu produzieren, ohne aus alten Dateien per Copy‑Paste zu arbeiten. Drafting sollte sich anfühlen wie Zusammensetzen von Bausteinen, nicht wie Schreiben von Grund auf.
Starten Sie mit einer Vorlage, die zum Deal‑Typ passt (z. B. NDA, MSA oder SaaS Order Form). Fügen Sie dann Klauseln aus Ihrem genehmigten Bestand hinzu und ordnen Sie sie in der erwarteten Reihenfolge an.
Ein praktischer Ablauf:
Um manuelle Änderungen zu reduzieren, nutzen Sie Platzhalter in Klauseln. Halten Sie sie vorhersehbar, z. B. {CompanyName}, {EffectiveDate}, {GoverningLaw} oder {PricingTerm}. Die App sollte diese Werte einmal abfragen und dann überall einsetzen.
Wenn jemand vom genehmigten Wortlaut abweichen muss, erfassen Sie den Grund genau in dem Moment. Eine kurze Notiz wie „Customer requested net‑60 payment terms“ oder „Liability cap an procurement policy angepasst“ reicht meist. Später sehen Prüfer, was geändert wurde und warum, ohne Nachrichten durchforsten zu müssen.
Der Export ist oft die Schwachstelle vieler Tools. Planen Sie Ausgaben, die tatsächlich nutzbar sind: kopierfertiger Text mit sauberer Formatierung, Überschriften mit konsistenter Nummerierung, optionale interne Kommentare und eine Vergleichsansicht (genehmigte Klausel vs. bearbeitete Klausel).
Kollaborationsregeln sollten offensichtlich sein: Drafters können editieren, Reviewer kommentieren, und nur Approver finalisieren. In AppMaster können Sie Rollen und Genehmigungen visuell modellieren, sodass der Workflow die Regeln durchsetzt.
Eine Klauselbibliothek bleibt nur nützlich, wenn Leute ihr vertrauen. Das erfordert klare Rollen, vorhersehbare Freigaben und eine Historie, auf die Sie verweisen können, wenn jemand fragt: „Wer hat das geändert und warum?"
Die meisten Teams kommen mit vier Rollen gut zurecht: Contributors schlagen neue Klauseln und Änderungen vor, Reviewer prüfen Qualität und Passform, Approver (oft Legal) geben die finale Freigabe, und Admins verwalten Struktur, Zugriffe und Templates.
Halten Sie Genehmigungstore simpel. Alles, was Risiko oder Verpflichtung ändert, braucht Sign‑off. Formatierungen und Metadaten dürfen self‑serve sein. Tags ändern, Tippfehler beheben oder eine Klausel in eine passendere Kategorie verschieben sollte die Arbeit nicht blockieren. Indemnity‑Sprache, Haftungslimits oder Datenschutz‑Änderungen sollten es jedoch.
Eine praktische Regelung:
Ein Audit‑Trail ist Pflicht. Jede Klausel sollte Versionshistorie zeigen (wer, was, wann), eine kurze „Warum“‑Notiz erlauben und das Wiederherstellen vorheriger Versionen unterstützen. In AppMaster nutzen Sie das Auth‑Modul, speichern jede Version als separaten Datensatz und steuern Änderungen mit rollenbasierten Berechtigungen und einem einfachen Approval‑Workflow.
Planen Sie Deprecation, nicht Löschung. Alte Klauseln können noch in aktiven Verträgen auftauchen, also halten Sie sie durchsuchbar, markieren Sie sie klar als „Deprecated“ mit kurzem Grund und nennen Sie die Ersatzklausel.
Behandeln Sie sensible Inhalte vorsichtig. Sperren Sie eingeschränkte Klauseln in geschützten Kategorien, begrenzen Sie die Ansicht auf bestimmte Gruppen und protokollieren Sie jede Ansicht und jeden Export.
Starten Sie klein. Die erste Version sollte die Klauseln abdecken, die Sie jede Woche nutzen, nicht jede denkbare Klausel. Ein gutes Ziel sind 50–200 Klauseln, gruppiert in einige klare Kategorien (z. B. Vertraulichkeit, Haftung, Kündigung, Datenschutz, Zahlung).
Bevor Sie bauen, schreiben Sie ein einseitiges Regelblatt: wie Klauseln benannt werden, was „approved“ bedeutet und welche Tags Pflicht sind. Das verhindert, dass die Bibliothek zu einem unordentlichen Ordner mit Nahe‑Duplikaten wird.
Ein praktischer Plan für die erste Version:
Wenn Sie eine No‑Code‑Plattform wie AppMaster nutzen, können Sie das direkt in ein DB‑Modell und UI‑Screens abbilden und Genehmigungslogik visuell ergänzen.
Testen Sie mit zwei oder drei echten Verträgen aus aktuellen Anfragen. Nehmen Sie etwas, das normalerweise Verhandlung bei Haftung und Datenschutz auslöst. Bauen Sie den Draft aus wiederverwendbaren Teilen und notieren Sie, was fehlt: ein gängiges Fallback, ein benötigter Tag oder ein klarerer Klauseltitel. Beheben Sie diese Punkte sofort — so wird die Bibliothek mit jedem Test schneller.
Ein Sales‑Manager schreibt: „Wir brauchen heute einen MSA‑Entwurf für einen Mid‑Market‑Kunden. Sie möchten ein höheres Haftungslimit, könnten aber ein Fallback akzeptieren.“
In einer Klauselbibliothek‑App beginnt die Anfrage mit Filtern, nicht mit einem leeren Dokument. Der Nutzer wählt Agreement Type = MSA, Customer Segment = mid‑market, Risk Level = standard, Topic = limitation of liability.
Er sucht nach „liability cap“ und sieht genehmigte Optionen, gruppiert nach Kategorie. Eine Klausel ist als preferred markiert (Cap = Fees paid in 12 months). Eine andere ist als fallback markiert (Cap = 2x Fees, indirect damages ausgeschlossen). Da Klauseln getaggt sind, kann der Nutzer schnell einen Filter wie „SaaS“ oder „security addendum present“ hinzufügen, um Fehlzuordnungen zu vermeiden.
Wie die 30 Minuten typischerweise aussehen:
Wichtig ist, was danach passiert. Legal speichert die bearbeitete Haftungsklausel als neue Variante, taggt sie „mid‑market – higher cap requested“ und protokolliert, wer sie wann genehmigt hat. Beim nächsten Mal startet Sales von einer bereits genehmigten Option.
Die meisten Klauselbibliotheken scheitern aus einem einfachen Grund: Sie sammeln Dokumente, keine Bausteine. Eine Klauselbibliothek sollte Ihnen helfen, kleine, klare Teile mit Vertrauen wiederzuverwenden.
Häufige Probleme und Lösungen:
Ein schnelles Beispiel: Ein Sales‑Rep sucht „limitation of liability“ und findet drei ähnliche Klauseln. Wenn jede einen Hinweis wie „Für SMB‑Jahresverträge unter $50k verwenden“ und die letzte genehmigte Version zeigt, fällt die Auswahl leicht.
Wenn Sie das in AppMaster bauen, behandeln Sie diese Schutzmaßnahmen als Kernanforderungen, nicht als spätere Ergänzungen. Sie machen Wiederverwendung sicher, nicht nur schnell.
Bevor Sie das ganze Team einladen, führen Sie einen kurzen „Kann man das unter Druck nutzen?“‑Test durch. Wählen Sie einen realen Vertragstyp (z. B. NDA oder MSA), lassen Sie zwei Personen dieselbe Aufgabe erledigen und beobachten Sie, wo sie stocken. Ziel ist Geschwindigkeit, Sicherheit und weniger Einzeländerungen.
Eine Rollout‑Checkliste, die die meisten Probleme früh auffängt:
Führen Sie einen realistischen Dry‑Run durch, z. B.: „Kunde verlangt Haftungslimit‑Änderung und eine einseitige Vertraulichkeits‑Ausnahme.“ Messen Sie, wie lange es dauert, die passenden Optionen zu finden, in den Entwurf einzufügen und die Gründe zu dokumentieren.
Wenn Sie das als Klauselbibliothek‑App in AppMaster bauen, fokussieren Sie die erste Version: Klausel‑Datensätze mit Metadaten (Owner, Status, zuletzt geprüft), einen leichten Approval‑Schritt und eine klare Möglichkeit, einen Draft aus einer Vorlage plus ausgewählten Klauseln zusammenzustellen.
Starten Sie gezielt klein. Wählen Sie einen Vertragstyp (z. B. NDAs), ein Team (Sales Ops oder Procurement) und einen einfachen Workflow (Anfrage, zusammenstellen, genehmigen, exportieren). Ein kleiner Pilot macht Probleme sichtbar, während die Risiken gering sind.
Entscheiden Sie, wo die Bibliothek leben soll und wer sie besitzt. Eine Klauselbibliothek scheitert, wenn „alle“ sie pflegen sollen — dann tut es keiner. Ernennen Sie einen monatlichen Owner, der neue Klauseln prüft, veraltete Sprache zurückzieht und kontrolliert, dass Tags noch dem Suchverhalten entsprechen.
Planen Sie Integrationen für später, aber blockieren Sie den Piloten nicht darauf. Häufige Phase‑2‑Bedürfnisse: Single Sign‑On, Benachrichtigungen (E‑Mail oder Chat), Approval‑Routing und Klauseln, die Deal‑Daten einziehen.
Wenn Sie schnell bauen wollen ohne viel Programmierung, kann AppMaster (appmaster.io) eine praktische Option sein, weil es Backend, Web‑App und Mobile App in einem No‑Code‑Projekt abbildet und Deployment in Ihre bevorzugte Cloud erlaubt.
Messen Sie den Erfolg mit ein paar einfachen Kennzahlen und prüfen Sie diese alle zwei Wochen während des Piloten:
Nach zwei bis vier Wochen ändern Sie immer nur eine Sache: Tags anpassen, Duplikate mergen, ein fehlendes Fallback ergänzen oder Berechtigungen straffen. Kleine, stetige Verbesserungen sind es, die einen Piloten in ein vertrauenswürdiges Tool verwandeln.
Wann lohnt sich der Aufbau einer Klauselbibliothek‑App?Bauen Sie eine, wenn dieselben Anfragen wiederkehren und Reviews daran scheitern, „die Standardklausel“ zu finden, Near‑Duplicates zu vergleichen oder zu erörtern, welche Version aktuell ist. Wenn Legal und Sales mehr Zeit mit Suchen und Abstimmen der Formulierungen verbringen als mit der Prüfung deal‑spezifischer Änderungen, zahlt sich eine gemeinsame Bibliothek meist schnell aus.
Worin unterscheidet sich eine Klauselbibliothek von einem Ordner voller Vorlagen?Eine Vorlagen‑Ordner speichert ganze Dokumente, was dazu führt, dass Leute kopieren und einheitliche Formulierungen verloren gehen. Eine Klauselbibliothek speichert wiederverwendbare Abschnitte mit Kontext, sodass Sie die richtige Klausel, Variante oder das Fallback auswählen und wissen, wann ihre Nutzung sicher ist.
Welche Mindestdaten sollten für jede Klausel gespeichert werden?Beginnen Sie mit einem einfachen Klausel‑Datensatz: klarer Titel, eine Kategorie, aktueller Text, Status und ein Owner. Ergänzen Sie Tags für flexible Dimensionen wie Jurisdiktion oder Risikoniveau. Halten Sie den Rest optional, damit die Leute die Pflege tatsächlich durchführen.
Wie sollte Klausel‑Versionierung funktionieren?Speichern Sie Klauseltexte als Versionen, damit Sie beantworten können, was sich geändert hat, wer es geändert hat und warum. Halten Sie einen „aktuellen“ Eintrag fürs Browsen und hängen Sie Versionsdatensätze mit Änderungsnotizen an.
Wie verhindert man, dass Tags außer Kontrolle geraten?Nutzen Sie eine kleine, stabile Menge an Tag‑Gruppen, die reales Suchverhalten abbilden (z. B. Jurisdiktion, Risikoniveau, Vertragstyp, Fallback‑Position). Bestimmen Sie einen Owner für Tags und führen Sie Duplikate frühzeitig zusammen, damit Filter sauber und vorhersehbar bleiben.
Was ist die einfachste Methode, einen Entwurf aus Klauseln zusammenzustellen?Verwenden Sie eine Vorlage als Skelett, fügen Sie genehmigte Klauseln ein und ordnen Sie die Abschnitte neu, um einen sauberen Entwurf zu erhalten. Nutzen Sie Platzhalter wie {CompanyName} oder {GoverningLaw}, damit Werte einmal eingegeben überall ersetzt werden.
Wer sollte Klauseln bearbeiten oder genehmigen dürfen?Definieren Sie klare Rollen: Contributors schlagen Änderungen vor, Reviewer prüfen die Eignung, Approver veröffentlichen genehmigte Sprache, und Admins verwalten Struktur und Zugriffe. Lassen Sie niedriges Risiko (Metadaten, Tippfehler) self‑serve, verlangen Sie aber Freigabe bei inhaltlichen Änderungen an hochriskanten Klauseln.
Sollte man veraltete Klauseln löschen oder behalten?Nicht löschen — deprecate. Alte Klauseln können noch in aktiven Verträgen stehen. Markieren Sie sie klar als „Deprecated“, nennen Sie einen kurzen Grund und verweisen Sie auf die Ersatzklausel, damit Nutzer sie nicht wiederverwenden.
Welche Exportoptionen sollte die App unterstützen?Bieten Sie Ausgaben, die sofort nutzbar sind: sauberer, kopierfertiger Text, konsistente Überschriften und Nummerierung sowie optional interne Hinweise. Wenn Nutzer keinen brauchbaren Export erhalten, greifen sie wieder auf alte Word‑Dateien zurück.
Kann ich das ohne aufwändige Programmierung bauen und wie passt AppMaster dazu?Ein No‑Code‑Ansatz funktioniert gut, wenn Sie die erste Version klein halten: Klauseln, Kategorien, Tags, Versionen und ein einfacher Draft‑Builder mit Genehmigungen. In AppMaster können Sie das Datenmodell in PostgreSQL abbilden, die Web‑UI für Suche und Klauselansichten bauen und Rollenbasierte Freigaben mit visuellen Workflows umsetzen, dann während eines kurzen Piloten iterieren.
10. März 2026
9 Min
08. März 20268 Min
07. März 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
