The Problem
The Ofofo marketplace worked when a buyer knew what they wanted: browse, filter, compare, buy. But the buyers worth the most arrived without a product name in mind. A customer, an investor or a regulator had told them they needed "security sorted", they had money set aside and a deadline attached, and what they lacked was the vocabulary to turn that pressure into a marketplace search. Before this system their only route was to email the Ofofo sales team, who would ring round a few sellers and relay questions in both directions for weeks. Every one of those deals lived in inboxes the platform could not see, learn from or speed up. The custom request-for-proposal system, for short, became the answer: let the buyer describe the problem in their own words, let qualified sellers respond with structured proposals, and let the platform carry the negotiation from blank form to purchased order, 20 to 25 times a month once live.Research: Who the Catalogue Could Not Serve
The groundwork came from 2 research artefacts. The personas gave the human texture: Emily, the marketing manager whose company just got breached and needs recovery she can understand. Raj, the entrepreneur buying security to close enterprise deals. Daniel, the researcher gathering intelligence with no purchase intent. Only one of the three maps cleanly onto a catalogue. The sharper instrument was a segmentation: all 16 combinations of Budget, Authority, Need and Timing, each mapped to the features that would serve that visitor. It started as a sales exercise, but one row changed the product. The Interested Decision-Maker, the visitor with budget, authority and timing but no articulated need, was prescribed exactly one feature: request-for-proposal . The most commercially valuable person on the site was the one the catalogue could not help, and the flow existed for them.The Buyer's Side
The request form is where a vague obligation becomes a specification. The buyer names what they think they need, describes it in their own words, sets a maximum budget and picks a pricing model, with an escape hatch for anything the presets miss. Features and deliverables are added as tags rather than prose, which quietly produces the structured data sellers need to respond precisely. 2 dates, a closing date and an estimated start, give the request a clock.The Seller's Side
Incoming custom requests are demand, so they surface as a first-class on the seller's dashboard home alongside orders and offerings. The section is a pipeline table: request name, buyer, status, dates, and per-row actions to chat, view or draft a proposal.Tested, Then Changed
The flow went through 3 cycles of changes, each funded by watching real behaviour. The buyer's create form collapsed three structured inputs into one rich-text editor, gained PDF attachments, and renamed a passive Save to an honest "Raise Request". Requests became editable with success and failure , and RFP status was promoted onto the dashboard home and into a notifications tray, because a negotiation you have to go looking for is a negotiation that stalls. The seller side got the bigger change: the was rebuilt around a dual-role account, with a company switcher and a "Switch to Buying" toggle. Sellers buy security too, and the platform stopped pretending otherwise.Outcomes, and Where Each One Comes From
Every number on this page traces to something measured:- 40% to 52% proposal coverage: read in the admin dashboard before and after distribution changed from broadcast to targeted routing, for the ten sellers moved across in May 2024. Sellers left on broadcast in the same window returned about 17%. The change was made because only about half of sellers ever responded to a broadcast.
- 71% buyer-reported success: a satisfaction form sent to buyers after they pay, answered by about 90% of paying buyers. Of those who answered, 71% said the process worked. It is a satisfaction measure, not a task success rate.
- 20 to 25 RFPs a month, ~$5,000 average deal: platform records once live, not projections, with revenue recorded in Stripe. Six of every ten of those RFPs entered through the marketplace's zero-results page, so most of this pipeline was recovered demand that used to bounce.
- 16 BANT segments: the framing artefact itself, and the reason the RFP system was built at all.
Milestones
Aug 2023
Personas and BANT segmentation
16 budget, authority, need and timing combinations mapped to features, and the Interested Decision-Maker row made the case for an RFP system.
Sep 2023
Flow and IA across 3 roles
The end-to-end flow drawn across buyer, seller and admin lanes, with the governance rules fixed in the diagram before any screen existed.
Mar 2024
Cycle 1: the full RFP flow
The create form, the 3-pane workspace on both sides, the five-status ladder, and the approval-to-checkout handoff.
May 2024
Prototypes and targeted routing
Both journeys prototyped end to end and tested with 48 participants, and ten sellers moved from broadcast to tag-matched routing.
Jun 2024
Cycles of tightening
Rich-text editor, attachments, editable RFPs, Compare on every proposal card, status in notifications, and the dual-role chrome.
Lessons
- Your best buyer might be the one your catalogue cannot serve The exercise reframed the whole product. The visitor with budget, authority and a deadline but no product name was not an edge case, they were the highest-intent segment on the site, and they needed a different front door.
- Two-sided features live or die on shared vocabulary Buyer and seller read the same 5 statuses, defined in plain language from each side's view. The moment the two dashboards describe the same negotiation differently, trust in the system starts leaking.
- Governance rules are UX, write them early Edit locks until the first proposal, revision locks after shortlisting, remind-once throttles. None are screens, all are experience, and fixing them in the flow diagram meant no screen contradicted them.
- Structured inputs are a gift to the other side of the marketplace Features and deliverables as tags felt stricter than a free-text box, but that structure is what let sellers respond precisely and proposals be compared. It paid out twice when the same tags started routing each request to matching sellers.
FAQ
Because the research showed the most qualified visitors could not use the catalogue. The BANT segmentation mapped every combination of budget, authority, need and timing, and the segment with money, mandate and urgency but no articulated need had nothing to click. The RFP flow is their front door.
Rules fixed at the flow level. Buyers can edit a request only until the first proposal arrives, so sellers never answer a moving target. Sellers can revise a proposal only until it is shortlisted. Approved-but-unpaid buyers can be reminded exactly once. Custom requirements route through the admin instead of bending the form.
Because context and decision belong on one screen. The buyer reads a proposal with their own request still visible on the left, and the seller drafts with the buyer's requirement in view throughout. Nobody negotiates from memory, and the mirrored layout means learning one side teaches you the other.