Compliance & security à l’intake : poser les questions gênantes d’emblée
Les deux steps de la request qui fixent certifications, traitement des données et contraintes de manutention avant l’ouverture du bid round.
Une pickup request qui ne dit jamais ce que le disposal doit prouver revient avec des bids chiffrés pour un autre travail. Tout le monde le découvre après l’award, en réunion, face à un responsable des achats qui n’est plus charmé du tout. Deux steps du wizard de request existent pour que ces réponses arrivent avant l’ouverture du bidding : un pour ce que le customer veut voir prouvé, un pour la manière dont les marchandises doivent être manipulées en sortant.
Le compliance step
Le customer indique si les appareils portent des données, puis choisit le traitement : effacement logique, destruction physique, ou les deux. Les certifications exigées viennent d’une courte liste fixe — R2v3, e-Stewards, NAID AAA, ISO 14001, ISO 27001 et WEEELABEX — et chacune resserre le vivier d’ITADs que la request peut atteindre. À côté d’elles, les demandes de preuve : destruction sur site, destruction sous témoin, preuve vidéo, rapport par asset, rapport ESG. Le step se termine par la disposition preference : réemploi préféré, recyclage uniquement, ou indifférent.
Six certifications, ce n’est pas un manque d’ambition. C’est précisément l’ensemble qui reflète les tags de certification qu’un ITAD garde sur sa coverage Sourcing, et c’est ce qui permet au filtre de matching de fonctionner. Un sélecteur à quatre-vingt-dix entrées produirait des formulaires plus longs et les six mêmes réponses.
Le security step
Autre préoccupation, autre step. La protection de marque vient en premier : retirer les asset tags, effacer le branding, ne pas revendre ces machines dans cette région — les questions que pose une entreprise quand son logo sur un laptop d’occasion est une exposition plus grande que le laptop. Ensuite la sécurité du transport : véhicules suivis par GPS, conteneurs scellés, équipage à deux personnes, chauffeurs contrôlés. Ensuite l’accès au site : pickup en dehors des heures, pickup le week-end, et un contact sécurité nommé pour le site, parce que le quai de chargement à 6 h appartient à quelqu’un.
Notez ce qui n’est pas là. Le choix de destruction des données vit dans le compliance step, puisque c’est une promesse sur les données et non sur la camionnette.
Deux listes, pas un mapping
Les choix ne se traduisent pas chacun en un joli code unique. La request porte deux tableaux : certifications exigées et services exigés. Les certifications sont des barrières — un ITAD dont la coverage ne porte pas chaque tag exigé ne voit jamais la request. Les services sont ce que la request demande au bidder gagnant d’exécuter réellement, et ils apparaissent côté bidder dans les mots mêmes que le customer a choisis. Une request, deux listes, aucune couche de traduction que personne n’avait demandée.
Quand personne ne bid
Une request publiée qui reste à zéro bid, sans award et sans handoff en aval, peut être assouplie : retirer une certification exigée, ou retirer un service exigé. La plateforme suggère quelle contrainte fait obstacle, le customer en applique une à la fois, et la request se republie pour remonter près du haut de l’inbox Sourcing — sans jamais exposer de compteurs de coverage ni quoi que ce soit sur ceux qui n’ont pas bid.
Une contrainte à la fois, c’est tout l’enjeu. Cela garde la request honnête sur ce qu’elle exige encore, au lieu de la laisser devenir discrètement une autre request. Et parfois la conclusion honnête, c’est que WEEELABEX relevait du vœu pieux.