The B2B quotation workflow: offers, negotiation and revised prices

What a B2B quotation workflow is

A quotation workflow is the agreed path a price proposal follows inside a business platform, from the moment a buyer asks for it to the moment someone decides. It sounds administrative, but it is the core of any request-for-quotation product: the request form brings buyers in, and the quotation workflow decides whether a deal can actually be closed inside the platform.

Three terms are worth separating early. A quotation is what a supplier submits: a price and terms for a specific request. An offer is what the buyer is asked to decide on; in an open marketplace it is the supplier's quotation as submitted, while in an operator-reviewed marketplace it is the quotation after review and preparation. A revision is a changed version of an offer, usually the result of negotiation.

Treating these as separate records, linked to each other and to the original request, is what makes the rest of this article possible. When the quotation, the offer and every revision are just fields that get overwritten, nobody can later answer "what price did the buyer accept, and when?"

The quote states, from requested to accepted

A quote should always be in exactly one named state, and each state should say who is expected to act next. The table below is a practical starting set for a marketplace with operator review; an open marketplace simply skips the reviewed state.

Real products need a few more states than the textbook path. WOSTA, the healthcare procurement marketplace FLUIDS built, lets a supplier follow whether a submitted quote is pending, accepted or rejected, and the product distinguishes a withdrawn offer, an offer that was already accepted and a request that has moved to another stage. Those distinctions exist so that the same button never appears to complete an action that is no longer available.

What a comparable quotation contains

A quotation is comparable when every supplier answers the same questions in the same structure. Free-text quotes are easy to submit and hard to compare; a short structured form solves most of that without making suppliers' lives difficult.

• Price, with its basis. Unit price and total, and whether VAT is included. A total without a quantity basis invites misunderstandings.
• Confirmed quantity. The supplier may offer less than requested, or a different pack size. Make that explicit rather than hiding it in notes.
• Delivery information. Where and when the supplier can deliver, and any delivery charge or minimum order.
• Validity. How long the price holds. This feeds the expired state.
• Alternatives. If the exact item is unavailable, a clearly labelled substitute is more useful than no quote.
• Notes and attachments. Conditions, warranty terms or a product sheet that do not fit a field.

WOSTA's supplier quotation includes a price, delivery information and notes against the buyer's request. A new platform can start with that core and add structured fields once the operator sees which notes suppliers write again and again.

How negotiation should work inside the platform

Negotiation should happen in a conversation attached to the specific offer, with any change to price or terms producing a new, visible version of that offer. Two things go wrong when it does not: the platform loses the record, and the buyer accepts a price that only exists in someone's chat history.

In WOSTA, the buyer can accept, decline or open a negotiation about an offer, and the conversation is tied to that offer. The request stays connected to the offer and its conversation, so anyone looking at the purchase later sees the request, the discussion and the outcome together. FLUIDS's scope on WOSTA included this in-product chat.

There is a design choice between free conversation and structured counter-offers:

• Free conversation only. Natural for users, but a price agreed in a message still has to be turned into a revised offer by the supplier or operator before it can be accepted.
• Structured counter-offer. The buyer proposes a price or quantity in a form; the other side accepts it or replies. Precise, but it can feel rigid for complex requests.
• Both. A conversation for discussion, and a single "revise offer" action that creates the new version. This is usually the most practical choice.

Whichever you choose, the operator should be able to read the conversation, and notifications should tell each side when it is their turn to reply.

Handling revised prices without accepting the wrong one

A revised price must never be accepted by accident. The classic failure is simple: a buyer opens an offer, a colleague or the supplier revises it, and the buyer, still looking at the old page, clicks accept. Without a check, the system records acceptance of a price the buyer never saw.

WOSTA's acceptance workflow addresses this directly. It checks the price the buyer is responding to, and if the offer was revised, the interface asks the buyer to review the updated price before accepting. The same pattern works for any quotation product:

1. Version every offer. Each revision gets a new version number or a stored copy of its price and terms.
2. Send the version with the action. When the buyer clicks accept, the request to the server includes the version they were looking at.
3. Compare on the server. If the current version differs, refuse the acceptance and return the latest offer.
4. Show the change clearly. Display the old and new price or terms, then let the buyer decide again.
5. Make acceptance atomic. Accepting should change the offer and the request in one database transaction, so two users from the same buyer cannot accept different versions at once.

This is a small amount of engineering with a large effect on trust. In B2B purchasing, a single disputed acceptance can cost more goodwill than a dozen missing features.

Keeping an audit trail, and what comes after acceptance

Every quotation workflow needs an audit trail: who created, revised, reviewed, accepted or rejected each offer, at what time and on which version. It answers disputes, supports internal purchasing policies and gives the operator the data to improve the marketplace.

• Store each offer version rather than overwriting the previous one.
• Record each state change with the user, the organization and the timestamp.
• Keep messages linked to the offer version that was current when they were sent.
• Let buyers export their accepted offers for their own records or accounting.

Acceptance usually leads to the next stage: an order confirmation, an invoice and delivery coordination. WOSTA includes invoice and reporting areas for buyers and suppliers next to the request and offer screens. When planning a new product, decide which of these stages the first release covers, and which stay outside the platform for now.

FLUIDS builds quotation and procurement workflows as part of SaaS products and custom internal systems. See how the workflow fits into a full marketplace in the WOSTA case study and the RFQ marketplace guide, or read how branches and approvals change it in multi-branch procurement.