What you’re building
A reverse marketplace: instead of vendors publishing services and buyers shopping a catalog, buyers post requests (“Need a Python developer for a 2-week scraping project, $3,000 budget”), vendors send proposals, and buyers pick one.
Upwork, Freelancer.com, ServiceMarket. All built on this pattern. The plugin ships it as a first-class mode alongside the Fiverr-style browse-and-buy. Both modes are always on, and you choose which one to lead with.
When request mode wins over browse mode
Request mode works best when:
- The job is custom by nature. Web development, legal work, plumbing, custom illustration. No two requests are identical.
- Budget varies wildly. A “build me a website” brief might be $500 or $50,000. Vendors quote per brief, not per fixed package.
- Buyers need to qualify vendors. Reviewing 3-5 proposals lets them assess fit before committing money.
- The deliverable is hard to package upfront. “Audit my codebase” doesn’t fit a 3-tier price card cleanly.
When the job is standardized (logo design, 1-hour tutoring, voiceover), browse-and-buy converts better because it removes the “wait for proposals” step.
The 30-minute setup
- Wizard. Marketplace name + currency + commission. For request marketplaces, commission is typically charged on the accepted proposal value (e.g., 10% of the $3,000 quote).
- Lead with requests. There is nothing to switch on: buyer requests and the catalog are both always available. Put the post-a-request page in your main menu so buyers start there.
- Categories. Apply to requests, not just services. Buyers categorize their brief (Development, Design, Writing, Legal, etc.) so vendors can spot the relevant ones.
- The brief form. Its fields are fixed: title, description, category, budget, delivery days, attachments, required skills and an expiry date. It is separate from the per-service requirements form.
- Who can propose. Any approved vendor can see an open brief and send a proposal. There is no category or level gate, so your quality control happens when you approve vendors.
The proposal flow
- Buyer posts a brief (free, no charge to post).
- Approved vendors see it in the list of open requests.
- Vendors send a proposal: cover letter, price, delivery time in days, optional file attachments (case study, portfolio sample). A vendor can also offer a milestone plan instead of one fixed price. The buyer gets an email when a proposal arrives.
- Buyer reviews proposals, messages back-and-forth via built-in messaging, picks one.
- Buyer pays the accepted quote → standard order workflow runs (requirements, delivery, revisions, complete).
What makes WP Sell Services different from a generic RFQ plugin
Most “request a quote” WordPress plugins drop after step 3. They don’t have the order workflow that runs after acceptance. WP Sell Services treats an accepted proposal as the trigger that converts the brief into an order. From there, the same delivery / revision / dispute / review machinery runs as for a browse-and-buy order.
That’s the unlock: one plugin handles both halves of the marketplace.
Vendor behavior to design for
Request marketplaces have a quality problem: low-effort vendors send template “I can do this, $50, message me” proposals on every brief. This kills buyer trust fast.
Counters built into the plugin:
- Vendor approval. You approve vendors before they can sell, so low-effort accounts never reach your briefs.
- Vendor reputation carries from completed orders. Ratings and the vendor’s level (New, Rising, Top Rated or Pro Seller) sit on their profile, so buyers can check before they accept.
Pricing the marketplace
Two commission structures work for request marketplaces:
- % of accepted proposal value (10-15%). Default. Scales with deal size.
- Vendor subscription + low commission. Vendors pay $29-99/mo to access briefs + send proposals; you take 5-8% commission. Best LTV per vendor.
For B2B marketplaces (RFQs over $5k average), the subscription model produces the best margins. For consumer-facing (under $500 brief), % commission wins.
Disputes are higher in request mode
Custom work + bigger budgets = more disputes. The plugin’s dispute system carries the full proposal + message history + delivery files + revision requests. Build a clear policy:
- Refund triggers: vendor missed deadline by >5 business days, deliverable doesn’t match accepted scope.
- Partial refund triggers: scope creep, mid-project pivot, mutual cancellation.
- No-refund triggers: buyer didn’t respond for >14 days post-delivery (order auto-completes on this).
Publish the policy on a /policy/ page. Apply it consistently.
When you’ll need Pro
- WooCommerce checkout for large proposal values where buyers want invoicing + PO numbers + regional payment methods.
- Stripe Connect or PayPal Payouts once you’re paying 50+ vendors a month.
- Vendor analytics so vendors can see proposal-to-acceptance rates and improve.
- Vendor subscriptions for the subscription commission model.
Common questions
Can I run only request mode (no browse catalog)? Both modes are always on, and there is no setting to turn the catalog off. Lead with requests in your menu and leave the catalog out of it. Many B2B marketplaces work this way.
Can buyers re-engage the same vendor for a follow-up project? Yes. Built-in messaging persists across orders. They can DM a past vendor and start a new brief directly.
What about NDAs / private briefs? There are no private briefs: every open brief is visible to your approved vendors. Keep confidential detail out of the brief and share it in the order messages once you’ve picked a vendor.
Try it
The InstaWP demo has buyer requests ready to try. Post a brief as a buyer, propose on it as a vendor, run through accept → pay → deliver. 15 minutes to see if the reverse-marketplace pattern fits.