Le module Trade-In: comment un pickup request devient pickup

Le module trade-in est la surface customer-facing où les équipes IT corporate publient une pickup request, des ITAD certifiés bid dessus, le customer en award un, la pickup se déroule et l'argent settle. Il tourne dans son propre app shell avec sa propre auth, son propre RLS et sa propre UI — séparé de l'operator app où le travail est exécuté, mais relié à celle-ci via Coverage matching, la bid pipeline et la notifications layer.

Customer-facing portal

Un customer s'inscrit via /signup?type=trade-in (l'URL legacy ?type=customer fonctionne encore pour ceux qui ont bookmarké trop tôt). Le portal a son propre shell : dashboard, requests, bids, awarded pickups, invoices, notifications, settings. Chaque surface est RLS-scoped au compte du customer — le customer ne voit jamais les requests ou bids d'autres customers.

Publier une request

Un multi-step wizard : contact + company → items (per-PC details — voir l'article rich-per-pc-intake) → logistics (location, access requirements, preferred date window) → schedule (Standard / Express / Urgent SLA) → compliance + security requirements (les V3 + V4 service codes — voir compliance-and-security-steps-on-intake) → review. Submit, et la request arrive dans la matching pipeline.

La bid round

Le matching engine trouve les tenants dont Coverage couvre la region, les certifications et les service codes de la request. Chaque ITAD matched voit la request dans sa sourcing inbox, avec V3+V4 affiché inline sur le bid detail (voir sourcing-bid-detail-compliance-display). Ils soumettent un structured bid : total amount, services inclus, SLA auquel ils s'engagent, optional notes. La bid round se ferme à la fin de la fenêtre configurée (24 hours pour Express, 5 days pour Standard).

L'award

Le customer compare les bids dans le portal : side-by-side view, sortable par price, certifications, trust score, SLA. Awarding un bid révèle l'identité de l'awarded ITAD au customer (voir awarded-itad-identity-reveal), clone le customer vers le CRM de l'ITAD, lance le travail operator-side dans Core et écrit la fee-ledger row pour settlement.

Pickup, processing, settlement

L'awarded ITAD coordonne la pickup, passe les items dans son workflow Core normal (receiving session, testing, grading, erasure), et fait remonter les certificates dans le customer portal à mesure qu'ils sont generated. Settlement se fait contre l'awarded bid amount, la platform commission s'applique, et Mollie déplace les funds dans la direction prévue par le deal (voir mollie-billing-and-award-payouts).

Smart relaxation

Si une request reçoit zero bids — region trop étroite, service-code set trop restrictif, SLA trop serré — le portal affiche des relaxation suggestions avant que le customer abandonne : “drop on-site destruction, 4 ITADs would bid.” Un customer qui voit crickets et ne reçoit aucune aide part et ne revient pas ; le relaxation flow est ce qui le garde.

Notifications and digests

Les customer-side notifications couvrent le lifecycle de la request : bid received, bid count thresholds, round closing soon, award reminders, pickup scheduled, certificates uploaded, settlement complete. Les operator-side notifications touchent l'awarded ITAD sur les mêmes events. Les deux côtés alimentent la digest pipeline de la plateforme, afin que la même avalanche de pings soit regroupée dans un morning summary.