Deal Rooms: wo Verhandlungen mit Belegen stattfinden

B2B-ITAD-Negotiations brauchen einen Record, der den Deal überlebt. Eine forwarded message reicht nicht, wenn ein Buyer sechs Wochen später die Invoice disputet. Der Deal Room ist dieser strukturierte Record: eine Per-deal Page, auf der jedes Offer, Counter-offer, Message und Decision timestamped ist und an die ursprüngliche Listing gepinnt bleibt.

Die Anatomy eines Deal Rooms

Oben auf der Page: die ursprüngliche Listing, frozen in dem Moment, in dem der Deal geöffnet wurde. Darunter: die Offer History in chronologischer Reihenfolge, mit Timestamps und dem User, der jeden Move gemacht hat. Seitlich: das Trust Profile beider Parteien, die Active Fees und der Next-action Prompt ("Buyer to respond" / "Seller to confirm").

Counter-offer flow

Jede Partei kann ein Offer machen. Die andere kann accept, counter oder reject wählen (mit optionalem Reason). Der Counter setzt die Clock zurück; das nächste Response Window wird gegen das Response-time SLA gemessen und fließt zurück in die Response-time Dimension des Trust Profiles. Ein Deal, der zwei Wochen zwischen Counters hin und her springt, erscheint in Analytics als Long-cycle Deal.

Realtime updates

Messages und Offers im Deal Room pushen via Supabase Realtime an beide Parteien — kein Refresh. Die Notifications Bell zählt in der Top Bar hoch; ein Email Digest bündelt ruhige Activity in eine Morning Summary, damit zwölf Pings zum selben Deal nicht jeweils Inboxes treffen.

Einen Deal schließen

Acceptance erzeugt eine closed_won Deal Row. Der H2 Escrow Trigger feuert, ein Escrow Record öffnet mit Deposit Address, und der Deal-room wechselt auf "awaiting deposit." Von dort übernimmt der H-keten Escrow Flow (siehe Escrow Articles). Der Deal Room bleibt als Historical Record bestehen — lange nach Deal Close zugänglich, für Audits oder für "was hatten wir vereinbart" Fragen, die nie ganz verschwinden.