← All use cases

Ask-for-service (Upwork-style)

How to build an Upwork-style request marketplace

Buyers post a brief. Vendors send proposals. Pick one and run the order workflow. Both modes ship in free.

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. You can run one mode, the other, or both.

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

  1. 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).

  2. Enable Buyer Requests mode. Settings → Marketplace Modes → toggle “Buyer Requests” on. (You can run both modes in parallel.)

  3. Categories. Apply to requests, not just services. Buyers categorize their brief (Development, Design, Writing, Legal, etc.) so vendors filter what’s relevant.

  4. Request form fields. Configure the global brief form: project title, description, budget range, deadline, attachments, required skills. Same plugin, slightly different schema from the per-service requirements form.

  5. Vendor matching rules. Decide who can propose:

    • Open: any approved vendor can propose on any brief. Simplest.
    • Category-restricted: vendors only see briefs in their listed categories. Better signal-to-noise.
    • Level-gated: only sellers above a level can propose on briefs over $X budget. Trust filter.

    Free plugin supports open + category-restricted. Level-gating is admin-side tagging.

The proposal flow

  1. Buyer posts a brief (free, no charge to post).
  2. Eligible vendors see it in their dashboard + get a notification email (out of the 25 templated emails).
  3. Vendors send a proposal: cover note, price quote, proposed timeline, optional file attachments (case study, portfolio sample).
  4. Buyer reviews proposals, messages back-and-forth via built-in messaging, picks one.
  5. 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:

  • Proposal review by admin (optional moderation). Reject spam proposals before the buyer sees them.
  • Vendor reputation carries from completed orders. Buyers see “Top Seller” / “Apprentice” badges on each proposal. They self-filter.
  • Limited proposals per brief (configurable). Cap at 10-15 to force vendor selectivity.

For your launch you’ll set the cap low (5-7) until you have enough vendor depth.

Pricing the marketplace

Three commission structures work for request marketplaces:

  • % of accepted proposal value (10-15%). Default. Scales with deal size.
  • Flat brief-posting fee (e.g., $10 to post a request). Predictable, lower friction on accepted proposals. Less common.
  • 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.
  • Automated payouts once you’re paying 50+ vendors a month.
  • Vendor analytics so vendors can see proposal-to-acceptance rates and improve.
  • Recurring services for ongoing engagements that started as one-off briefs.
  • Vendor subscriptions for the subscription commission model.

Common questions

Can I run only request mode (no browse catalog)? Yes. Toggle off the catalog in Settings. Many B2B marketplaces ship request-only.

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? Briefs can be marked private (visible only to invited vendors). NDA terms can be added as a required acknowledgement field on the brief form.

Try it

The InstaWP demo has buyer-requests mode pre-enabled. 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.