How to Build an Upwork-Style Request Marketplace with WP Sell Services

Post a catalog listing and you’re betting that a buyer’s problem fits neatly into a fixed-price box: “Logo design, $150,” “Blog post, 1,000 words, $80.” That works when the job really is standardized. It falls apart the moment someone needs a custom WordPress build, a twelve-article content series tied to a launch date, or a six-week data migration, because none of those fit a single price tag, and the buyer usually can’t even specify the full scope until a vendor has asked a few questions.

That’s the gap the request-and-proposal model closes, and it’s the same model that made Upwork the default choice for bigger, messier, more custom engagements while Fiverr stayed the home of the $25 gig. Instead of browsing a shelf of fixed packages, the buyer posts a brief: what they need, a budget range, and whatever files or context make the problem concrete. Vendors who can actually do the work respond with their own proposal, their own price, their own timeline, and a cover letter that proves they read the brief instead of copy-pasting a template pitch. The buyer compares real answers from real people instead of guessing which catalog listing is close enough.

WP Sell Services, a WordPress plugin from Wbcom Designs, ships this exact mechanic, buyer requests and vendor proposals, in its free plan, alongside the option for vendors to split a larger award into milestones instead of one lump-sum payment. This guide is specifically about building a marketplace around that request-and-proposal model: how to set up request categories and the brief fields that keep a buyer’s post usable, how to configure what a vendor proposal has to include, how to structure milestone contracts for projects too large to pay for upfront, how to keep low-effort proposal spam from drowning out serious bids, and how payouts actually move once a project is split into phases. If your buyers are describing custom projects rather than shopping a catalog, this is the half of WP Sell Services built for them.

Last updated: 6 November 2026

Table of Contents

• The Request Model vs. the Catalog Model
• Step 1: Set Up Buyer Request Categories and Brief Fields
• Step 2: Configure Vendor Proposal Submission
• Step 3: Set Up Milestone-Based Contracts for Larger Projects
• Step 4: Quality Control for Proposal Spam
• Step 5: How Payouts Work Per Milestone
• Real-World Scenario: A Marketplace for Web Development Projects
• Get Started with WP Sell Services
• Frequently Asked Questions
• Conclusion
• Sources

The Request Model vs. the Catalog Model

It’s worth being precise about what changes when a marketplace runs on requests instead of (or alongside) a catalog, because the difference shapes nearly every setup decision in the rest of this guide.

In a catalog model, the vendor sets the terms up front. They write a listing, price it in three tiers, and wait for a buyer to find it through search or browsing. The buyer’s only real decision is which existing listing comes closest to what they need. That’s an efficient model for standardized, repeatable deliverables, a logo, a voiceover, a 500-word blog post, where the range of reasonable scope is narrow enough that a fixed menu covers it.

In a request model, the buyer sets the terms up front instead. They describe the actual problem, not a pre-defined deliverable, attach whatever context exists, and name a budget range they’re willing to work within. Vendors then compete on how well they understand that specific problem, not just on price. A web development shop might propose a different tech stack than a competitor; a content agency might propose a different research process. The buyer isn’t choosing between near-identical listings, they’re choosing between different approaches to the same brief, which is exactly the decision a complex or custom project needs them to be able to make.

WP Sell Services doesn’t force a choice between the two. Three-tier packages and buyer requests both ship in the free plan, and a marketplace owner can run both side by side, catalog listings for the standardized work, requests for everything that doesn’t fit a fixed price.

Factor	Catalog Model	Request Model
Who sets the terms first	Vendor (fixed listing)	Buyer (brief + budget range)
Best fit	Standardized, repeatable deliverables	Custom, variable-scope projects
Buyer’s decision	Which listing is close enough	Which approach and price fit best
Price discovery	Fixed, set in advance	Competitive, via proposals
Payment structure	One-time, on checkout	Fixed sum or milestone phases

The rest of this guide focuses specifically on configuring the request side well, because a request feature that’s switched on but poorly configured produces vague briefs, mismatched proposals, and a marketplace that looks broken even though the mechanism underneath is sound.

