Wissensbasis/Konformität/Sourcing-Anforderungen: erst lesen, dann bepreisen
08Konformität3 Min. Lesezeit

Sourcing-Anforderungen: erst lesen, dann bepreisen

Warum Certifications, Services und die Datenvernichtungswahl des Kunden auf der Request-Detailseite selbst stehen — und wo das Bid-Formular wirklich liegt.

Ein Bieter, der einen Pickup bepreist, muss wissen, was der Job belegen muss. Liegen die Compliance-Angaben drei Klicks vom Formular entfernt, kommt die Hälfte der Angebote für den falschen Scope zurück — und der ITAD, der sorgfältig gelesen hat, sieht neben dem, der es nicht getan hat, teuer aus. Also stehen die Anforderungen auf der Request selbst, über dem Button, der das Gebot öffnet.

Was die Request-Detailseite zeigt

/sourcing/inbox/[id] öffnet mit der operativen Gestalt des Jobs: Request-Nummer, ungefähre Gerätezahl, Abholstadt und -land, die Bieterfrist oder die verbleibende Zeit, die aktuelle Zahl der Gebote und die Manifest-Zeilen mit Category, Hersteller, Modell oder Spec-Zusammenfassung, Menge und Data-bearing-Flags. Danach das gewünschte Abholfenster, die Fahrzeugpräferenz und die Priorität.

Danach die Anforderungen — in Klartext statt in internen Codes: die geforderten Certifications, die geforderten Services, ob Datenvernichtung verlangt wird und mit welcher Methode, ob ein ESG Report erwartet wird, und die Disposition Preference. Auflagen zu Brand, Transport und Zugang erscheinen, wenn der Kunde sie ergänzt hat. Ein Screen, alles, wovon der Preis abhängt.

Wo das Bid-Formular liegt

Angebot abgeben öffnet /sourcing/inbox/[id]/bid, eine eigene Seite unter der Request statt eine Box darauf, denn ein strukturiertes Gebot ist ein Formular und kein „machen Sie uns ein Angebot“-Textfeld. Hat Ihr Tenant bereits ein aktives eingereichtes Gebot, bietet die Request-Detailseite Gebot bearbeiten, solange das Fenster offen ist; nach Schließen des Bietens wird die Aktion deaktiviert statt entfernt, denn „Sie waren zu spät“ ist nützlicher als ein Button, der still verschwunden ist. /sourcing/bids ist wieder etwas anderes: die Historie dessen, was Ihr Tenant angeboten hat.

Sie sehen nur, was Sie können

Das Coverage-Filtering entscheidet, ob eine Request Sie überhaupt erreicht. Sind ihre geforderten Certifications nicht alle in der Coverage Ihres Tenants vorhanden, erscheint sie nie in Ihrer Inbox — jede Anforderung, die Sie lesen können, ist also eine, von der Sie der Plattform bereits gesagt haben, dass Sie sie abdecken. Der Anforderungsblock ist eine Checkliste zum Bepreisen, kein Eignungstest, durch den Sie beim Lesen fallen könnten.

Was bis zum Award verborgen bleibt

Der Firmenname des Kunden, die genaue Abholadresse, die Postleitzahl, Etage und Zugangsdetails sowie die Kontaktdaten stehen vor dem Award nicht auf der Seite. Sie werden operativ nützlich in dem Moment, in dem ein Gebot gewonnen ist; davor laden sie vor allem zu Nebenkanälen ein. Niemand braucht einen Marktplatz, auf dem die schärfste Preisstrategie darin besteht, die Telefonnummer zu finden.