What this segment needs from a platform
- Bidding per unit — per tonne, per cubic metre, per pelt — rather than per lot
- Partial allocation: a buyer takes part of a bulk lot and pays for what they are awarded
- Grading and quality classification driving how lots are grouped and presented
- Large seasonal sales with a recurring calendar and a returning trade buyer base
In practice
Fur brought us this model first, and it is what Copenhagen Fur and American Mink Exchange run on: graded volumes sold to an international trade, where buyers bid a price per unit for a quantity and are allocated against the pool rather than winning a single object. The same mechanism carries milled peat and other semi-finished bulk goods sold by the tonne. None of it required a separate product — the lot type, the bid step and the allocation rules are configuration.
Strings, and the option on what comes next
The other model we built for this segment works nothing like a normal sale. Bulk goods are catalogued in strings — runs of lots of the same grade — and in a live auction the first string is put up and bid in the room. Whoever takes it is then offered the strings that follow at the price they have just set. They can take one, take several, or take them all.
Whatever they leave goes straight back under the hammer. The next string finds its own price, which may be higher or lower than the one before it, and whoever wins that string inherits the same option on everything after it. The sale moves in that rhythm until the batch is finished.
It is an exacting thing to build. The price a string settles at has to carry across to every lot its buyer accepts; the strings they decline have to reopen cleanly and in the right order; and the auctioneer has to see the whole picture at a glance while a room full of trade buyers waits. We built it for the fur trade, on the same bid engine that runs a timed art sale. The difference lives in the lot type and the bidding rules, not in the platform underneath.
The same platform, configured differently
Nothing above required a separate product. Lot types, categories, bid steps, fee structures, invoice layouts, emails and languages are configuration, not custom development. That is what makes it possible for one codebase to serve 12 segments without any of them feeling like an afterthought.