---

Step 1: Set Up Buyer Request Categories and Brief Fields

A buyer request is only as useful as the information it forces the buyer to provide. Left completely open-ended, most buyers write two sentences, leave the budget field blank or absurdly wide, and attach nothing, which means every vendor who considers responding has to ask clarifying questions before they can even estimate a price. That back-and-forth is exactly what the request model is supposed to skip.

Start with categories. WP Sell Services lets you define request categories the same way you’d define service categories, and the category a buyer picks should determine which fields they’re asked to fill in next. A “Web Development” request category and a “Long-Form Content” request category don’t need the same brief structure: one needs a tech stack question and a hosting environment field, the other needs a word count range and a style-guide upload. Build out category-specific requirements rather than a single generic form that tries to cover every type of project with the same four questions. A generic brief form is the single biggest reason request marketplaces fill up with unusable posts.

Within each category, three fields matter more than the rest and are worth making mandatory rather than optional:

• Budget range, not a single number. A buyer who doesn’t know the market rate for a service will either lowball it to zero (and get no serious proposals) or leave it blank (and get proposals spanning a 10x range that waste everyone’s time). A range, even a wide one like “$2,000-$6,000,” tells vendors whether the project is worth their time before they write a proposal, and it anchors the negotiation that follows.
• Structured requirements, not a free-text box alone. Use the Requirements setup to ask specific, category-relevant questions: current tools in use, hard deadlines, whether there’s an existing codebase or content library to work from, who the final decision-maker is. A free-text description still has a place, buyers should be able to explain the problem in their own words, but pairing it with structured questions is what keeps the brief from depending entirely on how articulate a given buyer happens to be.
• Attachments. A messy spreadsheet, a half-built Figma file, a style guide, a link to the existing site, these do more to scope a project accurately than another paragraph of description ever will. Make sure file uploads are enabled on the request form and that the accepted file types cover what your category actually needs (design files, documents, spreadsheets, not just images).

Buyer posts a brief with a title, description, category and budget range, with attachments. Vendors respond with their own proposals. The buyer awards one, and acceptance turns it into a real order on the agreed terms.

One configuration choice worth making deliberately: whether a request is visible to all vendors in that category or only to vendors who’ve been invited or pre-qualified. For a general marketplace, open visibility maximizes the number of proposals a buyer receives, which is good for price discovery but also raises the spam risk covered in Step 4. For a marketplace built around higher-stakes categories, web development, legal, finance, gating request visibility to vetted vendors in that category keeps proposal quality higher at the cost of fewer total responses. Neither setting is universally correct; it depends on whether your marketplace is optimizing for buyer choice or for buyer confidence.

Step 2: Configure Vendor Proposal Submission

Once a brief is live, vendors respond with proposals, and a proposal in WP Sell Services carries three required components: an amount, a delivery timeline in days, and a cover letter. How you configure and present these three fields determines whether a buyer can actually compare proposals or just ends up picking whichever one showed up first.

Amount. This is the vendor’s price for the brief as written, not a starting quote they plan to renegotiate after award. Set the expectation in your marketplace guidelines (and ideally in the proposal form’s helper text) that the amount submitted should reflect the full scope described in the brief, since an artificially low number that gets “corrected” after the buyer awards the job is the fastest way to burn trust in a request marketplace. If a vendor genuinely can’t price the job from the brief alone, the cover letter is the place to say so and ask the clarifying question, not the amount field.

Delivery timeline. Measured in days, this is what lets a buyer weigh speed against price instead of comparing price alone. A marketplace that surfaces timeline prominently next to amount, rather than burying it inside the proposal detail view, helps buyers make a genuinely informed trade-off: the cheaper proposal with a six-week timeline versus the pricier one that delivers in ten days. Encourage vendors to commit to a realistic number here rather than lowballing the timeline to win the award; a late delivery is tracked through the order’s state machine (more on that in Step 3), and a pattern of missed timelines shows up in a vendor’s review history over time.

