Erstelle einen einseitigen Generator für Dienstleistungsverträge, der Kundendaten sammelt, klare Bedingungen zeigt und in einem flüssigen Ablauf eine Signatur erfasst.
E‑Mail‑Threads wirken anfangs einfach: „Klingt gut“, „Ja“, „Bestätigt.“ Dann startet das Projekt und alle erinnern sich anders an die Details. Eine kleine Frage wird zu 12 Antworten, jemand wird aus der Kette ausgeschlossen, und die „finale“ Version liegt an drei Orten.
Der größte Preis ist Zeit. Hin‑ und her erzeugt Pausen, während du auf Antworten wartest, alte Nachrichten durchsuchst oder erklären musst, was schon vereinbart wurde. Es schafft auch Risiko, weil wichtige Details angedeutet bleiben statt schriftlich festgehalten.
Wenn Vereinbarungen in E‑Mails leben, fehlen immer wieder dieselben Dinge: Umfangsgrenzen (was rein und raus ist), wichtige Daten, Zahlungsbedingungen, die korrekten Abrechnungsdaten und einfache Regeln für Änderungen.
Ein einseitiger Generator für Dienstleistungsverträge behebt das, indem er alles in einen Ablauf bringt: Kundendaten erfassen, klare Bedingungen neben den zugehörigen Feldern anzeigen und dann sofort eine Unterschrift einholen. Kunden müssen keine Anhänge suchen oder raten, welche Version korrekt ist. Du erhältst eine einzige Aufzeichnung, die du speichern, exportieren und bei Fragen wieder aufrufen kannst.
Einseiter funktionieren am besten, wenn das Geschäft klar und wiederholbar ist, wie Festpreis‑Pakete, monatliche Retainer oder Standard‑Onboardings. Sie eignen sich weniger, wenn die Arbeit komplex oder risikoreich ist. Brauchst du detaillierte Liefergegenstände, umfangreiche Compliance‑Sprache oder verhandelte Klauseln, brauchst du weiterhin einen längeren Vertrag.
Eine einfache Regel: Wenn du die Arbeit und die Zahlung in einem kurzen Gespräch erklären kannst, ohne alle 30 Sekunden „kommt drauf an“ zu sagen, reicht ein Einseiter meist aus. Wenn nicht, nutze den Einseiter für Intake und Unterschriftsabsicht und folge mit einem ausführlicheren Vertrag.
Ein einseitiger Generator für Dienstleistungsverträge hat eine Aufgabe: den Kunden vom „bereit zu starten“ zum „wir sind uns einig“ bringen, ohne zusätzliche E‑Mails, fehlende Details oder peinliche Nachfragen. Kann er keine wichtigen Infos sammeln, die Bedingungen bestätigen und die Unterschrift in einem flüssigen Durchgang erfassen, ist er nur ein weiteres Formular.
Ein solider Generator macht ein paar Dinge konstant richtig:
Halte die Seite kurz mit progressiver Offenlegung. Zeige zum Beispiel Zahlungsdetails erst, nachdem der Kunde eine Preisoption gewählt hat. Zeige Firmenfelder nur, wenn „Geschäftlich“ statt „Privat“ gewählt wird.
Entscheide vorher, wer es ausfüllt. Für viele Teams ist der schnellste Ablauf intern‑first: Du füllst Umfang und Preis vor, dann prüft und unterschreibt der Kunde. Nur‑Kunde kann ebenfalls funktionieren, führt aber eher zu mehr Hin‑und‑Her, es sei denn, dein Angebot ist sehr standardisiert.
Was er nicht tun sollte: so tun, als wäre er ein kompletter Vertragsersteller, Menschen mit langen Klauseln zu erschlagen oder das Onboarding in ein Verhör zu verwandeln. Vermeide komplexe Anhänge und mehrstufige Kontoerstellungen, es sei denn, du brauchst sie wirklich.
Wenn du einen Einseiter in Koder.ai baust, definiere „done“ praktisch: Der Kunde kann unterschreiben, du kannst die signierte PDF oder den Datensatz später abrufen, und beide Parteien haben einen Nachweis dessen, was vereinbart wurde.
Ein Einseiter funktioniert, wenn er nur Details abfragt, die wichtig werden, falls später jemand sagt: „So habe ich das nicht verstanden.“ Fühlt sich das Formular wie Bürokratie an, verlangsamen Kunden, brechen ab oder tippen Unsinn, um fertig zu werden.
Beginne mit einem eng gefassten Feldsatz, der klar auf die Vereinbarung abgebildet ist.
Halte den ersten Bildschirm kurz und vertraut. In den meisten Fällen decken diese Felder fast alles ab:
Füge dann einen kleinen Abrechnungsbereich hinzu, damit der Geldteil nicht missverstanden werden kann: Festpreis, Stundensatz, Meilenstein‑Beträge (falls genutzt) und Fälligkeitsdatum der Zahlung (z. B. „bei Erhalt fällig“ oder „net 7“). Bietest du sowohl Stunden‑ als auch Festpreis an, lass den Kunden eine Option wählen, damit keine widersprüchlichen Zahlen entstehen.
Optionale Details können helfen, sollten aber das Unterschreiben nicht blockieren. Mach sie einklappbar oder bedingt: Bestellnummer, Umsatzsteuer‑/Steuer‑ID oder ein zusätzlicher Rechnungsansprechpartner.
Eine einfache Regel: Wenn du es nicht verwenden wirst, frage nicht danach.
Ein paar Schutzmaßnahmen verhindern spätere Streitigkeiten:
Beispiel: Ein Kunde tippt „ACME“ und lässt die Adresse leer. Wenn dein Formular den vollständigen rechtlichen Namen und die Rechnungsadresse verlangt, bevor die Signatur freigeschaltet wird, ersparst du dir Nachfragen und deine Vereinbarung bleibt später brauchbar.
Ein Einseiter funktioniert am besten, wenn er die wenigen Dinge abdeckt, die tatsächlich zu Streit führen. Halte die Bedingungen kurz, benutze Alltagssprache und vermeide vage Versprechen wie „laufender Support“ oder „unbegrenzte Überarbeitungen“. Wenn du einen Begriff nicht in einem Satz erklären kannst, gehört er vermutlich nicht auf den Einseiter.
Beginne mit dem Umfang. Beschreibe in klarer Sprache, was du liefern wirst, und nenne, was ausgeschlossen ist. „Design und Aufbau einer 5‑seitigen Marketing‑Website“ ist klarer als „Webdesign‑Dienstleistungen“. Füge eine direkte Zeile für Ausschlüsse hinzu, z. B. „Texterstellung und SEO sind nicht eingeschlossen, es sei denn, sie werden schriftlich hinzugefügt."
Revisionen sind der nächste Zündstoff. Kunden hören „Revision“ oft als „neu anfangen“, also definiere, was als Revision gilt und was als Änderungsanforderung. Eine einfache Vorgehensweise ist, eine kleine Anzahl einzuschließen und zu benennen, was danach passiert.
Zahlungsbedingungen sollten direkt sein: Gesamtbetrag, wann er fällig ist und was bei Zahlungsverzug passiert (Spätgebühren nur aufnehmen, wenn du sie wirklich durchsetzen willst). Bei geteilten Zahlungen nenne die Auslöser: „50 % zu Projektbeginn, 50 % bei Lieferung."
Stornierung und Rückerstattung sollten explizit sein, auch wenn die Antwort „keine Rückerstattung nach Arbeitsbeginn“ lautet. Halte es fair und leicht verständlich.
Schließlich: Support‑Erwartungen. Ein Support‑Fenster ist kein ewiges Versprechen. Gib an, wie lange Support gilt und wie schnell du in der Regel reagierst.
Mindestbedingungen, die auf einem Einseiter stehen sollten:
Beispiel: „Zwei Überarbeitungsrunden für das Homepage‑Layout. Neue Seiten oder neue Funktionen gelten als Änderungsanforderung und werden mit $X/Stunde berechnet."
Ein Signatur‑Schritt wirkt echt, wenn er klar, vorhersehbar ist und eine Papierspur hinterlässt. Es geht nicht um juristisches Theater, sondern darum, dem Kunden eine einfache Handlung zu geben, die seinem Willen entspricht, und später nachweisen zu können, was passiert ist.
Biete Signatur‑Optionen an, die zum Arbeitsstil der Leute passen. Manche Kunden unterschreiben unterwegs auf dem Handy, andere bevorzugen eine gezeichnete Unterschrift, und manchmal reicht eine klare Zustimmung:
Welche Option auch immer du anbietest: Zeichne immer auf, wann die Unterschrift erfolgte. Füge nahe der Signatur ein automatisches Datum‑ und Zeitstempel hinzu und speichere intern, wer unterschrieben hat, welche Version der Bedingungen angezeigt wurde und welche E‑Mail genutzt wurde. Diese Prüfspur ist wichtiger als die Frage, ob die Unterschrift getippt oder gezeichnet ist.
Platziere einen kurzen Zustimmungssatz direkt über dem Button. Halte ihn einfach: „Mit meiner Unterschrift stimme ich den oben stehenden Bedingungen zu und beabsichtige, dies als rechtsverbindliche Unterschrift.“ Wenn sie im Namen einer Firma unterschreiben, füge eine Zeile hinzu: „Ich bestätige, dass ich bevollmächtigt bin, für diese Firma zu unterschreiben."
Nach der Unterschrift zeige sofort eine Bestätigung und sende eine Kopie. Ein guter Standard ist: ein herunterladbares PDF, eine E‑Mail‑Quittung an den Unterzeichner und ein internes Dashboard, in dem du die neueste signierte Version abrufen kannst.
Ist der Unterzeichner nicht der Zahler (häufig bei Agenturen und größeren Teams), mache das deutlich. Erfasse sowohl „Unterzeichner“ als auch „Rechnungsansprechpartner“ und füge eine Checkbox hinzu, dass Rechnungen an den Rechnungsansprechpartner gehen sollen. Dieser kleine Schritt verhindert den klassischen Streit: „Ich habe zugestimmt, aber die Buchhaltung wusste nichts davon."
Ein Einseiter funktioniert, wenn er sich wie ein geführter Checkout anfühlt, nicht wie eine Textwand. Halte alles auf einer Seite, nutze aber klare Abschnitte, damit Kunden nie fragen müssen, was als Nächstes passiert.
Beginne mit einer kurzen Kopfzeile (Leistungsname und dein Firmenname). Strukturier die Seite dann in drei Blöcke: Kundendaten, Bedingungen und Signatur.
Eine einfache Fortschrittsanzeige hilft: „1) Daten 2) Prüfen 3) Signieren.“ Kombiniere sie mit einem fixierten Zusammenfassungsfeld (Seitenleiste auf Desktop, unterer Balken auf Mobil) mit Preis, Startdatum und der wichtigsten Storno‑ oder Rückerstattungszeile.
Prefille, was du kannst. Kam der Kunde über eine Einladung oder ein Angebot, lade automatisch Name und Firma. Kannst du nicht vorausfüllen, halte Felder kurz und erkläre, warum du sie brauchst.
Auch auf einer Seite willst du klare Lebenszyklus‑Zustände:
Im Hintergrund halte das Modell einfach: ein Kunden‑Datensatz, ein Agreement‑Datensatz, eine Terms‑Version (damit du beweisen kannst, was der Kunde gesehen hat) und ein Signatur‑Datensatz (Name, Zeitstempel, Methode plus eine kurze Audit‑Notiz wie „von E‑Mail‑Einladung signiert").
Nach der Signatur zeige eine Bestätigungsseite mit einer kurzen Zusammenfassung und „Was als Nächstes passiert“. Sende zwei Benachrichtigungen: eine an den Kunden (Quittung und Kopie) und eine intern (signierte Vereinbarung und wichtige Felder).
Wenn du das in Koder.ai baust, fordere eine einseitige UI mit fixierter Zusammenfassung und einer kleinen Zustandsmaschine für den Agreement‑Lebenszyklus an. Es ist eine Seite für den Kunden, aber sie sollte wie ein kontrollierter Prozess funktionieren.
Koder.ai ist eine Vibe‑Coding‑Plattform, mit der du Web-, Server‑ und Mobile‑Apps über eine Chat‑Schnittstelle erstellen kannst. Für einen Einseiter ist das gut geeignet: Du beschreibst den Flow in klarer Sprache und generierst ein React‑UI mit einem Go‑Backend und PostgreSQL‑Speicherung.
Beginne im Planning‑Modus und schreibe die genauen Worte, die Kunden sehen sollen. Sei spezifisch bei Feldern, Bedingungen und dem, was nach der Signatur passiert. Generiere dann die App mit diesen Bezeichnungen und diesem Ton.
Eine praktische Reihenfolge beim Bauen:
Zum Sperren der Bedingungen: Wenn der Kunde auf Signieren klickt, speichere den finalen Bedingungstext genau so, wie er angezeigt wurde (optional mit Checksumme) und verhindere dann Änderungen an diesem Agreement‑Datensatz.
Wenn der Flow solide ist, deploye aus Koder.ai. Willst du es kundenfertig aussehen lassen, füge eine Custom‑Domain hinzu. Musst du Daten in einer bestimmten Region hosten, kannst du die Anwendung im passenden Land betreiben.
Eine freiberufliche Designerin, Maya, verkauft ein Festpreis‑Landingpage‑Paket. Sie möchte eine Unterschrift in fünf Minuten, ohne langen Vertrag oder E‑Mail‑Ping‑Pong. Sie nutzt einen Einseiter, der sich wie ein kurzer Checkout anfühlt.
Maya konfiguriert im Voraus, was nicht geändert werden soll: Paketname, Festpreis und eine kurze Umfangsangabe. Der Kunde sieht nur die Felder, die er ausfüllen muss, plus die Bedingungen, denen er zustimmt.
Der Kunde füllt aus:
Ihre Bedingungen bleiben minimal und klar:
Nach der Signatur ist der Ablauf genauso wichtig wie die Worte. Die Bestätigungsseite zeigt eine klare Zusammenfassung (Preis, Anzahlung, Liefertermine) und sagt, was als Nächstes passiert.
Im Hintergrund wird die signierte Kopie mit Zeitstempel gespeichert und beide Seiten erhalten ein sauberes PDF. Dann werden die nächsten Schritte automatisch gestartet: „Anzahlung bezahlen“ für den Kunden und „Kickoff‑Call planen“ für Maya. So wird die Vereinbarung vom Papierkram zu einem e‑Signatur‑Flow, der das Projekt voranbringt.
Die meisten Streitigkeiten beginnen nicht mit böser Absicht. Sie beginnen mit einem Formular, das bei der Einführung „gut genug“ wirkte und dann versagt, wenn sich jemand anders erinnert.
Eine Falle ist, den Einseiter in ein Mini‑Juradokument zu verwandeln. Wenn die Seite mit dichten Klauseln vollgestopft ist, überfliegen Kunden sie, übersehen Punkte und fühlen sich später überrascht. Halte die Sprache einfach und nimm nur Bedingungen auf, die du wirklich erwartest, dass der Kunde einhält.
Ein weiteres häufiges Problem ist vager Umfang. Sagt deine Vereinbarung „Design‑Support“ oder „Marketing‑Hilfe“, lädst du verschiedene Interpretationen ein. Nenne konkrete Liefergegenstände und Grenzen: was inklusive ist, was nicht und was als Änderungsanforderung gilt.
Ein Einseiter sollte auch stille Änderungen nach der Signatur verhindern. Streit entsteht, wenn jemand die Seite bearbeitet, Preise ändert oder Termine anpasst und niemand nachweisen kann, was vereinbart war.
Achte auf Lücken wie diese:
Ein Freelancer schickt einen Einseiter für eine Festpreis‑Website. Der Kunde unterschreibt und sagt später: „Wir haben vereinbart, dass Textarbeit dabei ist.“ Die Umfangszeile sagte nur „Website‑Aufbau“ ohne Ausschlüsse, und die Vereinbarung wurde nach der Signatur bearbeitet, um eine neue Frist hinzuzufügen. Jetzt fühlen sich beide Seiten getäuscht.
Behandle die Vereinbarung wie ein Protokoll: Sperre signierte Felder, speichere die Terms‑Version und archiviere jede signierte Kopie separat. Das verhindert viele vermeidbare Streitigkeiten.
Bevor du deinen Einseiter echten Kunden schickst, mach einen Trockenlauf mit jemandem, der ihn noch nicht gesehen hat. Beobachte, wo er pausiert, was er überspringen will und was er am Ende zu bekommen erwartet.
Nutze diese Punkte als finale Prüfung:
Ein einfacher Test: Unterschreibe zweimal, einmal mit korrekten Daten und einmal mit einem absichtlichen Fehler (z. B. Tippfehler im Namen). Wenn das Korrigieren des Fehlers die Bearbeitung des ursprünglich signierten Datensatzes erfordert, brauchst du einen Änderungs‑ oder Neunterschrifts‑Weg.
Wenn du mit Koder.ai baust, nimm diese Punkte als Akzeptanzkriterien für die App, nicht als „nice to have".
Starte mit einer kleinen, echten Version: eine Seite, die das Wesentliche sammelt, klare Bedingungen anzeigt und eine Signatur erfasst. Stell sie 3–5 freundlichen Kunden vor und beobachte, wo sie zögern. Ziel sind weniger Verzögerungen und weniger Missverständnisse.
Entscheide vor dem Launch, wo die Daten liegen müssen. Manche Kunden achten stark auf Standort und Zugriff. Arbeitest du mit EU‑Kunden, im Gesundheits‑ oder Finanzbereich oder mit Enterprise‑Teams, kläre früh die Datenschutz‑Erwartungen und wer Datensätze herunterladen oder löschen können muss.
Halte die Aufbewahrung einfach und sichtbar. Notiere, was du speicherst (Kundendaten, finale Agreement‑PDF, Signatur‑Zeitstempel und ggf. IP‑Adresse) und wie lange du es behältst. Eine kurze Aufbewahrungsregel ist später leichter zu verteidigen als „wir behalten alles für immer."
Stelle sicher, dass du Daten exportieren kannst. Selbst wenn dein aktuelles Tool heute gut funktioniert, schützen Exporte dich, falls du das System wechselst, geprüft wirst oder Daten mit einem Anwalt oder Steuerberater teilen musst.
Ein praktikabler Launch‑Plan:
Wenn du Koder.ai nutzt (koder.ai), machen Planning‑Modus und Snapshots das Iterieren einfacher: Du kannst den Flow verfeinern, Formulierungen testen und Änderungen zurückrollen, wenn etwas Nutzer verwirrt. Wenn du teilst, was du gebaut hast, bietet Koder.ai außerdem Wege, Credits über Content‑ und Empfehlungsprogramme zu verdienen.
Verwende eine Einseiter‑Vereinbarung, wenn die Leistung einfach und wiederholbar ist, z. B. ein Festpreis‑Paket oder ein monatlicher Retainer. Hat das Projekt viele Unbekannte, detaillierte Liefergegenstände oder verhandelte Klauseln, nutze den Einseiter für Intake und Unterschriftsabsicht und folge mit einem ausführlicheren Vertrag.
E‑Mails führen oft zu Verwirrung, weil wichtige Details verstreut, nur angedeutet oder in Antworten vergraben sind. Ein einseitiger Flow fasst Umfang, Termine, Zahlung und Signatur an einem Ort zusammen, sodass du eine einzige Referenz hast, wenn Fragen auftauchen.
Beginne mit den Grundlagen, die du zur Lieferung und Rechnungsstellung brauchst: rechtlicher Name, Rechnungsadresse, E‑Mail/Telefon, Leistungsname, Startdatum, Zeitrahmen für die Lieferung und Zahlungsbedingungen. Füge optionale Felder nur hinzu, wenn sie wirklich relevant sind, z. B. Bestellnummer oder Steuer‑ID.
Mache die minimalen Felder verpflichtend und halte alles andere optional oder bedingt. Nutze Validierung, um fehlerhafte Einträge zu verhindern, z. B. gültige Daten, einheitliche Währungsformate und den vollständigen rechtlichen Namen statt Spitznamen.
Formuliere Umfang und Ausschlüsse, Revisionen, Zahlungsplan, Stornierung/Rückerstattung und Support‑Erwartungen. Halte jede Klausel klar und spezifisch, damit sie später schwer misszuverstehen ist.
Definiere, was eine Revision ist, und setze ein klares Limit, das im Preis enthalten ist. Beschreibe dann, was danach passiert, z. B. Abrechnung zum Stundensatz oder Auslösen einer Änderungsanforderung.
Biete eine einfache Methode wie getippten Namen oder gezeichnete Unterschrift an und zeichne immer Zeitstempel sowie die exakte angezeigte Versionsansicht der Bedingungen auf. Die Prüfspur ist entscheidend, damit später klar ist, was vereinbart wurde.
Sperre die signierte Kopie so, dass Felder und Bedingungen nach der Signatur nicht mehr bearbeitet werden können. Muss etwas geändert werden, erstelle eine neue Agreement‑Version oder eine Änderung, die erneut signiert wird, statt das Original zu verändern.
Verwende eine einzelne Seite mit klaren Abschnitten: Kundendaten, Bedingungen und Signatur, plus eine kleine Zusammenfassung mit Preis und wichtigen Terminen. Behandle es wie einen geführten Checkout, damit Kunden immer wissen, was als Nächstes zu tun ist, ohne eine Textwand lesen zu müssen.
In Koder.ai kannst du den Flow im Planning‑Modus beschreiben und eine React‑UI mit Go‑Backend und PostgreSQL‑Speicherung generieren. Sorge dafür, dass „Fertig“ bedeutet: gesperrte signierte Datensätze, gespeicherte Versionsansicht der Bedingungen, klare Statuszustände und ein exportierbares signiertes PDF, das du später abrufen kannst.
