Das Trade-In Modul: wie ein Pickup Request zum Pickup wird
Customer Portal, Bid Round, Award Flow, Settlement - der Lifecycle eines Trade-in Pickups von Publish bis Payout.
Das Trade-in Module ist die customer-facing Surface, auf der Corporate IT Teams eine Pickup Request veröffentlichen, zertifizierte ITADs darauf bieten, der Customer eine davon awarded, die Pickup passiert und das Money settlet. Es läuft in seiner eigenen App Shell mit eigener Auth, eigenem RLS und eigener UI — getrennt von der Operator App, in der die Arbeit erledigt wird, aber über Coverage Matching, die Bid Pipeline und die Notifications Layer mit ihr verbunden.
Customer-facing portal
Ein Customer meldet sich über /signup?type=trade-in an (die Legacy ?type=customer URL funktioniert noch für Menschen, die zu früh bookmarkt haben). Das Portal hat eine eigene Shell: dashboard, requests, bids, awarded pickups, invoices, notifications, settings. Jede Surface ist RLS-scoped auf den Account des Customers — der Customer sieht nie Requests oder Bids anderer Customers.
Eine Request publishen
Ein Multi-step Wizard: contact + company → items (per-PC details — siehe rich-per-pc-intake Article) → logistics (location, access requirements, preferred date window) → schedule (Standard / Express / Urgent SLA) → compliance + security requirements (die V3 + V4 service codes — siehe compliance-and-security-steps-on-intake) → review. Submit, und die Request landet in der Matching Pipeline.
Die bid round
Die Matching Engine findet Tenants, deren Coverage die Region, Certifications und Service Codes der Request abdeckt. Jeder matched ITAD sieht die Request in seiner Sourcing Inbox, mit V3+V4 inline auf dem Bid Detail (siehe sourcing-bid-detail-compliance-display). Sie geben einen structured bid ab: total amount, Services, die sie include, SLA, zu dem sie sich committen, optional notes. Die Bid Round schließt am Ende des configured Window (24 hours für Express, 5 days für Standard).
Der award
Der Customer vergleicht die Bids im Portal: Side-by-side View, sortierbar nach Price, Certifications, Trust Score, SLA. Einen Bid zu awarden reveal die Identity des awarded ITAD an den Customer (siehe awarded-itad-identity-reveal), clonet den Customer in das CRM des ITAD, startet die operator-side Arbeit in Core und schreibt die Fee-ledger Row für Settlement.
Pickup, processing, settlement
Der awarded ITAD koordiniert die Pickup, läuft die Items durch seinen normalen Core Workflow (receiving session, testing, grading, erasure) und surfaced Certificates zurück in das Customer Portal, sobald sie generated werden. Settlement läuft gegen den awarded bid amount, die Platform Commission greift, und Mollie bewegt die Funds in die Richtung, die der Deal verlangt (siehe mollie-billing-and-award-payouts).
Smart relaxation
Wenn eine Request zero bids bekommt — Region zu eng, Service-code Set zu restriktiv, SLA zu knapp — zeigt das Portal Relaxation Suggestions, bevor der Customer abbricht: “drop on-site destruction, 4 ITADs would bid.” Ein Customer, der nur crickets sieht und keine Hilfe bekommt, geht und kommt nicht zurück; der Relaxation Flow hält ihn.
Notifications and digests
Customer-side Notifications decken den Request Lifecycle ab: bid received, bid count thresholds, round closing soon, award reminders, pickup scheduled, certificates uploaded, settlement complete. Operator-side Notifications erreichen den awarded ITAD zu denselben Events. Beide Seiten fließen in die Digest Pipeline der Plattform, sodass dieselbe Ping-Flut in eine Morning Summary gerollt wird.