Cover letter. This is the part that separates a request marketplace from a reverse auction. A cover letter that references specifics from the brief, “given the WooCommerce + custom checkout stack you mentioned, here’s how I’d approach the migration”, does more to win a complex-project award than the lowest number on the page. A cover letter that’s obviously templated, generic enough to paste onto any brief in the category, is the clearest signal of a low-effort proposal. If your marketplace allows a minimum character count or asks a specific prompt (“what’s your approach to this exact brief?”) rather than leaving the cover letter field totally open, you’ll filter out a meaningful share of copy-paste proposals before a buyer ever has to read them.

Once a buyer has proposals in hand, the decision isn’t just “which proposal is best,” it’s “which contract type is best for this award.” The vendor also chooses, at proposal time, whether the engagement is priced as a single fixed sum or split into milestones. That choice is the subject of the next step, and for anything beyond a small, short engagement, it’s usually the more important decision than the headline price.

---

Step 3: Set Up Milestone-Based Contracts for Larger Projects

Nobody sends a few thousand dollars to a stranger they met an hour ago, and a request marketplace that asks buyers to do exactly that for every award will quietly cap itself at small, low-trust projects. WP Sell Services solves this with fixed-or-milestone contracts, built into the free plugin: when a vendor submits a proposal, they choose whether the award is paid as one lump sum on completion or split into a sequence of phases, each one paid and approved before the next phase unlocks.

A vendor bidding on a posted job chooses how they want to be paid: one sum, or phases. Each phase is paid and signed off before the next one opens, and the plugin enforces that sequencing rather than relying on the two parties to honor it informally.

For a request marketplace specifically, milestones should map onto natural checkpoints in the type of project your category covers, not an arbitrary even split. A few patterns worth setting as guidance for vendors in your marketplace documentation:

• Web development: Phase 1, discovery and technical spec. Phase 2, core build. Phase 3, QA, revisions, and launch. Each phase has a concrete, inspectable deliverable the buyer can actually evaluate before releasing the next payment, rather than “50% now, 50% later,” which gives the buyer nothing to approve against except a promise.
• Long-form content series: Phase per batch of articles (say, three or four pieces) rather than per individual article, which keeps administrative overhead reasonable while still protecting the buyer from paying for twelve articles before seeing whether the first three hit the brief.
• Data or system migrations: Phase 1, audit and migration plan. Phase 2, staged migration with rollback tested. Phase 3, cutover and verification. This structure protects the buyer from the worst-case scenario in migration work, a vendor who’s moved data irreversibly before anyone confirmed the plan was sound.

Project type	Phase 1	Phase 2	Phase 3
Web development	Discovery and spec	Core build	QA and launch
Long-form content	First article batch	Second batch	Final batch and edits
Data migration	Audit and plan	Staged migration	Cutover and verification

The mechanics matter as much as the structure. Each phase is paid and approved before the next one unlocks, and the plugin enforces that sequencing rather than relying on the two parties to honor it informally, which is the detail that actually makes milestone billing trustworthy instead of just a line item in a contract neither side can verify. The order itself moves through eleven defined states, from pending payment through pending requirements, in progress, pending approval, revision requested, on hold, late, disputed, and on to completed or cancelled, and for a multi-phase award spanning weeks or months, both sides can see exactly where things stand without reconstructing the history from an email thread.

Set a sensible default in your marketplace guidance: three to four phases for most mid-size custom projects. Fewer than that and milestone billing barely improves on a straight fixed price; more than that and the administrative overhead of approving each phase starts to outweigh the protection it buys. Let vendors propose the exact phase count and deliverables per phase in their proposal, since they’re the ones who actually know how the work breaks down. Don’t leave new vendors without a template, though; a sample milestone structure per category in your onboarding docs saves both sides a round of back-and-forth on every single award.

---

Step 4: Quality Control for Proposal Spam

