De Trade-In module: hoe een pickup request een pickup wordt
Het klantportaal, de biedronde, de award flow, de settlement - de lifecycle van een trade-in pickup van publish tot payout.
De trade-in module is de customer-facing surface waar corporate IT teams een pickup request publiceren, gecertificeerde ITADs erop bieden, de customer er één awardt, de pickup gebeurt en de money settlet. De module draait in zijn eigen app shell met eigen auth, eigen RLS en eigen UI — gescheiden van de operator app waar het werk gebeurt, maar eraan gekoppeld via Coverage matching, de bid pipeline en de notifications layer.
Customer-facing portal
Een customer meldt zich aan via /signup?type=trade-in (de legacy ?type=customer URL blijft werken voor mensen die te vroeg bookmarkten). De portal heeft zijn eigen shell: dashboard, requests, bids, awarded pickups, invoices, notifications, settings. Elke surface is RLS-scoped naar het account van de customer — de customer ziet nooit requests of bids van andere customers.
Een request publiceren
Een multi-step wizard: contact + company → items (per-PC details — zie rich-per-pc-intake article) → logistics (location, access requirements, preferred date window) → schedule (Standard / Express / Urgent SLA) → compliance + security requirements (de V3 + V4 service codes — zie compliance-and-security-steps-on-intake) → review. Submit, en de request landt in de matching pipeline.
De bid round
De matching engine vindt tenants waarvan Coverage de region, certifications en service codes van de request dekt. Elke matched ITAD ziet de request in zijn sourcing inbox, met V3+V4 inline op de bid detail (zie sourcing-bid-detail-compliance-display). Ze dienen een structured bid in: total amount, services die ze include, SLA waartoe ze zich verbinden, optional notes. De bid round sluit aan het einde van het configured window (24 hours voor Express, 5 days voor Standard).
De award
De customer vergelijkt de bids in de portal: side-by-side view, sorteerbaar op price, certifications, trust score, SLA. Een bid awarden onthult de identiteit van de awarded ITAD aan de customer (zie awarded-itad-identity-reveal), clonet de customer naar de CRM van de ITAD, start het operator-side werk in Core en schrijft de fee-ledger row voor settlement.
Pickup, processing, settlement
De awarded ITAD coördineert de pickup, draait de items door zijn normale Core workflow (receiving session, testing, grading, erasure), en toont certificates terug in de customer portal zodra ze generated worden. Settlement loopt tegen het awarded bid amount, platform commission wordt toegepast, en Mollie verplaatst de funds in de richting die de deal vereist (zie mollie-billing-and-award-payouts).
Smart relaxation
Als een request nul bids krijgt — region te smal, service-code set te restrictief, SLA te strak — toont de portal relaxation suggestions voordat de customer afhaakt: “drop on-site destruction, 4 ITADs would bid.” Een customer die alleen crickets ziet en geen hulp krijgt, vertrekt en komt niet terug; de relaxation flow houdt hem binnen.
Notifications and digests
Customer-side notifications dekken de lifecycle van de request: bid received, bid count thresholds, round closing soon, award reminders, pickup scheduled, certificates uploaded, settlement complete. Operator-side notifications bereiken de awarded ITAD op dezelfde events. Beide kanten voeden de digest pipeline van het platform, zodat dezelfde ping-vloed in één morning summary wordt gerold.