Skip to main content

Proposals & Invoices · Article 5.4

Was Ihr Kunde sieht, wenn ein Nachtrag eintrifft

Der Kunde erhält eine E-Mail mit einem neuen PIN, gelangt auf eine PIN-geschützte Seite, sieht eine Spalte-für-Spalte-Unterschiedsliste (Alt vs. Neu) mit Gesamtbeträgen und einer Begründung und unterzeichnet (oder lehnt ab) – genau wie beim ursprünglichen Angebotsablauf, aber mit eingebautem Diff.

Die Kundenerfahrung bei einem Nachtrag spiegelt die ursprüngliche Angebotserfahrung bewusst wider. Gleiches E-Mail-Design (Anzeigename = Ihr Unternehmensname), gleiches PIN-Gate, gleiches bei-Clozo-gehostetes URL-Muster, gleiche Beweiserfassung bei der Unterzeichnung. Der Unterschied ist die Seite selbst: Anstatt einer einzelnen Angebotsvorschau sieht der Kunde einen strukturierten Vergleich, sodass die Änderung eindeutig ist. Diese Konsistenz ist wichtig – Kunden, die einmal ein Angebot unterzeichnet haben, sollten nie das Gefühl haben, in einer fremden Benutzeroberfläche einen Änderungsauftrag zu unterzeichnen.

Step by step

  1. E-Mail trifft innerhalb von ca. 5 Sekunden ein.

    Von noreply@useclozo.com, Anzeigename „[Ihr Unternehmensname] via Clozo". Betreff lautet standardmäßig „Angebotsänderungsanfrage: [Originaltitel]", ist aber in Schritt 4 des Assistenten bearbeitbar.

  2. Kunde klickt auf Änderung prüfen.

    Gelangt auf app.useclozo.com/p/amendment/{slug} – eine von Clozo gehostete Seite, geschützt durch den 4-stelligen PIN, der im E-Mail-Text steht.

  3. Kunde gibt PIN ein.

    Fünf falsche Versuche in 24 Stunden lösen eine Slug-basierte Sperrung aus (Cache-Schlüssel slug_amend_locked:{slug}). Nach der Sperrung können nur Sie einen neuen PIN ausstellen (Artikel 7.7).

  4. Kunde liest die Unterschiedsliste.

    Original-Positionen erscheinen links, revidierte rechts. Farbige Tags entsprechen dem Assistenten: grün + hinzugefügt, bernsteinfarben ~ geändert, rot − entfernt, grau unverändert. Das Gesamtbetrags-Delta ist unten prominent angezeigt („Kostensteigerung: +€500" / „Kostenreduzierung: −€500" / „Erstattung fällig: €1.200"). Die Begründung, die Sie in Schritt 2 geschrieben haben, erscheint als Zitatnotiz über der Unterschiedsliste.

  5. B2C-Widerrufsblock (falls zutreffend).

    Bei Δ+-Nachträgen, bei denen der Kunde als B2C markiert ist, rendert die Seite zwei Pflicht-Widerrufscheckboxen unmittelbar über der Schaltfläche „Unterzeichnen". Beide müssen angekreuzt sein, bevor „Unterzeichnen" aktiviert wird. Artikel 7.5 für die rechtlichen Grundlagen.

  6. Kunde unterzeichnet (oder lehnt ab).

    Die Unterzeichnung erfasst dieselben eIDAS-Beweise wie beim ursprünglichen Angebot: eingegebener Name, E-Mail, IP, User-Agent, Server-Zeitstempel und Einwilligungsflag. Der Nachtragsstatus wechselt zu unterzeichnet, die Post-Sign-Pipeline läuft, und Bestätigungs-E-Mails werden innerhalb von Sekunden an beide Parteien versendet.

Die Angebotsdetailseite zeigt einen Bereich „Ausstehender Nachtrag" mit Nachtragsnummer, Sendezeitstempel, Ablauf-Countdown (14 Tage ab sent_at) und drei Schaltflächen: Unterzeichnungslink kopieren, Mit neuem PIN erneut senden, Nachtrag stornieren. Die Timeline verzeichnet Nachtrag vorgeschlagen um HH:MM UTC. Wenn der Kunde den Link öffnet, erscheint ein Timeline-Ereignis Nachtrag aufgerufen um HH:MM UTC von IP X.X.X.X. Wenn er unterzeichnet, verschwindet der Bereich und wird durch die neuen Dokumente im Dokumente-Dropdown sowie eine Bestätigungs-E-Mail in Ihrem Posteingang ersetzt.

Why this works this way

Warum ein neuer PIN pro Nachtrag, selbst für denselben Kunden, der bereits das ursprüngliche Angebot unterzeichnet hat? Weil der Nachtrag ein eigenständiges rechtliches Artefakt ist – er erhält seinen eigenen Prüfpfad, seinen eigenen Beweisstapel, seinen eigenen unveränderlichen Datensatz. Den PIN des ursprünglichen Angebots zu teilen würde die beiden Artefakte verschmelzen und die Beweiskette schwächen, falls der Nachtrag jemals angefochten wird. Die 5-Versuche-in-24-Stunden-Sperrung (_check_amendment_access_code in backend/apps/public/amendment_views.py) gilt unabhängig pro Nachtrag-Slug.

Das Diff-View-Rendering verwendet positionsbasierten Vergleich (computeDeltaAction in AmendmentWizard.tsx) – Position bei Index i in der revidierten Liste wird mit Position bei Index i in der Original-Liste verglichen. Ergänzungen erscheinen am Ende der revidierten Liste mit grünen Tags; Entfernungen erscheinen in der Original-Spalte mit roten Durchstreichungen; Änderungen bleiben an Ort und Stelle mit bernsteinfarbenen Tags. Das ist einfach und vorhersehbar; es wird ein „Vertausch zweier benachbarter Zeilen" nicht als No-Op erkennen (es zeigt beide als geändert an) – absichtlich, weil solche Neuanordnungen die Gewichtung eines Vertrags ändern können, selbst wenn die Zeilensummen übereinstimmen.

Troubleshooting

Keep reading