Centre d’aide/Portail trade-in/Révélation de l’ITAD attributaire & clone CRM
04Portail trade-in3 min de lecture

Révélation de l’ITAD attributaire & clone CRM

Pourquoi l’identité du bidder reste masquée pendant le bid round, ce que voit le customer à l’award, et comment l’award lui-même plante le customer dans le Core de l’ITAD gagnant.

Pendant le bid round, le customer voit des offres — prix, services, certifications, palier de confiance — mais pas l’identité du bidder. Le masquage garde le round honnête : un customer qui reconnaît un nom familier ne devrait pas le favoriser sur la seule reconnaissance, et un bidder ne devrait pas pouvoir jouer le round en exploitant une relation connue. À l’award, le masque tombe.

Ce que voit le customer pendant le round

Chaque bid remonte avec : le montant net pour le customer, les services inclus, les certifications que le bidder dit pouvoir prouver, le palier de trust score (platinum / gold / silver / bronze), la date de pickup proposée, les conditions de paiement et la note au customer. Le bidder est affiché comme « ITAD #N », où N est un identifiant stable pour toute la session du customer — le customer peut donc comparer et en discuter en interne sans jamais avoir besoin du nom de la company pour savoir quel bid est lequel. Quand un bidder révise son bid, la carte le dit.

Ce que voit le customer à l’award

À la seconde où le customer attribue un bid, la carte partenaire de l’ITAD gagnant apparaît dans le portail : le nom de la company, son e-mail de support, un numéro de téléphone, l’adresse et le site web, là où ils sont renseignés. C’est une carte de visite, pas un dossier — de quoi appeler les gens qui viennent chercher le matériel. Les identités des autres bidders restent masquées ; le customer qui a attribué à un ITAD n’a pas besoin des noms des autres. L’award est définitif, et le portail le dit avant que le bouton ne soit pressé.

Ce qui se passe côté ITAD

L’award fait lui-même le travail de greffe. En une seule opération de base de données, la plateforme crée le customer comme company dans le Core de l’ITAD gagnant — ou réutilise la company qu’il a déjà pour ce customer — et crée l’inbound order et la collection qui portent la pickup vers la planification et le receiving. Il n’y a pas de bouton « cloner vers le CRM », parce qu’un bouton, c’est une chose qu’on oublie un vendredi. Le bid gagné sur /sourcing/won et le calendrier des pickups renvoient directement vers cette collection. La relation démarre dans la bonne base ; l’ITAD n’a rien à retaper.

Pourquoi un clone, pas une jointure

Les comptes customer trade-in et les companies Core vivent dans des scopes différents. Le customer trade-in est une identité de marketplace (plusieurs ITADs peuvent travailler pour lui au fil du temps) ; la company Core est la vue d’un ITAD sur un client. Cloner signifie que le CRM de chaque ITAD possède le customer comme sa propre ligne, avec ses propres données de contrat et de contact, sans aucune fuite de données entre tenants. De toute façon, la Row Level Security n’autoriserait pas l’alternative.

La trace

Accepter un bid écrit une activity row : le bid a été accepté dans le portail trade-in, et la plateforme a créé la collection liée et le handoff inbound. Quand un customer ou un bidder demande plus tard à quel moment cela a été su et par qui, la réponse est une ligne horodatée, pas le souvenir d’un coup de téléphone.