Prachi Bakshi

Redefining the RFQ interaction model

How I mapped real procurement journeys and designed a buyer-initiated negotiation flow for Hub.

TradeNeo · HubSenior Product Designer2025

An RFQ for Nylon-Spandex Smooth Knit. Its details sit behind a panel titled Quotes Submitted By All Suppliers, a grid of quote cards with a price and three buttons each: Reject, Counter, Accept.
A buyer's RFQ, with the quotes suppliers sent back.
Role
Senior Product Designer
Team
Me and a junior designer
Timeline
4 weeks
Methods
Journey mapping · stakeholder interviews · contextual inquiry · card sorting · market research
Status
Available to beta users

01 · The starting point

Buy orders and sell orders. No defined negotiation journey.

Hub was early in development. The first version had an Order Book, borrowed from the bid and ask of financial markets: buyers posted buy orders, suppliers posted sell orders, and either side could submit quotes.

The earlier Book View screen: a table with Buy Order columns on the left and Sell Order columns on the right, each row with a date, order ID, quantity, company ID, bid and a View link.
  1. 01Both sides could initiate activity.
  2. 02Buy orders in one table.
  3. 03Sell orders in another.
  4. 04What happens after View?
The early Order Book.
  • The early Buy Order page: a grid of order cards marked Open or Closed, each with a Submit Quote button, and a Create Buy Order button at the top.

    Buy Order

  • The early Sell Order page: the same grid of Open and Closed order cards with Submit Quote buttons, and a Create Sell Order button at the top.

    Sell Order

Buy orders and sell orders lived in separate views. Either side could create an order, and every open card had Submit Quote. Nothing said what happened after.

Buy order

A buyer posts what they need.

Sell order

A supplier posts what they have.

How would these two sides connect?

02 · What concerned me

Creating a quote was only the beginning.

The distinction I noticed was that, unlike financial stock trading, where buyers and sellers can transact without knowing each other or having a direct conversation, export trade depends on building trust and aligning on the details before a physical transaction can happen. A buyer and supplier need to discuss requirements, quantities, pricing, and terms before moving forward. The order-book model made supply and demand visible, but it didn't fully account for the conversation needed to turn that intent into a real trade.

  1. Order posted
  2. Quote submitted
  3. Then what?Who acts next? Where does negotiation happen? How does it end?
The part of the journey that still needed definition.

03 · Back to actual user journeys

Same trade. Different jobs. The buyer starts with a requirement; the supplier responds to one.

I mapped the persona's journey to understand how procurement actually happened: what the buyer was trying to achieve, and how the supplier responded.

Thinking about the mandi alongside it reminded me of the physical conversation behind a transaction. A buyer comes with a specific requirement, and a supplier responds to that requirement.

That made me look again at the early Hub model. Buy Order and Sell Order let both sides start activity, but the interaction between them hadn't been worked out end to end.

So I stopped designing two separate order experiences and started defining how a buyer's requirement could open a connected interaction with suppliers.

Who does what?

Buyer

  1. Has a requirement
  2. Finds suppliers
  3. Asks for quotes
  4. Compares + negotiates
  5. Decides

Supplier

  1. Has supply
  2. Gets discovered
  3. Sees a requirement
  4. Chooses to quote
  5. Negotiates
The two journeys, redrawn from my journey map.
A FigJam board of open card-sorting sessions: four columns of sticky notes labelled cards for bip, cards for buyer outreach, cards for operations and cards for registrations, with one numbered lane per participant.
  1. 01One lane per participant.
  2. 02Sorted by area of the business.
Open card sorting, alongside the stakeholder conversations. It showed me how the ecosystem behaves. Participant names are replaced with numbers.

04 · The interaction model changed

One clear starting point: the buyer's requirement.

For the procurement workflow we were designing, the buyer initiated the requirement and suppliers responded. So I designed the RFQ to start with the buyer.

Relevance comes from the HS code. The buyer picks one for the RFQ, the backend filters suppliers on it, and only those relevant suppliers are notified.

  1. Buyer selects the HS code
  2. Backend filters relevant suppliers
  3. RFQ published to the market
  4. Relevant suppliers notified
  5. Suppliers choose whether to respond
  6. Quote, negotiation, outcome
Before, buy and sell orders sat side by side with no defined path between them. Now: one requirement, a structured way to respond, and a defined end.

05 · Why an RFQ

More structure than a message. More flexibility than an immediate purchase.

The Create RFQ screen: six steps across the top (Company Contact, Product Information, Packaging, Logistic Terms, Payment Terms, Additional Information) and the line: relevant suppliers will be notified through email when your RFQ is uploaded, and an RFQ is valid for 30 days.
  1. 01The requirement, built in six steps.
  2. 02Relevant suppliers, filtered on the RFQ's HS code, are notified by email.
Creating an RFQ, as a buyer.
The Product Information step of Create RFQ: Product Name reads 6004- Nylon-Spandex Smooth Knit, with Variety, Grade, Product Specification, Country of Origin, Certification, Offer Quantity, Trial Order Quantity and Unit Price fields.
  1. 01The HS code comes with the product name: 6004. The backend filters suppliers on it.
