Was soll passieren, wenn ein Kunde ein altes Angebot annimmt?

Wer ein älteres Angebot öffnet, sollte erkennen, ob genau diese Fassung noch angenommen werden kann. Vereinbaren Sie vor der Entwicklung eines Angebotsportals die Gültigkeitsregeln, den Umgang mit überarbeiteten Angeboten und das Verhalten bei einer Annahme kurz vor Ablauf oder während eines Widerrufs. Nicht allein die Schaltfläche darf entscheiden, ob ein Auftrag angenommen wurde.

Dieser Leitfaden behandelt Softwareabläufe, nicht die rechtliche Frage, wann ein Vertrag zustande kommt oder ob ein Angebot zurückgezogen werden darf. Lassen Sie Bedingungen und Kundenhinweise für Ihren Betrieb und die betreffende Rechtsordnung prüfen.

Ein Angebot ist nicht die aktuelle Preisliste

Ein Angebot beschreibt einen bestimmten Vorschlag. Es ist nicht bloß eine Ansicht des heutigen Katalogs. Für eine individuelle Anwendung empfiehlt sich, ausgestellte Leistungsbeschreibung, Mengen, Preise, Währung, relevante Bedingungen und die Identität der Fassung zu erhalten. Sonst sieht ein Kunde unter demselben Link möglicherweise plötzlich einen anderen Leistungsumfang oder Betrag, ohne die Änderung zu bemerken.

Ein Entwurf darf bearbeitbar bleiben. Definieren Sie einen eigenen Schritt für die Ausgabe der Kundenfassung. Muss diese später korrigiert werden, braucht es ein klares Verfahren: beispielsweise die bisherige Fassung zurückziehen und eine neue ausstellen. Überschreiben Sie nicht unbemerkt das Angebot, über das jemand gerade entscheidet.

Das sind empfohlene Anforderungen. Nicht jedes Angebotsprodukt bietet sie automatisch.

Die Gültigkeit braucht eine genaue Grenze

„Gültig bis Freitag“ lässt Fragen offen. Welche Zeitzone gilt? Ist der Tagesanfang oder das Tagesende gemeint? Was passiert genau an der Grenze? Halten Sie den vollständigen Ablaufzeitpunkt in den technischen Vorgaben fest und verwenden Sie dazu passende, verständliche Kundenhinweise.

Stripe zeigt einen konkreten Produktansatz. Das Feld expires_at des Quote-Objekts beschreibt den Zeitpunkt, zu dem ein offenes Angebot oder ein Entwurf storniert wird, angegeben in Sekunden seit der Unix-Epoche. Laut Stripe-Leitfaden können stornierte Angebote nicht angenommen werden. Dieser Ablauf gehört zu Stripe und überträgt sich nicht von selbst auf ein eigenes Portal.

Wählen Sie für Ihr System Zeitpunkt und Grenzfall ausdrücklich. Der Dienst, der die Annahme verarbeitet, sollte die aktuelle Berechtigung zur Annahme prüfen und nicht einer möglicherweise seit Stunden geöffneten Seite vertrauen. Countdown und deaktivierte Schaltfläche sind hilfreiche Hinweise, ersetzen aber keine verbindliche Prüfung.

Was soll ein alter Link zeigen?

Nach Ablauf sollte die Seite erklären, dass das Angebot nicht mehr angenommen werden kann, und einen passenden Weg zu einem neuen Vorschlag anbieten. Sie sollte weder Erfolg melden noch stillschweigend einen neuen Preis unterschieben.

Wenn es eine überarbeitete Fassung gibt, muss der Zusammenhang verständlich sein. Bestimmen Sie, ob der alte Link auf den Ersatz verweisen darf und welche Informationen dabei sichtbar werden. Zugriff auf ein Angebot darf nicht automatisch Zugang zu anderen Kundendaten eröffnen.

Unterscheiden Sie in der internen Historie zwischen Ablauf, Rücknahme und Ersatz, auch wenn die verwendete Plattform mehrere Fälle unter einem Status zusammenfasst. Mitarbeitende brauchen eine nachvollziehbare Erklärung statt Vermutungen.

Gegen den aktuellen Stand prüfen

Ein hypothetischer Fall: Ein Kunde lässt das Angebot im Browser offen. Währenddessen zieht eine Mitarbeiterin es zurück. Ein späterer Klick muss gegen den zuletzt gespeicherten Zustand geprüft werden. Vereinbaren Sie, wie das System entscheidet, wenn Rücknahme und Annahme gleichzeitig eintreffen. Lassen Sie zeigen, dass nur ein zulässiger Zustandswechsel abgeschlossen wird.

Prüfen Sie außerdem einen zweiten Klick und eine verlorene Bestätigungsantwort. Wer nicht weiß, ob die Annahme erfolgreich war, sollte das gespeicherte Ergebnis erneut abrufen können. Eine ausgebliebene Antwort allein darf nicht zu einem weiteren Auftrag führen.

Diese Empfehlung betrifft den Annahmevorgang und daraus entstehende Arbeit. Sie behauptet nicht, dass ein gespeicherter Status externe Zahlungen oder E-Mails automatisch genau einmal ausführt.

Angenommen bedeutet nicht bezahlt

Der dokumentierte Stripe-Status accepted bedeutet, dass der Kunde das Angebot angenommen hat und eine Rechnung, ein Abonnement oder ein Abonnementplan erstellt wurde. Der Status ist damit kein Zahlungsnachweis.

Trennen Sie diese Begriffe auch im eigenen Portal. Legen Sie fest, was nach der Annahme entsteht: ein noch zu prüfender Auftrag, eine Rechnung, eine Terminierungsanfrage oder ein anderer definierter Folgeschritt. Vereinbaren Sie gesondert, wann die Arbeit beginnen darf und wer die Zahlung bestätigt. Die Kundenmeldung soll das tatsächlich gespeicherte Ergebnis beschreiben, nicht den Abschluss sämtlicher Folgeschritte versprechen.

Diese Abläufe gehören in die Abnahme

Nutzen Sie die Fälle für Ihre Akzeptanzkriterien:

• Ein aktuelles Angebot lässt sich rechtzeitig annehmen und die Bestätigung erneut aufrufen.
• Ein abgelaufenes Angebot erklärt den nächsten Schritt und erzeugt keinen angenommenen Auftrag.
• Nach einer Überarbeitung bleibt die ältere Fassung erkennbar.
• Eine veraltete Browseransicht kann kein zurückgezogenes Angebot annehmen.
• Gleichzeitige Rücknahme und Annahme führen zu einem erklärbaren gespeicherten Ergebnis.
• Wiederholtes Absenden erzeugt keine doppelte Folgearbeit.
• Angenommen, Zahlung ausstehend und bezahlt werden nicht gleichgesetzt.

Bringen Sie zur Planung eines Angebotsportals ein abgelaufenes und ein überarbeitetes Angebot mit. Solche Beispiele zeigen Entscheidungen, die hinter einem einfachen Annahmeknopf leicht verschwinden.

Quellen und Einordnung

Stripe zum Lebenszyklus von Angeboten: https://docs.stripe.com/quotes

Stripe zum Quote-Objekt und Ablaufzeitpunkt: https://docs.stripe.com/api/quotes/object

Die belegten Produkteigenschaften beziehen sich auf Stripe. Versionierung, Kundenhinweise und Annahmeprüfungen sind Planungsempfehlungen, deren Umsetzung und rechtliche Eignung gesondert zu prüfen sind.