Die Notifications Bell und der Morgen-Digest
Wie die Glocke hochzaehlt, was eine Notification triggert und warum der Digest zwoelf Pings zu einem Deal in eine lesbare Zusammenfassung verwandelt.
Das Notifications System ist der Teil der Plattform, der Users pingt, wenn etwas passiert, das sie betrifft. New Offer in einer Deal Room. Asset deiner Testing Queue zugewiesen. Settlement wartet auf Review. Auction, die du beobachtest, erreicht gerade Reserve. Zwölf davon in zwei Stunden, alle zum selben Deal, trainieren Users darauf, die Bell zu ignorieren. Das System ist gebaut, um das zu verhindern.
Die Bell
Die Top-Bar Bell zeigt einen unread count. Klick öffnet das Notifications Center: ein chronologischer Feed mit Grouping (mehrere Events zur selben Entität klappen zu einer Summary zusammen). Mark-as-read pro Item oder bulk. Der Bell Count aktualisiert sich in Echtzeit über Supabase Realtime — kein Refresh.
Was eine Notification auslöst
Event-driven Triggers auf jede Statusänderung, die zählt: deal-room messages, offer changes, asset stage advances, SLA approaching, watchlist alerts, settlement actions, dispute filings, escrow transitions, auction events. Jeder Event Type hat einen Default Delivery Channel (in-app, email, beides, keines) und eine Default Urgency.
Der Morning Digest
Für Users, die keine zwölf E-Mails am Tag wollen, ist der Digest die Antwort. Ein Cron läuft jeden Morgen, sammelt die Notifications des Vortags pro User, gruppiert sie nach Entität und Typ und sendet eine einzige Email Summary. Zwölf Notifications zum selben Deal werden zu “Deal #1234: 3 messages, 1 counter-offer, 1 acceptance — open deal room.” Handhabbar.
Per-Event Preferences
Users wählen ihren Delivery Channel pro Event Type unter /settings/notifications. Der Platform Default ist “in-app für alles, email nur für high-urgency, digest für den Rest.” Users mit Vorlieben für volle Email Firehose, gar keine Email oder per-event tuning können jedes separat konfigurieren.