Browse vs request: the two marketplace modes and when to use each

Most marketplace plugins make you choose: are you building a Fiverr-style catalog where buyers shop fixed packages, or an Upwork-style request board where buyers post briefs and vendors quote?

WP Sell Services ships both. They run in parallel. You can launch with one mode, add the other later, or run both from day one. Most marketplaces eventually want both because demand has two shapes.

This post walks through when each mode wins, when you need both, and what the data flow looks like in each case.

Browse-and-buy: when the work is productized

Browse mode treats services like products. Vendors publish listings with three-tier pricing (Basic / Standard / Premium), gallery images, an intake form, and a fixed delivery time. Buyers shop the catalog, filter by category or price, pick a package, pay, fill the form, and the order starts.

This works when the work is standardized enough to package:

• A 1-hour piano lesson at $50.
• A logo with 3 concepts + 2 revisions at $200.
• A 5-page WordPress site at $1,500.
• A 500-word product description at $30.
• A 30-second voiceover at $50.

The buyer knows roughly what they need. The vendor has done this exact thing many times. The price is predictable. The deliverable fits in a clear box.

Browse mode wins when:

• Buyers want to compare options quickly. Catalog + filters + reviews + price + delivery time, all visible at a glance.
• Vendors want to scale. A productized listing converts visitors into orders without per-buyer negotiation. Vendors who package well 10x their throughput.
• The work is repeatable. Same brief, same process, same deliverable shape every time.

It loses when the work is genuinely custom every time, because forcing a $25,000 audit into a 3-tier card is awkward and erodes vendor trust.

Request mode: when the work is custom by nature

Request mode (sometimes called RFQ. Request for quote) flips the marketplace. Buyers post a brief: project title, description, budget range, deadline, attachments. Eligible vendors see it, send proposals (cover note + quote + timeline), buyer compares proposals and picks one. The accepted proposal converts into an order and the standard delivery / revision / complete workflow runs.

This works when the work is inherently variable:

• Custom web development with unique requirements.
• Consulting engagements with company-specific context.
• Plumbing jobs (every house is different).
• Translation work where source material matters.
• Video editing with raw footage of unknown shape.
• Legal-adjacent work where the answer depends on the question.

Request mode wins when:

• The buyer can’t fully spec the job upfront. They know the outcome; they need vendors to scope the path.
• Vendors compete on approach, not just price. A good proposal shows the vendor’s understanding of the brief. The buyer picks based on that, not just lowest bid.
• Average order value is high enough to justify the proposal effort. Vendors won’t write thoughtful proposals for $50 briefs. Aim for $500+ briefs minimum.

It loses when buyers want instant gratification (browse mode is faster) or when vendors don’t have time to write proposals for every brief (they prefer the productized catalog model).

When to run both

Most marketplaces hit a point where they need both. The pattern:

Launch in one mode matching your primary demand:

• Consumer-facing freelance services: browse mode.
• B2B custom work (development, consulting, design): request mode.
• Local home services: request mode (every job is custom).
• Tutoring / coaching: browse mode (packages are standardized).

Add the second mode at month 3-6 once you have proof the first is working. Why:

• 30-40% of demand sits in the “other” mode. Adding it captures buyers you’d otherwise lose.
• Vendors who’ve earned reputation in browse mode can use request mode to upsell custom work.
• Buyers who started with a custom brief can return to browse mode for follow-up needs.

You’ll often see a vendor with 5 productized listings in the catalog AND active proposals on briefs. That’s a healthy vendor pattern. Same plugin, two shapes of revenue.

What the data flow looks like

Both modes share the post-acceptance workflow. After payment, every order. Whether it came from browse-and-buy or from a buyer-request proposal. Runs the same lifecycle:

1. Requirements collection. If browse mode, the buyer filled the vendor’s intake form at checkout. If request mode, the brief already includes the equivalent info.
2. In progress. Vendor works, buyer can message via the built-in chat.
3. Delivery submission. Vendor uploads files + a note.
4. Revision (optional). Buyer requests changes within the agreed revision count. Vendor redelivers.
5. Auto-complete. If the buyer doesn’t respond within the configured window, the order auto-completes and the vendor earns out.
6. Review. Buyer leaves a star rating. Reviews feed into seller levels.

The pre-acceptance flow differs (catalog browsing + checkout vs brief + proposals + accept), but everything from “paid” onwards is identical. This is the architectural unlock that lets one plugin handle both marketplace shapes without duplicating logic.

Commission and pricing implications

Browse mode commission is straightforward: percentage of the order value, taken at checkout, vendor sees their share in earnings. Configurable flat % across all categories.

Request mode commission is taken when the buyer accepts a proposal and pays. Same percentage, just deferred to the accepted-quote moment. Vendors are used to this pattern from Upwork (10-20% take rate is the norm).

For both modes, Pro adds tiered commissions (lower rates for higher-tier vendors) which significantly improves vendor retention once you have top sellers worth keeping.

Picking your launch mode

If you’re launching this week and can only pick one:

Add the other mode once you have traffic and at least 20 active vendors. Adding it too early dilutes vendor focus on the primary mode.

Try both

The InstaWP demo has both modes enabled by default. Walk through one purchase as a buyer in browse mode, then post a brief and respond as a vendor in request mode. 25 minutes total to feel both shapes from both sides.

If you only have time for one, run the request-mode flow. It’s the workflow most marketplace plugins don’t ship cleanly, and it’s where WP Sell Services differs most from the WooCommerce-stack approach.