Intake détaillé par machine : pourquoi « 340 laptops » n’est pas un manifeste
Comment l’intake trade-in capture le détail par appareil dès la request — catégorie, fabricant, modèle, specs, numéros de série, classification des données — et ce que ça change pour la justesse des bids et la prévisibilité opérationnelle.
« 340 laptops mélangés », ce n’est pas un manifeste. C’est une supposition. Les ITADs qui bid sur une supposition chiffrent pour le pire mélange plausible ; les customers qui avaient chiffré pour le meilleur mélange plausible tombent de haut au settlement. L’intake détaillé par machine du formulaire trade-in remplace la supposition par des lignes d’items structurées, et le bid form de l’autre côté est fait pour chiffrer exactement ces lignes-là.
Ce que le formulaire capture par ligne
Chaque ligne d’item porte une catégorie (laptop, desktop, serveur, écran, téléphone, networking, imprimante ou autre), un fabricant, un modèle, un CPU, de la RAM, du stockage, une taille d’écran et une quantité. Elle porte aussi une classification des données — public, interne, confidentiel ou réglementé — et c’est elle qui transforme une ligne en ligne data-bearing en aval. Les numéros de série et les asset tags propres au customer peuvent s’ajouter ligne par ligne, avec des notes en texte libre. Il n’y a pas de grade de condition côté customer : le grading est le métier de l’ITAD, et chaque bid suppose du grade A jusqu’à ce que le receiving dise autre chose.
Saisie en masse
Taper 340 lignes à la main n’arrivera pas. L’étape items dispose d’une boîte de dialogue de collage depuis un tableur, avec des en-têtes de colonnes fixes — manufacturer, model, category, cpu, ram_gb, storage_gb, display_size, qty, serial, asset_tag, data_classification — qui transforme les lignes collées en lignes d’items. Les appareils identiques restent sur une seule ligne avec une quantité ; un lot de 50 Latitude et 50 ThinkPad fait deux lignes, pas cent.
Pourquoi par ligne, pas en comptage global
Trois raisons. La justesse du bid : le bid form exige que chaque ligne demandée soit entièrement couverte, et laisse l’ITAD scinder une ligne en variantes à des prix unitaires différents tant que les quantités tombent juste — un prix plus serré que « quelques centaines mélangées » ne pourra jamais l’être. Le matching de coverage : une request avec des serveurs à données réglementées demande d’autres partenaires qu’une request avec des écrans à données publiques ; la plateforme ne route correctement que si elle sait ce qu’il y a dans le lot. La prévisibilité opérationnelle : l’ITAD attributaire planifie sa capacité de receiving, de testing et d’erasure à partir du manifeste. Se présenter avec 340 inconnues, c’est ainsi qu’un SLA de cinq jours en devient douze.
Photos du site
La moitié de ces requests sont déposées depuis un téléphone, à côté du matériel. Le wizard accepte des photos de lieu — la salle, les palettes, le quai de chargement — pour que le bidder voie à quoi ressemble vraiment une pickup « troisième étage, sans ascenseur » avant de proposer un véhicule.
Ce que voit le bidder
Sur le détail de la request Sourcing, les lignes de manifeste apparaissent avec catégorie, fabricant, modèle ou résumé de specs, quantité et drapeau data-bearing, à côté du nombre approximatif d’appareils et de la ville du pickup. Le nom de la company, l’adresse exacte et le contact restent cachés jusqu’à l’award. L’ITAD chiffre le manifeste, pas la relation. Après l’award, c’est encore le receiving qui grade les vrais appareils ; le manifeste est la promesse, le scan est la vérité.