Rich per-PC intake: pourquoi "340 laptops" n’est pas un manifeste
Comment l’intake trade-in capture du detail device-level des la request - manufacturer, model, condition, serials, data-on-board - et ce que cela change pour les bids.
“340 mixed laptops” n'est pas un manifest. C'est une estimation. Les ITADs qui bid sur une estimation pricent pour le pire mix plausible ; les customers qui avaient price pour le meilleur mix plausible sont surpris au settlement. Rich per-PC intake dans le trade-in form remplace l'estimation par des rows per-device structurées.
Ce que le form capture par device
Pour chaque device que le customer veut faire collecter : manufacturer, model, age band, condition grade (une échelle customer-facing pour non-experts, pas l'ITAD A–R), serial number (optionnel mais précieux), si le drive est encore installed, si le drive carries data, préférence on-site vs. facility wipe, et special handling notes. Le form auto-suggest pendant que l'utilisateur tape — manufacturer “Dell” ouvre le model picker filtré sur les produits Dell.
Bulk entry options
Taper 340 rows à la main n'arrivera pas. Le form supporte CSV upload (avec un template téléchargeable qui documente les column headers), copy-paste depuis un spreadsheet, et un bouton “same as the row above” qui permet de remplir rapidement des rows identiques en bulk. Pour les mixed lots avec patterns (50 Latitude 5430s + 50 ThinkPads), le CSV upload est le chemin réaliste.
Pourquoi per-device, pas bulk-counts
Trois raisons. Bid accuracy : un ITAD qui bid sur des per-device data donne un price plus serré qu'un ITAD qui bid sur “a couple hundred mixed.” Coverage matching : une request avec servers nécessite d'autres ITADs qu'une request avec phones ; la plateforme route correctement seulement si elle sait ce qui est dans le lot. Operational predictability : l'awarded ITAD planifie receiving, testing et erasure capacity à partir de la device list. Arriver avec 340 unknowns est la manière dont un SLA de 5 days devient 12 days.
Camera capture for warehouse-floor requests
La moitié de ces requests sont filed depuis un phone à côté du matériel. Le intake form supporte camera upload pour les location photos (la room où sont les devices), et le “add photo” de la per-device row capture le device via le même flow que l'operator scanner. Un customer qui documente sa pile par phone ne doit donc pas changer d'outil.
Ce que voit l'opérateur
La receiving session de l'awarded ITAD est pre-populated depuis la device list de la request : chaque device reçoit une placeholder row avec les customer-supplied data, prête pour que l'opérateur scanne les actuals à l'arrivée. La pre-population n'est pas traitée comme truth — c'est le scan de l'opérateur qui crée l'asset row — mais les placeholders font de receiving une comparaison, pas une re-création.