Product Information, step two of Create RFQ.
The RFQ Details panel: Quote Details with product specification and offer quantity, Packaging with type of packaging and language requirements, and Payment Terms with offer validity and payment terms details.
The RFQ details a supplier quotes against.

An RFQ carries the whole requirement: what, how much, how it's packed, how it's paid for, and how long the offer stays open.

Every quote and every counter refers back to it.

06 · The state model

Defined what happens after every action.

I defined the states, who owns the next move in each, what they can do, and where each action leads. Current state → who acts → available action → next state.

  1. DraftThe buyer prepares it.
  2. SentPublished. Relevant suppliers can quote.
  3. Supplier quoteNot a state of its own. The buyer's move.
  4. CounteredEither side. Turns alternate.
  5. Accepted · Rejected · ExpiredRejecting a quote leaves the RFQ open to others. Expiry is the 45-day timeout.
The lifecycle at a glance.
Buyer
Supplier
BuyerDraft

Drafts the RFQ and selects the HS code

BuyerSent

Publishes it to the RFQs Market

Supplier

Sees the RFQ and chooses whether to respond

Supplier

Submits a quote

  • Submit Quote
Buyer

Decides on the quote

  • Accept
  • Counter
  • Reject
SupplierCountered

Responds to the counter

  • Approve
  • Counter
  • Reject
  • AcceptedEither side accepts or approves. The deal is agreed.
  • RejectedThat quote's negotiation ends. The RFQ stays in the market for other suppliers.
  • ExpiredThe 45-day request duration ran out with no action.
Who holds the next move. A counter passes it to the other side, so turns alternate until someone accepts or rejects.
  1. DraftWho actsBuyerActionSelects the HS code, finishes and publishesSent
  2. SentWho actsRelevant suppliersActionChoose whether to submit a quoteBuyer's move
  3. SentWho actsBuyerActionAccepts the quoteAccepted
  4. SentWho actsBuyerActionCounters the quoteCountered
  5. SentWho actsBuyerActionRejects the quote. The RFQ stays in the market for other suppliers.Rejected
  6. CounteredWho actsThe other partyActionApproves the counterAccepted
  7. CounteredWho actsThe other partyActionCounters againCountered
  8. CounteredWho actsThe other partyActionRejects the counterRejected
  9. Sent · CounteredWho actsNobody actsActionThe 45-day request duration runs outExpired
The full specification behind the diagram.

07 · From states to screens

The interface followed the logic.

An RFQ detail page for Nylon-Spandex Smooth Knit, tagged Ongoing, with a 45-day request duration, the full RFQ details, and an empty Quotes Submitted By All Suppliers section reading Awaiting For Quotes From The Vendors.
  1. 01Sent and open.
  2. 02The request duration: when it runs out, the RFQ expires.
  3. 03Awaiting quotes: the next move is the suppliers'.
Sent, as the buyer sees it.
The Quote Received list for a seller: two quote cards from buyers, P V H Corporation at USD 2.45 per meter and ComfortKnit Bedding at USD 2.50, each with Reject, Counter and Approve buttons.
  1. 01The price leads the card.
  2. 02The decision sits on the card: Reject, Counter, Approve. Any of them changes the state.
Quote Received, as a seller sees it: a counter has come back and it's their move.

08 · The negotiation in motion

A state wasn't just a label. It decided what you could do next.

  1. Sent · supplier

    An RFQ card in the RFQs Market: P V H Corporation, Nylon-Spandex Smooth Knit, an Ongoing tag and one button, Submit Quote.

    One action: Submit Quote.

  2. Quote in · buyer

    A quote card as the buyer sees it: the supplier's name, USD 2.50 per meter, and Reject, Counter, Accept.

    Reject, Counter or Accept.

  3. Accepted

    A card from the buyer's Approved list: Shahi Exports Private Limited, Nylon-Spandex Smooth Knit, with a green Approved tag.

    No buttons left. It's done.

The buttons on a card are whatever that side can do in that state.

What changed?

09

BeforeAfter
Starting pointSeparate buy and sell orders; either side startsThe buyer's RFQ
ConnectionNot yet definedHS code filters relevant suppliers; they choose to respond
NegotiationStages still to be definedDefined states and transitions
Next moveUnclearSet by the state
From independent order activity to a defined negotiation flow.

What I took away

I started by looking at the Buy Order and Sell Order pages, but the harder problem was what happened between them.

Mapping the real journeys helped me rethink who should start the interaction. From there I defined the RFQ's states, actions and transitions, so the negotiation had a structure both sides could follow.

The biggest change wasn't another order screen. It was the logic that connected the two sides.

What I delivered

  • A buyer-initiated RFQ interaction model.
  • An HS-code-based supplier-relevance flow.
  • RFQ state-transition logic, including action ownership and negotiation rules.
  • Product interfaces that turned the model into distinct RFQ and quote states.

Current status: in beta. The redesigned RFQ experience is available to beta users.