Open a request marketplace to unlimited vendor responses and the failure mode isn’t too few proposals, it’s too many low-effort ones. A buyer who posts a brief and gets back twenty near-identical, barely-customized pitches has a worse experience than a buyer who gets back four thoughtful ones, even though the first buyer technically has more choice. Proposal spam is the request-model equivalent of catalog race-to-the-bottom pricing, and it needs its own set of controls rather than being treated as an unavoidable cost of an open marketplace.

A few mechanisms, used together, keep proposal quality from collapsing as the marketplace grows:

• A proposal limit per request, or a submission cost. Capping the number of proposals a single brief can receive (say, fifteen) creates urgency and discourages vendors from treating every brief as a free lottery ticket. If your marketplace handles higher-value categories, consider a small submission cost or a Connects-style credit system for proposals; a vendor who’s spending something, even a small credit, to respond thinks harder about whether the brief is actually a fit before hitting submit.
• Minimum vendor standing to respond to higher-budget requests. Gate requests above a budget threshold to vendors with a minimum review count or rating, the same way a consulting directory gates its top-tier category. A brand-new vendor with zero completed orders can still respond to smaller, lower-risk briefs, but a $15,000 request shouldn’t be open to an account that joined yesterday.
• Cover letter requirements that filter at the point of submission. As covered in Step 2, a minimum length or a required prompt specific to the brief does real filtering work before a human ever has to read a bad proposal. This is the cheapest control to implement and the one with the highest return relative to effort.
• Visible proposal history for vendors. Because reviews and order history are tied to completed orders in the free plugin, a buyer evaluating proposals can see which vendors actually have a track record of finishing what they bid on, not just who bid the lowest or fastest. Surface that history prominently next to each proposal rather than requiring a buyer to click into a separate profile page for every bidder.
• A reporting path for obviously spam or scraped proposals. Give buyers a one-click way to flag a proposal that’s clearly templated or irrelevant to the category, and review flagged vendors periodically. A marketplace that never acts on these reports trains its best vendors to stop bothering with thoughtful proposals, since they’re competing against noise that never gets cleaned up.

None of these controls require custom development; they’re a mix of plugin configuration (proposal limits, requirement fields) and marketplace policy (minimum standing, reporting follow-through) that a marketplace owner sets and enforces. The common thread is that every control should raise the cost of a low-effort proposal without raising the cost of a genuine one, since the goal is better signal, not fewer total responses.

Step 5: How Payouts Work Per Milestone

Money moving in phases rather than all at once changes what “getting paid” means for a vendor, and it’s worth being explicit with vendors about exactly when funds move, because ambiguity here is one of the fastest ways to erode trust in a request-and-milestone marketplace.

Each phase is paid and approved before the next one unlocks. Nothing beyond the current phase is ever at risk for the buyer, and work on an approved phase is work that’s already been paid for, not a promise resting on goodwill.

The sequence for a milestone award runs the same way regardless of plan: the buyer pays into the order at the point they accept a proposal (or at the point each phase is funded, depending on how the vendor structured the milestone plan), the vendor delivers against that phase, and the buyer approves it. Only then does the phase close out and the next one unlock.

Where the free and paid plans diverge is in how the vendor actually receives that money once a phase clears. On the free plan, payouts are handled manually: the marketplace owner clears vendor balances after a clearance period they set and pays out by hand. That’s workable for a smaller marketplace or one just getting its request-and-milestone flow off the ground.

But manual payouts become a real operational cost once more than a handful of vendors are running multi-phase engagements simultaneously, because every phase approval is a payout event, not just every completed order. A marketplace running three active vendors through three-phase web development contracts is generating nine separate payout events to track by hand, not three.

The Personal plan ($99/year) adds Stripe Connect, which automates this: the vendor is paid automatically at the moment of sale or at each milestone approval, rather than waiting for the marketplace owner to run a manual payout batch. PayPal Payouts on the same plan lets you batch-pay everyone owed in a single triggered run when Stripe Connect isn’t the right fit for a given vendor. For a marketplace where milestone billing is the normal way business gets done, not the exception, this is less an optional convenience and more the piece of infrastructure that lets the request model scale past a founder manually approving and wiring every phase.

