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, and both are always on. There is no switch: you choose which one to lead with in your menu and marketing, and when to start promoting the other. 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 spend far less time quoting.
• 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. 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 very small briefs, so promote request mode for work big enough to justify the effort.

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:

Lead with 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).

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

• Some of your demand will sit in the other mode. Promoting 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. In browse mode, the buyer fills the vendor’s intake form right after checkout. In request mode there is no vendor form, so the buyer submits their details and files on a plain requirements page after paying. A milestone contract skips this step because it starts In Progress.
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 decision that lets one plugin handle both marketplace shapes without duplicating logic.

A request, step by step

If you are used to the catalog, request mode has a few more moving parts. This is the path one brief takes.

1. A buyer posts a request with a title, description, budget, deadline and optional attachments. Requests expire after 30 days by default, so an abandoned brief doesn’t sit on the board for ever.
2. Vendors read the request and send proposals. Each proposal has a cover note, a quote and a timeline, and the vendor picks a contract type: fixed price or milestone.
3. The buyer compares proposals side by side. Milestone proposals show the full phase list before the buyer commits.
4. The buyer accepts one. A fixed-price proposal goes to checkout for the full amount, and the order waits for requirements. A milestone proposal creates the order immediately with a zero base price, and the buyer pays phase by phase.
5. From payment onwards, the order follows the same lifecycle as a catalog order.

Which checkout you run matters for step 4. Fixed-price proposals work on any supported checkout, but milestone phases need the standalone checkout or WooCommerce, which is a Pro feature. The milestone payments guide covers what that means for money.

Setting up both modes on one site

Neither mode needs switching on. There are no toggles in settings, because buyer requests cannot be switched off, so the real decisions are about emphasis.

• Put your lead mode in the main menu and the other under a smaller link, such as “Post a request” beside “Browse services”.
• Use the service grid and featured services blocks for the catalog, and the buyer requests block to show open briefs on a page of your choosing.
• Decide how new vendors join, with open registration or your approval, since the vendors you admit are the ones who will answer requests.
• Check the email settings, since proposal and request emails are separate switches from the order emails.

The request marketplace use case and the freelance marketplace use case show complete setups for each lead mode.

Mistakes when running both

• Launching both at full volume. A new marketplace with few vendors can’t answer many requests, and an empty request board looks worse than a small catalog.
• Leaving requests unanswered. A brief that gets no proposals teaches the buyer not to return. Watch the board and nudge relevant vendors.
• Forcing custom work into a package. If a vendor keeps adding “contact me first” to their listings, that work belongs in request mode.
• Expecting identical commission timing. Catalog orders credit on completion, milestone phases on approval. Explain this to vendors early.
• Ignoring the difference in effort. A catalog sale takes the vendor one click. A proposal takes thought. Vendors need to know what each costs them.

What to look at after a month

You don’t need elaborate analytics to learn which mode is working. A few plain counts are enough, and the admin orders list gives you most of them.

• How many orders came from catalog purchases and how many from accepted proposals.
• How many requests received at least one proposal, and how many received none.
• Which categories attract requests but have few catalog listings. That gap is where new productized services could go.
• Which vendors sell in both modes, since they are the ones to learn from.

Vendor and admin analytics dashboards with export are a Pro feature, if you want these numbers drawn for you. Everything above can be read from the free plugin’s lists.

For comparison with the hosted platforms that popularised each shape, the Fiverr alternative page and the Upwork alternative page set out the trade-offs plainly.

Commission and pricing implications

Browse mode commission is straightforward: a percentage of the order value, fixed when the buyer pays, and credited to the vendor’s earnings when the order completes. One global rate, with per-vendor overrides.

Request mode commission is fixed when the buyer accepts a proposal and pays. Same percentage, just deferred to the accepted-quote moment. On a milestone contract it is fixed phase by phase, and each phase is credited when the buyer approves it. Vendors are used to this pattern from Upwork.

For both modes, Pro adds tiered commission rules, which can vary the rate by service category, seller level or sales volume. That lets you reward top sellers with a lower rate once you have some worth keeping.

An example: a small design marketplace running both

Picture a marketplace for brand design. It launches with a catalog of productized services: a logo package, a social media kit, a business card design. Each has three tiers, an intake form that asks about brand colours and style, and a delivery time. Buyers browse, pay and fill the form.

A few months in, buyers start asking for things the packages don’t cover: a full rebrand, a packaging range, a pitch deck with illustrations. Instead of stretching the catalog, the owner promotes “Post a request”. A buyer describes the rebrand and a budget. Three vendors send proposals, one as a fixed price and two as milestone plans with a discovery phase, a concept phase and a final delivery phase. The buyer picks a milestone plan, pays the first phase, and the project runs in lock-step from there.

Meanwhile the same vendors keep their catalog listings. The logo package brings steady small orders, and the requests bring the larger projects. Reviews from both kinds of work build the same seller level, so a vendor who started with small packages earns the trust that helps them win a bigger proposal.

Questions to settle before you choose a lead mode

Answer these honestly and the right lead mode usually becomes obvious.

1. Can a typical job be described in a sentence and priced in advance? If yes, lead with browse.
2. Do buyers usually need to explain their situation before a price makes sense? If yes, lead with request.
3. Do your vendors prefer to wait for work to come to them, or to chase it? Catalog suits the first group and proposals suit the second.
4. How large is a typical job? Larger jobs justify proposals and milestone plans.
5. How much can you moderate? A request board needs attention to stay healthy, while a catalog mostly looks after itself.

None of these locks you in. Because both modes are always available, changing your emphasis later costs a menu edit and some new marketing, not a rebuild. The features page lists everything else the plugin ships, and free versus Pro shows which parts of each mode need a licence.

Picking your launch mode

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

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

Try both

The InstaWP demo has both modes ready to try. 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.