How an RFQ marketplace works: buyers, suppliers and the operator

What an RFQ marketplace is, and how it differs from an online store

An RFQ marketplace is a platform where the price is the answer to a question rather than a label on a product. The buyer asks: "We need this quantity, delivered here, by this date. What will you charge?" Suppliers answer with quotations, and the buyer decides.

Much business purchasing already works this way, in Saudi Arabia and elsewhere. Medical consumables, equipment, catering for an event, office fit-outs and spare parts are often priced per order, because the price depends on quantity, location, timing and the supplier's stock. A fixed-price catalogue cannot express that. A phone call, a WhatsApp thread or an email chain can, but then the requests and replies are scattered and hard to compare.

An RFQ platform replaces those scattered threads with one shared record. The request is written once in a structured form. Every quotation points back to it. Negotiation, revisions and the final decision stay attached to the same request, so the buyer, the supplier and the team running the platform are looking at the same facts.

The three roles: buyer, supplier and operator

Every RFQ marketplace has at least three roles, and most product problems come from designing for two. Buyers and suppliers are obvious. The operator, the company that runs the platform, is easy to forget until someone has to approve a supplier, resolve a dispute or answer "why did this request get no quotes?"

• Buyer. Creates requests, receives offers, negotiates, accepts or rejects, and follows the history of each purchase. In a B2B product the buyer is an organization with several users, not one person.
• Supplier (provider). Sees the requests it is allowed to see, submits quotations with a price, delivery information and notes, and follows whether each quote is pending, accepted or rejected. Suppliers usually also maintain a profile and the categories or products they cover.
• Operator. Onboards both sides, manages categories and cities, monitors requests that are stuck, and, depending on the model, reviews or prepares quotations before the buyer sees them. The operator also needs reporting across the whole marketplace.

In WOSTA, the healthcare procurement marketplace FLUIDS designed and built for Saudi Arabia, the roles are separated in the product itself. Buyers manage requests and offers from their side. Providers have dedicated screens for requests, quotations, products and communication. Both sides have invoice and reporting areas. And the buyer receives an offer that has been selected and prepared through the platform's review workflow, rather than a raw feed of every supplier reply.

How a request moves from brief to accepted offer

A request in an RFQ marketplace follows a short, predictable path. Making each step explicit in the product is what lets everyone know where a purchase stands without asking.

1. The buyer creates a request. In WOSTA the buyer flow records a title, description, category, quantity, city, urgency and desired delivery date, and the request can be associated with one of the buyer's branches.
2. The platform routes the request. Suppliers who cover that category, and possibly that city, are notified or see it in their request list. Routing rules are an operator decision.
3. Suppliers submit quotations. Each quote is tied to the request and carries the supplier's price, delivery information and notes.
4. The offer reaches the buyer. In an open model the buyer sees every quote. In a reviewed model, as in WOSTA, the operator's workflow selects and prepares the offer the buyer receives.
5. The buyer decides. Accept, decline or open a negotiation. In WOSTA the negotiation conversation is tied to the offer, so the discussion and the price under discussion stay together.
6. The record closes or moves on. An accepted offer moves the request to its next stage. Rejected, withdrawn or superseded offers remain in the history.

Notice what is not in this list: payment, delivery tracking and supplier guarantees. Those can be added, but each is a separate requirement with its own rules and, for payments, its own regulatory questions. A first release that handles the request-to-decision path well is already a useful product.

Open bidding vs operator-reviewed offers

The biggest design decision in an RFQ marketplace is who stands between the supplier's quote and the buyer. There are three common models, and each changes the product's screens, its trust model and the operator's workload.

WOSTA uses the reviewed model: suppliers submit quotations, and the buyer is presented with the offer selected and prepared through the review workflow. That makes the operator a real participant in every transaction, which is why its review screens matter as much as the buyer's and supplier's.

None of these models is correct in general. A marketplace for standard consumables with many comparable suppliers may suit open bidding. A sector where buyers want one recommended offer, and where an operator can add judgement, may suit review. Decide early, because switching later means rebuilding permissions and the buyer's main screen.

What a B2B marketplace in Saudi Arabia needs to get right

A Saudi B2B marketplace succeeds on operational detail more than on feature count. A few requirements come up in almost every project:

• Arabic-first, bilingual interfaces. Procurement staff, supplier sales teams and operators often work in different languages. Right-to-left layout, Arabic category names and bilingual notifications are part of the core build, not a translation pass at the end.
• Cities and delivery locations as data. Suppliers rarely cover the whole Kingdom. Storing city and delivery location as structured fields lets the platform route requests and lets suppliers decline what they cannot serve.
• Organizations, not individuals. Buyer and supplier accounts belong to companies with several users and, often, several branches. Roles and permissions inside each organization are needed early.
• In-product communication. If negotiation happens on personal phones, the platform loses the record. A conversation tied to the request or offer keeps the history where the operator can see it.
• Personal data and records. User accounts contain personal data, so Saudi Arabia's Personal Data Protection Law (PDPL) applies. If the platform issues invoices, e-invoicing requirements from the Zakat, Tax and Customs Authority (ZATCA) also matter. Confirm the specifics with qualified counsel and your accountant.

Real-time messaging and live status updates are where architecture choices show. WOSTA is built with React, TypeScript, Supabase and PostgreSQL, and FLUIDS's scope included the marketplace architecture, the RFQ workflow and in-product chat. A relational database suits this domain well, because requests, quotations, branches, organizations and messages are tightly related records.

What to build first in an RFQ marketplace

The first release of an RFQ marketplace should prove one thing: that buyers will send real requests and suppliers will answer them inside the platform. Everything else can wait for evidence.

• Buyer and supplier sign-up with an operator approval step.
• A structured request form for one sector, with the fields suppliers need to quote accurately.
• A supplier request list, a quotation form and quote statuses.
• The buyer's offer screen with accept, reject and negotiate actions.
• A conversation tied to each offer, and notifications for new requests, quotes and replies.
• An operator console for onboarding, categories, cities and stuck requests.

Before committing to a marketplace, check that it is the right product. If your real problem is finding new buyers rather than handling their requests, a custom sales prospecting tool may fit better. If you are matching clients with professionals rather than suppliers, the dynamics of a lawyer marketplace platform are closer to yours.

FLUIDS designs and builds B2B marketplaces for companies and founders in Saudi Arabia and the GCC. See the WOSTA case study, read how we approach marketplace platform development, or go deeper into the B2B quotation workflow and healthcare procurement platforms.