Commission on milestone awards works the same as it does on any other order: a global rate from 0 to 50 percent that the marketplace owner sets, with per-vendor overrides available for established vendors you want to offer a reduced rate. That commission is taken per phase as it clears, not as one lump deduction at the end of the full engagement, which keeps the marketplace’s own revenue arriving in the same rhythm as the vendor’s.

---

Real-World Scenario: A Marketplace for Web Development Projects

Picture a niche marketplace built for a community of WordPress agencies and freelance developers, think of it as the kind of focused, trust-based alternative to posting a generic job on a general freelance platform and hoping a qualified developer notices it. The founder installs WP Sell Services on a WordPress site already serving that community and sets up two request categories to start: “Custom Theme or Plugin Build” and “Site Migration,” each with its own brief fields, tech stack, current hosting, existing codebase link for the build category, and source platform, data volume, and downtime tolerance for the migration category.

A buyer posts a brief in the migration category: moving a 40,000-product WooCommerce catalog off a legacy host with minimal downtime, budget range $4,000-$8,000, with a spreadsheet of current plugins attached. Within three days, six vendors respond. Two are filtered out immediately by a buyer skimming cover letters, one is a generic pitch that never mentions WooCommerce, the other quotes a price without acknowledging the 40,000-product volume at all. Of the remaining four, proposals range from $4,200 to $7,500, with delivery timelines from three to seven weeks, and the buyer narrows to two finalists based on a combination of price, timeline, and the specificity of their migration approach in the cover letter.

The winning vendor proposes a three-phase milestone structure: Phase 1, full audit and a written migration plan with a rollback procedure, priced at $1,500. Phase 2, staged migration to a sandbox environment with verification, priced at $3,500. Phase 3, production cutover and a two-week monitoring window, priced at $1,500.

The buyer approves Phase 1 after reviewing the migration plan, which surfaces two plugins with known WooCommerce compatibility issues that weren’t on anyone’s radar before the audit, an outcome that validates paying for the audit as its own phase rather than bundling it into a single upfront quote. Phase 2 and Phase 3 proceed on schedule, each paid and approved before the next unlocks, and the order completes a little over six weeks after it started, fully documented on the order page rather than scattered across email and Slack.

Three months in, the marketplace has processed eleven migration awards and nineteen custom build awards, almost all running through milestone contracts rather than fixed-price-in-full. The founder upgrades to the Personal plan once manually tracking and paying out roughly a dozen active multi-phase engagements at once stops being a once-a-week task and starts eating a meaningful chunk of a workday; Stripe Connect then pays each vendor automatically as their phases clear. The request-and-milestone model didn’t just make the marketplace possible, it’s the reason buyers trusted it with $4,000-plus engagements in the first place, something a catalog of fixed-price listings was never going to capture for this kind of work.

---

Get Started with WP Sell Services

Buyer requests, vendor proposals, and fixed-or-milestone contracts are all included in the free plan of WP Sell Services, no feature gate on the mechanics that make a request marketplace work. The Personal plan ($99/year) adds Stripe Connect and PayPal Payouts automation, WooCommerce integration, and vendor analytics with CSV export for marketplaces running enough milestone volume to need automated payouts. Visit wpsellservices.com to see the full feature list and get the plugin.

Summary

A catalog is the right tool when the work is standardized enough that a fixed price makes sense before anyone’s talked to anyone. The moment a project is custom, the scope is unclear until someone asks a few questions, or the engagement is big enough that nobody should pay for it all upfront, the request-and-proposal model is the one that actually fits. WP Sell Services ships that model free: buyer requests with structured briefs, vendor proposals with price, timeline, and a cover letter, and the choice between a fixed sum or a milestone plan split into phases, enforced by the plugin rather than left to an honor system.

None of the configuration in this guide, category-specific brief fields, proposal quality controls, a sensible default milestone structure per category, requires the paid tier to set up. It requires treating the request side of the plugin as the primary product for custom work, not an afterthought bolted onto a catalog. Upgrade to Personal once there’s enough milestone volume that manual payouts, not marketplace mechanics, are the actual bottleneck.

