De Trade-in module: Hoe een pickup request een pickup wordt

De trade-in module is het klantgerichte oppervlak waar corporate IT-teams een pickup request publiceren, gecertificeerde ITADs erop bieden, de klant er een gunt, en het gewonnen werk echte operatie wordt. Ze draait in een eigen app-shell met eigen auth, eigen RLS en eigen UI — los van de operator-app waar het werk gebeurt, maar ermee verbonden via Coverage matching, de bid pipeline en de notificatielaag.

Klantportaal

Een klant meldt zich aan via de trade-in-flow. Het portaal heeft een eigen shell: dashboard, requests, pickups, facturen, certificaten, een meldingenoverzicht en instellingen. Elk oppervlak is gescoped op het klantaccount. De klant ziet de eigen aanvraag en het eigen bewijs, niet de opruiming van iemand anders in een ander gebouw. Portaalgebruikers beheren hun eigen profiel — naam, telefoon, wachtwoord en app-taal — terwijl e-mailadres en portaalrol alleen-lezen blijven, te wijzigen door de bedrijfsadmin of door ReVend-support. Een viewer krijgt geen knop “Nieuwe aanvraag”; het portaal zegt dat de rol alleen-lezen is, en wie de wizard-URL rechtstreeks opent, krijgt uitleg binnen het portaal in plaats van een 404.

Een aanvraag publiceren

De wizard heeft vijf stappen: Assets, Naleving, Beveiliging, Logistiek, Controle. Assets is het manifest per apparaat. Naleving legt databehandeling, vereiste certificeringen en rapportagebehoeften vast. Beveiliging legt merkbescherming, transport- en toegangseisen vast. Logistiek bevat het adres, de verdieping en de instructies, de voertuigvoorkeur, de prioriteit en de vroegste en laatste pickupdatum. Bij Controle leest de klant alles terug voor publicatie. Verzenden, en de aanvraag landt in de matchingpijplijn.

De biedronde

De matching engine vindt ITAD-tenants waarvan de coverage past bij het land, de vereiste certificeringen en de vereiste services. Elke in aanmerking komende ITAD ziet de aanvraag in de Sourcing inbox met de eisen inline. Ze dienen een gestructureerd bod in: een prijs per gevraagde regel, offertes voor de services, een voorgestelde pickupdatum, geldigheid, betaalvoorwaarden en een notitie voor de klant. Voor de award ziet de ITAD een stad en een manifest, maar geen bedrijfsnaam, adres of contact, en de klant ziet anonieme biedkaarten. De biedronde gaat over het werk, niet over merkkaraoke.

De award

De klant vergelijkt de biedingen en gunt er een. De award is definitief. In dezelfde operatie onthult het platform de partnerkaart van de winnende ITAD aan de klant, maakt het de klant aan als bedrijf in de Core van die ITAD (of hergebruikt het het bedrijf dat er al is), en maakt het de operationele handoff: een collection plus een inbound order, klaar voor planning en receiving. Geen knop om achteraf in te drukken. Eén award, drie records.

Pickup, verwerking en bewijs

De gegunde ITAD coördineert de pickup, ontvangt de goederen, test, gradeert, wist data waar nodig, en publiceert certificaten terug naar het klantportaal zodra ze beschikbaar zijn. Pickup-facturatie en operationele finance horen bij de Core-records van de ITAD. ReVend volgt de handoff en het bewijs; het ITAD-team doet nog altijd het fysieke werk. Software blijft slecht in pallets dragen.

Smart relaxation

Blijft een gepubliceerde aanvraag op nul biedingen staan, dan toont het aanvraagdetail in het portaal veilige versoepelingen: laat één vereiste certificering of één vereiste service vallen, met hoeveel extra partners dat zou ontgrendelen. Er een toepassen bewerkt de aanvraag ter plaatse en publiceert ze opnieuw bovenaan de Sourcing inbox. Het werkt alleen zolang er geen biedingen en geen award zijn, en het toont nooit wie die partners zijn. Een klant die stilte ziet en geen hulp krijgt, vertrekt. Een klant die ziet “laat deze ene eis vallen en vier ITADs kunnen bieden”, heeft ergens naartoe te gaan.