Centre d’aide/Conformité/Exigences Sourcing : lisez-les avant de les chiffrer
08Conformité3 min de lecture

Exigences Sourcing : lisez-les avant de les chiffrer

Pourquoi les certifications, services et choix de destruction des données du customer se trouvent sur le request detail lui-même, et où vit vraiment le bid form.

Un bidder qui chiffre une pickup doit savoir ce que le travail doit prouver. Si les choix de compliance vivent à trois clics du formulaire, la moitié des offres reviennent chiffrées pour le mauvais scope — et l’ITAD qui a lu attentivement a l’air cher à côté de celui qui ne l’a pas fait. Les exigences se tiennent donc sur la request elle-même, au-dessus du bouton qui ouvre le bid.

Ce que montre le request detail

/sourcing/inbox/[id] s’ouvre sur la forme opérationnelle du travail : numéro de request, nombre approximatif d’appareils, ville et pays du pickup, date limite de bidding ou temps restant, nombre de bids actuel, et les lignes de manifeste avec catégorie, fabricant, modèle ou résumé de specs, quantité et drapeaux data-bearing. Puis la fenêtre de pickup demandée, la préférence de véhicule et la priorité.

Ensuite les exigences — en mots clairs plutôt qu’en codes internes : les certifications exigées, les services exigés, si une destruction des données est requise et par quelle méthode, si un rapport ESG est attendu, et la disposition preference. Les contraintes de marque, de transport et d’accès apparaissent quand le customer les a ajoutées. Un écran, tout ce dont le prix dépend.

Où vit le bid form

Faire une offre ouvre /sourcing/inbox/[id]/bid, une page distincte sous la request plutôt qu’une boîte posée dessus, parce qu’un bid structuré est un formulaire et non un champ libre « faites-nous une proposition ». Si votre tenant a déjà un bid soumis actif, le request detail propose Modifier l’offre tant que la fenêtre est ouverte ; une fois le bidding clos, l’action est désactivée plutôt que retirée, car « vous êtes arrivé trop tard » est plus utile qu’un bouton disparu sans un mot. /sourcing/bids est encore autre chose : l’historique de ce que votre tenant a chiffré.

Vous ne voyez que ce que vous pouvez faire

Le filtrage par coverage décide si une request vous atteint tout court. Si ses certifications exigées ne sont pas toutes présentes sur la coverage de votre tenant, elle n’apparaît jamais dans votre inbox — chaque exigence que vous pouvez lire est donc une exigence que vous avez déjà déclarée couvrir. Le bloc des exigences est une checklist pour chiffrer, pas un test d’éligibilité que vous pourriez rater en le lisant.

Ce qui reste caché jusqu’à l’award

Le nom de la company du customer, l’adresse exacte du pickup, le code postal, l’étage, les détails d’accès et les coordonnées ne sont pas sur la page avant l’award. Ils deviennent opérationnellement utiles à la seconde où un bid est gagné, et avant cela ils invitent surtout aux canaux parallèles. Personne n’a besoin d’une marketplace où la stratégie de prix la plus fine consiste à trouver le numéro de téléphone.