Designing a Multi-Vendor Auction Platform for Enterprise Procurement
Some details have been anonymized for confidentiality.
Owning a B2B auction product end to end
Taabi Procure is a B2B logistics SaaS platform that lets enterprises run auctions to buy and sell materials. As the sole designer, I owned it end to end, from the first discussion through to launch and the customer demo. I designed both sides of the marketplace: the enterprise's creation and management experience, and the vendor's bidding interface.
Procurement auctions with no ownership and no record
A large manufacturing enterprise ran high-value procurement auctions, buying raw materials and selling surplus, on third-party tools and spreadsheets. Bids were tracked manually, extensions were handled ad hoc, and auctions couldn't be reliably reconstructed afterward. There was no ownership, no real-time visibility, and no audit trail over decisions that moved significant money.
The job was to bring that entire process into one platform: configurable enough for how enterprises actually run auctions, yet simple enough for vendors to bid without training.
The visual representation of enterprise procurement
Starting from a version we already had
Rather than start from a blank canvas, we adapted an auction module we had already built for Taabi's TMS, swapping its core object from vehicles to materials, and put a working V1 in front of the procurement team quickly.
The demo did its job. It showed where the old model breaks down for procurement, and three pieces of feedback reset the direction:
- Vendors couldn't tell where they stood. Ranking visibility was too weak to drive competitive bidding.
- The auction screen was cluttered with information the enterprise didn't need.
- There was no final report to close out and reconcile an auction.
The V1 that reset the whole design.
What a live auction taught us
That feedback sent us deeper. Before redesigning any screen, we mapped how these auctions actually work: the auction types, where the starting price comes from, how bid gaps and differences are set per material, and how multiple materials run together.
Then we watched the procurement team run a live auction on their current tool. Seeing a real one surfaced two things no requirements doc would:
- Visibility shapes how vendors bid. How clearly a vendor could read their position changed how aggressively they bid. That auction surfaced a visual ranking idea, a traffic light model, which we then researched and built our own version of.
- Starting prices aren't uniform. Each vendor had already submitted a quote before the auction, and that became their personal starting bid, so vendors enter the same auction at different floors.
The finding pointed one way: enterprises needed to configure auctions to their own requirements, while vendors needed a bidding experience simple enough to ignore all that complexity.
Defining the flow before the design
With the mechanics clear, my PM and I locked the entire flow before touching a single screen. For a system this configurable, sequence mattered more than polish.
The result was a multi-step wizard, ordered to mirror how a procurement decision actually gets made.
Step 1: Auction type and price source
Step 2: Materials and vendors
Step 3: Ranking configuration
Step 4: Scheduling and rules
Three of those steps carried the real decisions:
- Every vendor can start at a different price. Each vendor's pre-auction quote becomes their own floor.
- The enterprise picks what vendors see. Exact L1/L2 ranks, or traffic-light bands, set per material.
- Lowest bid alone doesn't win. L1 goes only to vendors who commit to a minimum share of the volume, not just the cheapest quote on a sliver of it.
And one we reversed. We first built two execution modes, simultaneous and sequential. Sequential collapsed under its own logic: if any auction can end early or extend, you can never schedule when the next one begins. We killed it and committed to simultaneous.
Sequencing turned a dauntingly configurable product into a series of small, in-context decisions.
Two ranking systems, not one
Once the live auction surfaced the traffic-light model, the easy path was to swap it in for L1/L2 and move on. I pushed back, and argued to keep both.
That auction had shown me something specific: what a vendor can see changes how they bid.
Visibility isn't a display choice, it's a lever on price discovery.
Different enterprises want to pull that lever differently, so the real answer wasn't one ranking system or the other. It was letting the enterprise choose.
L1/L2 Ranking
Vendors are ranked purely by bid price. Simple, transparent, and widely understood.
Traffic Light Ranking
The enterprise defines green and yellow bid bands. Vendors see only their relative position, green, yellow, or red, without exact ranks.
Two ways to see the same race.
One component, two truth models, matched to how much visibility the enterprise wants to expose. The hard part wasn't building the second system, it was arguing that keeping both was worth the added complexity.
Two users, two jobs
A live auction has two people watching the same event for different reasons. The enterprise needs full awareness of everything happening. The vendor needs to focus on a single task. I designed each side around that difference.
The enterprise's live view
The enterprise needs to see everything, and auctions aren't flat: one parent auction can hold many child auctions running at once. Two decisions shaped this screen.
- A persistent command block, always in view. The full state of the current auction stays pinned, so the enterprise never loses track of which one they are in across parallel auctions.
- One deliberate omission: no starting price. Each vendor starts from their own pre-quoted price, so a single starting-price number would be misleading. I chose to show nothing over something false.
One block. The entire auction at a glance.
Below the block, five tabs, each answering one question the enterprise asks under pressure: what is happening (time-wise bids), who is winning and can I trust them (vendor-wise bids, where IP-conflict flags surface), why did this run long (extensions), who is ignoring the invite (participants), and what is the record of truth (the log, timestamped and exportable to Excel).
The vendor's bidding card
The vendor has one job, so the card protects it. I stripped everything that doesn't change a bidding decision and kept only what does: time left, the last bid to beat, and where they stand right now. Three decisions shaped it.
- The same card speaks both ranking languages. However the enterprise configured the auction, the card shows either an exact rank (L1/L2) or a band (green, yellow, or red). Two truth models, one component.
- Every live-auction state has an answer. Extended, closed, removed from participation, or an invalid bid: whatever happens, the card says so immediately, so a vendor is never left guessing.
- Acceptance comes before bidding, and it counts. If material acceptance is on, vendors first commit to how much they can supply, say 400 of 500 tons. That commitment feeds the L1 eligibility rule, so the winning rank reflects who can genuinely fulfil the volume.
One screen, one job: bid.
Designing each side around its own job kept a dense product legible under real-time pressure.
Once an auction ends, the platform generates a downloadable report that summarizes the completed auction, giving procurement an auditable record to reconcile and close against.
Where the real product lives
IP Conflict Detection
If two vendors bid from the same IP address or location, the system flags it. This wasn't in the original scope. I pushed to include it, because without it the audit log would be incomplete, and in high-value procurement a complete record is the entire point.
IP conflict detection with vendor details
Messaging
The enterprise and vendor can communicate directly within the platform during an auction. This replaced the informal WhatsApp and email threads that used to sit outside the system, bringing that context into the audit trail where it belongs.
Messaging thread for each side
Validating it in a live auction
We built and tested the platform, then ran a live auction on it with the procurement team. The pilot produced two immediate changes:
- Vendors needed the terms and conditions visible at the acceptance step, so the enterprise now sets them during auction creation.
- The enterprise wanted to know who was actually present, so an online and last-seen indicator was added to the Participants tab, making an empty auction obvious at a glance.
A working pilot, measurement ahead
The product is in development and has already run its first live auction with the procurement team: a complete, competitive auction from start to finish. The primary business outcome at launch is the full elimination of third-party auction-tool spend. As adoption grows, the outcomes worth tracking are:
- Vendor participation rate per auction
- Time from creation to publish
- Price discovery against historical negotiated rates
- Reduction in communication happening outside the platform
Configurability isn't the enemy of simplicity. Bad sequencing is.
The business initially wanted to limit configuration to keep things simple. The better answer was to keep every option but sequence them, so each decision arrives at the right moment and in the right context.
Dual-sided products mean holding two mental models at once.
Every screen I designed had a counterpart on the other side. A decision about what the enterprise configures directly shapes what a vendor experiences while bidding. That relationship has to stay in view the whole time. You cannot design one side and retrofit the other.
The edge cases are where the real product lives.
IP conflict detection, messaging, and the audit log weren't in the original scope. But in procurement, something always goes wrong, and a platform that can't handle that isn't a platform, it's a prototype.