Marketplace Take Rate: A Founder’s Pricing Worksheet

A founder can sell a $250 service, keep a $50 commission, and still have almost nothing left after matching, support, acquisition, and payment costs. Raising the commission may fix the spreadsheet while making the provider refuse the next job.

A marketplace take rate is the share of a defined transaction value retained as platform fees. For a new service marketplace, choose it by testing two boundaries: the platform’s cost floor and the provider’s acceptable proceeds. If those boundaries do not overlap, there is no viable seller-side commission under the current assumptions. Change the offer or operating model before buying more demand.

Define the transaction before choosing a percentage

This guide uses a simple model: one fixed-scope service, one provider, and a commission deducted from the service price. There is no separate buyer fee. The customer pays the service price; the provider receives that price less the commission, before their own delivery costs. Taxes, tips, and pass-through charges are outside the example.

For this model, fee revenue equals service value multiplied by the commission rate. A $250 booking at 20% produces $50 in platform fees and $200 in provider proceeds. The $250 moving through the transaction is not all platform earnings, and the $50 is not net profit. This planning model does not determine how a particular business must recognize accounting revenue.

Write down the fee basis, who pays, what happens on cancellation, whether discounts reduce the provider’s proceeds, and which party bears each payment or recovery cost. If you add buyer fees, subscriptions, or several providers, rebuild the calculation rather than using the same percentage with a different denominator.

Sharetribe’s marketplace pricing guide treats marginal costs, transaction size, differentiation, and the fee-paying side as pricing inputs. That is more useful than importing an industry-average percentage into a service with different labor and support requirements.

Find the platform floor and provider ceiling

The platform floor: what must one completed job leave?

List the costs the platform actually bears for the chosen unit. Include payment and payout charges, coordination time, customer support, an allowance for recoveries, and acquisition effort allocated consistently across completed jobs. Give founder labor a planning cost even when no salary is paid.

Do not deduct provider compensation twice. In this seller-commission model, it has already been separated from platform fee revenue. Do include platform-funded provider bonuses or guarantees if they are additional costs.

Check the actual payment agreement. For example, BlueSnap’s marketplace documentation distinguishes processing fees based on the whole captured amount from vendor-management and payout fees. A processor’s charges need not be calculated only on the commission you retain.

Platform floor = (platform costs per completed job + desired remaining contribution) ÷ service value. Here, “remaining contribution” is a deliberately defined planning remainder after the listed costs, including the acquisition allocation. It still has to help cover fixed overhead and other expenses not already included; it is not net profit.

The provider ceiling: what proceeds make delivery worthwhile?

Ask qualified providers to assess a realistic request, not an abstract percentage. Specify service scope, preparation, travel if relevant, delivery evidence, likely revisions, payment timing, and cancellation exposure. Their acceptable proceeds must reflect their own labor, expenses, and commercial requirements.

Provider ceiling = 1 − (minimum acceptable provider proceeds ÷ service value). At a $250 service value, a provider who needs at least $200 can tolerate at most a 20% seller-side commission under these assumptions. Those proceeds are not their personal profit.

The feasible interval runs from the platform floor to the provider ceiling. A rate inside it is a candidate to test, not proof of demand. Customers must still accept the complete offer, and providers must actually take and fulfill jobs on the stated terms.

A worked example: when 20% is not enough

All numbers below are illustrative planning assumptions, not market rates, processor quotations, customer results, or forecasts. Imagine a marketplace matching small businesses with specialists for a tightly bounded remote review session. The service price is $250. A qualified specialist requires $200 in proceeds for the defined preparation, session, and closeout.

The founder estimates these platform costs for each completed job:

• Payment-related charges: $8.
• Matching and support: 24 minutes at an internal planning cost of $40 per hour, or $16.
• Recovery allowance: $4, to be replaced by observed refund, rework, and related support costs.
• Acquisition allocation: $15, including unsuccessful selling effort assigned to completed jobs.

Total modeled platform cost is $43. At a 20% commission, the platform keeps $50 and has $7 left after these costs. If the founder needs a $12 remainder per job, the floor is ($43 + $12) ÷ $250 = 22%. But the provider ceiling is 20%. There is no overlapping interval.

Charging 22% would leave the specialist $195, below the assumed acceptable proceeds. Selling more identical jobs does not repair that per-job mismatch. Lowering the target remainder may make a short experiment possible, but it does not remove the cost of running the operation.

Redesign the work, then recalculate

Suppose a narrower intake and clearer scope could reduce matching/support to 12 minutes, or $8, and a more focused acquisition channel could lower the allocation to $10. Keep payment costs at $8 and recovery at $4. The revised cost assumption is $30.

The floor becomes ($30 + $12) ÷ $250 = 16.8%. An 18% test commission would generate $45 in fees, leave the provider $205, and leave the platform $15 after the modeled costs. The interval now exists—but the claimed time and acquisition improvements still need to be observed.

The small-job row deliberately holds platform cost constant to expose the risk of fixed effort. Actual charges and labor may change with order size; replace the assumptions. A minimum service scope, a genuinely useful bundle, or a different delivery method may work better than a fee providers cannot absorb.

Copy this take-rate decision worksheet

Use one row per genuinely different service and scope. A blended marketplace average can hide an unworkable low-value job or a provider segment that cannot deliver at the assumed proceeds.

1. Offer: customer, problem, exact service, timing, evidence, and exclusions.
2. Money basis: service value, fee payer, included/excluded amounts, provider proceeds, and cancellation treatment.
3. Provider minimum: quoted acceptable proceeds and the request those proceeds cover; record qualifications and availability separately.
4. Platform costs: each cost, who bears it, source or assumption, and allocation method. Count acquisition and founder effort once.
5. Target: desired remaining contribution and which overhead still sits outside it.
6. Boundaries: floor, ceiling, proposed rate, and provider proceeds at that rate.
7. Adverse case: extra coordination, cancellation, rework, or failed matching; state who pays and how the interval changes.
8. Decision owner: approve test, rework, or stop; record the pricing version and next review trigger.