Frequently Asked Questions

Is the buyer requests and proposals feature really free?

Yes. Buyer requests, vendor proposals, and the choice between fixed-price or milestone contracts are all included in the WP Sell Services free plan, along with the full order workflow, disputes, reviews, commission handling, and manual withdrawals. There’s no paid tier required to run a request-and-proposal marketplace.

How is this different from just using catalog packages?

Catalog packages assume the buyer already knows exactly what they want and can match it to a pre-priced listing, which works for standardized, low-variance deliverables. Buyer requests work the opposite way: the buyer describes a custom problem with a budget range, and vendors propose their own price, timeline, and approach. WP Sell Services supports both models at once, so a marketplace can run catalog listings for standardized work and requests for everything that needs a custom scope.

What does a vendor proposal actually include?

Three required components: a price (amount), a delivery timeline in days, and a cover letter. The vendor also chooses, at proposal time, whether the engagement is paid as one fixed sum or split into milestone phases.

How do milestone contracts actually work?

A vendor responding to a buyer request can split the award into phases instead of one lump payment. Each phase is paid and approved before the next phase unlocks, and the plugin enforces that sequencing automatically rather than relying on an informal agreement between the buyer and vendor.

How many milestones should a project have?

There’s no hard rule built into the plugin, the vendor proposes the phase structure as part of their proposal, but three to four phases is a reasonable default for most mid-size custom projects. Too few phases barely improves on a flat fixed price; too many adds approval overhead without much added protection for either side.

How do I stop my request marketplace from filling up with low-effort proposals?

A combination of controls works better than any single one: a cap on proposals per request, a minimum cover letter length or a required brief-specific prompt, a minimum vendor rating or review count to respond to higher-budget requests, and a reporting path for obviously templated or spam proposals that the marketplace owner actually acts on. None of this requires custom development, it’s a mix of plugin configuration and enforced marketplace policy.

What happens if a milestone phase is late or disputed?

The order workflow includes “late” and “disputed” as defined states, tracked per order. If a dispute is opened, either the buyer or the vendor can submit evidence, messages and files, directly on the order, and the marketplace owner mediates toward one of five outcomes: full refund, partial refund, in favor of the vendor, in favor of the buyer, or a mutual agreement. This is included in the free plugin.

How do vendors actually get paid per milestone?

On the free plan, the marketplace owner clears vendor balances after a set clearance period and pays out manually, phase by phase. On the Personal plan ($99/year), Stripe Connect pays the vendor automatically at the moment of sale or at each milestone approval, and PayPal Payouts can batch-pay everyone owed in a single triggered run.

Can I limit which vendors see or respond to a buyer request?

You can configure request visibility by category and set minimum vendor standing (such as a review count or rating threshold) for higher-budget requests. Whether to keep requests fully open or gate them depends on whether your marketplace is optimizing for the widest possible proposal pool or for consistently higher proposal quality.

Does WP Sell Services charge commission on milestone-based orders?

Yes, the same way it does on any order: a global commission rate from 0 to 50 percent, with per-vendor overrides available. On a milestone award, commission is taken per phase as it clears rather than as one deduction at the end of the full engagement.

Can a marketplace built around requests still use three-tier packages too?

Yes. Catalog packages and buyer requests both run on the free plan and can operate side by side in the same marketplace, catalog listings for standardized, repeatable work, and buyer requests for custom projects that don’t fit a fixed price. Many marketplaces use both: packages to capture quick, low-commitment sales, and requests to capture the larger, custom engagements that a catalog listing can’t price upfront.

Sources

• Grand View Research: Freelance Platforms Market (press release)
• Wbcom Designs: WP Sell Services pricing and plans (checked 6 November 2026)

Interesting Reads

• Fiverr vs Upwork vs WP Sell Services: Which Marketplace Model Actually Pays Off?
• How to Build a Consulting Services Directory with WP Sell Services