Sourcing bids, defaults & bid history: één keer offreren, de saaie stukken hergebruiken
Hoe gestructureerde bids, tenantdefaults, geldigheidsvensters en biedhistoriek het offreren van ophalingen snel houden zonder het slordig te maken.
Een sourcing bid is niet zomaar een bedrag. Het is een belofte over ophaaltiming, diensten, betaalvoorwaarden, geldigheid en alle notities die de klant nodig heeft voor hij kiest. ReVend OS behandelt die belofte als gestructureerde data, want “zie bijlage” heeft deze sector al genoeg archeologie bezorgd.
Het biedformulier
Vanuit een requestdetail opent Offerte maken het biedformulier, voorgevuld vanuit de itemregels van de klant, de servicecatalogus van de tenant en de defaults van de tenant. De ITAD prijst elke gevraagde regel — alle vijftig laptops, niet de mooie dertig — en mag een regel opsplitsen in varianten met verschillende stukprijzen zolang de aantallen kloppen. Dan komen de diensten: catalogusdiensten plus alles wat de request vereist, elk met aantal, stukprijs en of ze verplicht zijn; verplichte diensten verlagen het nettobedrag dat de klant ziet, optionele worden apart opgelijst. Daarna logistiek en compliance: voorgestelde ophaaldatum, doorlooptijd in uren, tekortvergoeding per ontbrekend item, methode van datavernietiging, of assetrapportage en een ESG-rapport inbegrepen zijn, garantievoorwaarden en interne notities. Betaalvoorwaarden en de klantnotitie zijn de twee tekstvelden die de klant te zien krijgt. Het formulier telt alles op tot hardware-aanbod, verplichte kosten, optionele kosten en nettobedrag voor de klant, en het houdt de vereisten van de request zichtbaar terwijl dit allemaal wordt ingetypt, zodat niemand een gewone ophaling offreert voor een request die stilletjes om gecertificeerde vernietiging vroeg.
A-grade tot het tegendeel blijkt
Bids gaan uit van A-grade. De toegewezen ITAD inspecteert en gradeert nog altijd bij receiving, en de afrekening volgt het contract of de gradecorrectieregels na echte inspectie. Een bid is een gestructureerde commerciële offerte, geen profetie over elke laptop in een bergkast.
Defaults
/settings/sourcing/defaults bewaart tenantbrede defaults voor de saaie stukken: geldigheid van de bid (168 uur tenzij gewijzigd), doorlooptijd voor de ophaling (48 uur tenzij gewijzigd), betaalvoorwaarden en een standaard klantnotitie. Nieuwe bids vullen zich vanuit die defaults en leggen daarna de effectief ingediende waarden vast als snapshot. De default later wijzigen herschrijft de geschiedenis niet. Contracten stellen dat op prijs.
Bid history
/sourcing/bids houdt elke ingediende bid zichtbaar met requestnummer, biednummer, ophaallocatie, aantal items, nettobedrag, status en geldig-tot-datum. De statussen zijn submitted, retracted, accepted, rejected, lost en expired. Een ingediende bid kan achter een bevestigingsdialoog ingetrokken worden zolang het venster openstaat; zodra ze accepted, rejected, lost of expired is, verdwijnt die actie. Het is de plek om “wat hadden we ook alweer geoffreerd?” te beantwoorden, voor iemand met verdacht veel zelfvertrouwen een herinnering verzint.
Waarom structuur wint
Gestructureerde bids maken vergelijken eerlijk voor de klant en nakijken nuttig voor de ITAD. Ze voeden ook de cijfers: de dashboardpreset Sourcingmanager bouwt zijn ingediende bids, gewonnen bids, win rate, actieve bids, responstijd en lifetime gewonnen waarde rechtstreeks uit deze bid history. Een propere offerte vandaag wordt beter bieden morgen.