Deal rooms: ou les negociations ont des preuves

Les negotiations B2B ITAD ont besoin d’un record qui survit au deal. Un forwarded message ne suffit pas quand un buyer conteste l’invoice six semaines plus tard. La deal room est ce record structuré : une page par deal où chaque offer, counter-offer, message et décision est horodaté et rattaché à la listing d’origine.

L'anatomie d'une deal room

En haut de la page : la listing originale, frozen au moment où le deal a été ouvert. En dessous : l'offer history, en ordre chronologique, avec timestamps et l'utilisateur qui a fait chaque move. Sur le côté : le trust profile des deux parties, les active fees et le next-action prompt ("Buyer to respond" / "Seller to confirm").

Counter-offer flow

Chaque partie peut faire une offer. L'autre peut accept, counter ou reject (avec une reason optionnelle). Le counter réinitialise l'horloge ; la prochaine response window est mesurée face au response-time SLA, qui alimente la dimension response-time du trust profile. Un deal qui rebondit entre counters pendant deux semaines apparaît dans analytics comme un long-cycle deal.

Realtime updates

Messages et offers dans la deal room sont poussés aux deux parties via Supabase Realtime — pas de refresh. La notifications bell compte dans la top bar ; un email digest regroupe l'activité calme dans un morning summary afin que douze pings sur le même deal ne frappent pas chaque inbox.

Clôturer un deal

L'acceptance crée une closed_won deal row. Le H2 escrow trigger se déclenche, un escrow record s'ouvre avec une deposit address, et la deal-room passe à "awaiting deposit." À partir de là, le flow escrow H-keten prend le relais (voir les articles escrow). La deal room reste le historical record — accessible longtemps après la clôture, pour les audits ou les questions "qu'avons-nous convenu" qui ne disparaissent jamais tout à fait.