Test both sides before expanding bookings

A positive worksheet does not establish willingness to pay, repeat purchase, reliable supply, or a scalable acquisition channel. Reach one buyer segment through a bounded channel such as relevant referrals or focused outreach. Offer the actual scope and full price; record objections to price separately from objections to timing, trust, or deliverables.

Recruit a small qualified provider pool before accepting requests you cannot cover. Review competence, evidence standards, availability, and the complete terms. Contracting with a provider does not remove applicable licensing, insurance, privacy, or worker-classification responsibilities; establish the requirements for the service and location before transacting.

Use this illustrative experiment card; its thresholds are chosen decision rules, not industry benchmarks:

• Hypothesis: buyers will purchase the $250 bounded offer, providers will accept $205 proceeds, and the redesigned process can deliver at the modeled cost.
• Test: present the same offer to 12 qualified prospective buyers during a defined test period, using a pre-agreed provider pool. Do not change the fee halfway through without labeling a new test version.
• Signal: purchase commitments, provider acceptance, completed evidence, actual coordination minutes, acquisition effort, and subsequent adjustments—not just inquiries.
• Threshold: seek three paid, completed jobs, each accepted on the stated provider terms and leaving at least $12 after the defined actual-cost allocation. Investigate every decline and recovery. Model an additional $20 support event even if none occurs.
• Decision: continue a limited test if both sides and delivery economics pass. Rework scope, channel, or process if a named assumption fails. Stop this offer if qualified providers cannot accept a customer price that covers delivery.

Three jobs do not validate long-run recovery rates or acquisition costs. In the redesigned example, an additional $20 support event turns the $15 remainder into a $5 loss on that job. Decide whether a well-evidenced portfolio allowance can cover such events; do not erase the exception or assume every job will be clean.

Launch with capped demand and a human approval boundary. Scale only after repeated cohorts show stable provider acceptance, repeat customer use where relevant, bounded coordination time, and costs that survive plausible recoveries. If each match still requires founder intervention, the commission is funding a fragile service operation, not a self-running network.

Build This Business in Workhint

The operating requirement is to keep scope, fee terms, assignment, and exceptions connected. Workhint’s Workflow Engine describes requests, assignments, role-based approvals, and required details or files before work advances. These capabilities fit the review boundary between a proposed request and an authorized service commitment.

The Workhint solution for founders describes separate customer and worker journeys and request review, assignment, and approval. Use those building blocks to coordinate the service; they are not proof of automatic pricing optimization or your particular payment configuration.

Adapt this copy-ready configuration brief. Treat it as desired operating requirements and verify the resulting behavior with sample cases before accepting live work:

Build a service-marketplace workflow for small businesses requesting a fixed-scope remote review session from qualified specialists. Give customers, providers, an operations reviewer, and an administrator appropriate role-based access. Capture the requested outcome, sample inputs, service scope, timing, service value, fee basis, pricing version, proposed commission, provider proceeds, and approved cost worksheet. Onboard providers after human review of relevant competence, confidentiality, availability, and acceptable service terms. Match manually by competence and availability.

Use Request received, Scope reviewed, Terms approved, Provider accepted, Scheduled, Evidence submitted, Customer review, and Closed states. Require approved scope and terms before commitment, explicit provider acceptance before scheduling, and completion evidence before closeout. Route a below-minimum provider offer or outside-worksheet price to the commercial owner. Route missing inputs to the customer, provider declines to operations, and cancellations, rescheduling, or rework to named reviewers. Keep the original terms and record a separately approved change rather than silently replacing them.

Let customers provide inputs and review delivery, providers see assigned work and agreed proceeds, and administrators manage exceptions. For the initial test, keep payment execution in the separately agreed payment process; record its confirmation and reference manually. Do not assume an automatic split or payout setup. Record coordination time, provider acceptance, completion, acquisition allocation, adjustments, repeat use, and the manually reviewed per-job remainder. The outcome is an explainable service commitment and cost record, not an automatically optimized fee.

FAQ

What is a good take rate for a new marketplace?

There is no universal healthy percentage. A workable candidate covers the costs the platform bears, leaves acceptable provider proceeds, and supports an offer customers buy. Test the rate for a specific service rather than copying an unrelated platform.

Should the buyer, provider, or both pay the fee?

That changes the offer and the calculation. A buyer fee increases the customer’s total price; a provider fee reduces proceeds. Test the full customer price and provider terms together, with clear disclosures and the applicable commercial requirements. Moving the fee does not make its economic burden disappear.

Can a higher take rate solve negative unit economics?

Only if both sides still accept the resulting terms. If the platform floor exceeds the provider ceiling at the customer price, improve the value, narrow the scope, reduce real costs, or stop. An unaccepted rate is not a solution.

When should the rate be reviewed?

Review when scope, order size, acquisition cost, coordination effort, recovery experience, or provider terms materially change. Use a new pricing version and evaluate existing commitments rather than silently applying new terms to old work.

Verdict: conditional on an overlapping interval

A commission-funded service marketplace is Conditional: attractive only when customers buy a useful bounded outcome, qualified providers accept the net proceeds, and the platform retains enough after real delivery and acquisition costs. The model is weak when its margin depends on unpaid founder rescue or an untested promise of cheap future demand.

The broader on-demand service marketplace guide covers the surrounding model. For this decision, keep the task smaller: define the money basis, calculate both boundaries, test the interval, and allow “this service does not work at this price” to be a legitimate launch decision.