Find out whether buyers can actually book your providers. Use a fixed request cohort, a failure-cost worksheet, and explicit repair-or-expand rules before buying more demand.
A service marketplace can have enthusiastic providers and a growing inquiry list while failing its basic promise: getting a buyer an acceptable service at the agreed time. More signups do not tell a founder which part is broken.
Quick answer: Marketplace liquidity describes how readily participants find a useful transaction. For an early service network, measure the share of eligible requests matched within the promised window, the share fulfilled by the service deadline, and how much confirmed provider capacity gets used. Keep unsuccessful requests in view and calculate what handling them costs.
Verdict: conditional. Expansion is worth testing only when a narrow segment matches reliably, completes work acceptably, and leaves enough contribution after unsuccessful requests and operating effort. A good-looking match rate is not proof of profitability or product-market fit.
Define the promise before choosing a liquidity metric
Sharetribe’s liquidity explanation distinguishes value on both sides: buyers finding what they need and sellers finding transactions. For services, supply can be available hours rather than a count of listings. That distinction matters when ten listed specialists collectively offer only two suitable appointments.
Start with a specific buyer, bounded service, qualified provider type, and purchase constraint. In the illustrative model used here, a small business requests a remote presentation rehearsal with an independent facilitator. The buyer needs an accepted booking within one business day and a completed session within five business days. These are proposed test terms, not evidence of demand or normal market expectations.
Write down who buys, who delivers, what the fee covers, and what makes a request eligible. A rehearsal might include one session and a short feedback note, but exclude slide production or investor introductions. Recruit facilitators who can demonstrate the relevant skills and explicitly accept the scope, compensation, response window, and available times. Profiles alone are not committed supply.
The broader on-demand service marketplace operating model explains the components of a network. This scorecard answers a narrower question: where do real requests fail, and does the evidence justify expanding this segment?
Give every request a stable denominator
Record a unique request ID when the buyer first submits. Keep the original timestamp even if details need correction. Also record when the request becomes qualified and the applicable match and service deadlines. Otherwise, a team can appear faster simply by delaying when it starts the clock.
| Record | Working definition | Control against misleading results |
|---|---|---|
| Received | One buyer need enters intake. | Merge true duplicate submissions; retain a link to the original. |
| Qualified | The request meets the prewritten buyer, scope, timing and commercial rules. | Keep ineligible requests in a separate demand log with reasons. |
| Match accepted | Buyer and eligible provider accept the same scope, terms and appointment. | An outreach message or suggested name is not an accepted match. |
| Fulfilled | Work is delivered by the deadline with the agreed acceptance evidence. | Track late or disputed delivery separately rather than counting it as on-time success. |
| Terminal exception | Unmatched expiry, cancellation, provider withdrawal or unresolved delivery failure. | Preserve the event history and the responsible reviewer. |
| Not yet observable | The relevant match or service deadline has not passed. | Do not treat a pending outcome as success or failure. |
Freeze the eligibility rules before the experiment. Keep qualified requests that later cancel, fail to find supply, or lose their provider in the relevant denominator. If a buyer withdraws before matching, record that reason rather than deleting the request. Requests outside the offer can be excluded from the qualified cohort, but their volume may show that the offer is attracting the wrong audience.
Copy the six-line launch scorecard
Use one defined cohort and state its observation cutoff. A request must have had its full one-business-day window before appearing in the on-time matching denominator. Fulfillment uses requests whose service deadlines have passed. Those populations can differ in a live weekly report; label both counts instead of dividing unrelated totals.
Yonder’s marketplace metrics guide separates an accepted match from fulfilled demand and emphasizes complete observation windows. The definitions below adapt that distinction to a small service-network launch; metric names are not interchangeable across businesses.
| Measure | Calculation or record | Decision it supports |
|---|---|---|
| On-time match rate | Requests with an accepted match inside the promise ÷ qualified requests with a full matching window. | Can available supply meet the buying promise? |
| On-time demand fulfillment | Qualified requests fulfilled by deadline ÷ qualified requests whose service deadlines have passed. | Does demand become delivered value, not just bookings? |
| Post-match completion | Accepted bookings fulfilled on time ÷ accepted bookings whose service deadlines have passed. | Is the break before or after agreement? |
| Matching time and unmatched share | Time from qualification to acceptance for matched requests; show unmatched requests separately. | Are fast successes hiding buyers who never find anyone? |
| Supply utilization | Fulfilled service hours ÷ confirmed hours offered for the same period and segment. | Are providers getting useful work from their committed capacity? |
| All-request contribution | Retained fees minus attributable costs of successful and unsuccessful requests; show per qualified request too. | Can this matching model fund the effort it requires? |
For time to match, report the median and the slow end when the sample supports it. With a tiny cohort, show individual waits rather than an impressive percentile. Never describe the median among successful matches as the typical wait for all buyers.
Slice results by constraints that change whether providers can fulfill: service type, required skill, time window, geography where relevant, and price band. A global provider directory is not one pool of interchangeable availability. Keep sample counts visible; one additional failure changes a ten-request segment by ten percentage points.
A worked cohort: healthy bookings, weak delivery
Constructed example, not customer results: Twenty qualified rehearsal requests have passed both deadlines. Sixteen find an accepted match within one business day. Fourteen finish on time; two accepted bookings are cancelled. The remaining four requests never match. Each completed session uses one hour. Providers had confirmed thirty available session-hours for this cohort’s delivery period.
- On-time match rate: 16 ÷ 20 = 80%.
- On-time demand fulfillment: 14 ÷ 20 = 70%.
- Post-match completion: 14 ÷ 16 = 87.5%.
- Unmatched share: 4 ÷ 20 = 20%; the two later cancellations are a separate failure stage.
- Supply utilization: 14 ÷ 30 = 46.7%.
The same network has unserved buyers and unused provider time. That is a reason to inspect fit—not automatically recruit more providers or buy more leads. Perhaps open hours are mornings while buyers need evenings. Perhaps the right specialists decline the offered compensation. Read the request and provider records before choosing a remedy.
Charge unsuccessful demand to the model
Suppose the illustrative business earns a $50 retained fee on each of the fourteen completed sessions. Assume no retained fee on failed requests, matching and support cost $12 for every qualified request, processing and other completion-variable costs are $4 per completed session, and cancellation recovery costs the platform $30 for each of the two cancellations. These are invented planning inputs, not market prices or processor quotes.
The cohort leaves (14 × $50) − (20 × $12) − (14 × $4) − (2 × $30) = $344. That is $17.20 per qualified request before acquisition, onboarding, software and fixed overhead not already counted. It is not net profit. If acquiring the cohort costs another $400, the remainder becomes −$56 before those other expenses.
A completed-job calculation that includes only fourteen support charges misses $72 spent on the six unsuccessful requests. Count founder coordination at a deliberate labor cost even when cash wages are zero. Use actual costs and avoid counting provider compensation twice: this example starts with the platform’s retained fee, not the full service value. Use the marketplace take-rate worksheet if the underlying fee itself needs redesign.
Turn each failure into a bounded experiment
A missing match does not reveal its own cause. Record the buyer constraint, providers considered, response and decline reasons, offered terms, and the final outcome. Let an operator distinguish facts from hypotheses: “three providers declined this time” is observed; “providers dislike our model” needs more evidence.
- No eligible provider: narrow the promise or recruit the missing qualification before resuming demand acquisition.
- Eligible but unavailable: test buyer-compatible windows and explicit capacity commitments.
- Provider declines terms: revisit scope, compensation or response burden; do not count invitations as capacity.
- Buyer rejects a suitable proposal: investigate price, trust and offer fit before blaming supply volume.
- Accepted then cancelled: inspect confirmation, reminders, preparation and backup ownership.
- Completed but disputed: improve acceptance criteria and evidence; a fast match cannot repair poor fulfillment.
For the example, use this experiment card:
- Hypothesis: buyer-compatible provider hours, rather than total provider count, are limiting outcomes.
- Test: run the next twenty qualified requests in the same service segment, price version and acquisition channel after confirming coverage for the requested windows.
- Signal: on-time match and fulfillment counts, decline reasons, all-request costs, and rescue minutes.
- Threshold: before testing, choose a service-quality floor and cost ceiling the business can afford. An illustrative internal gate might be at least eighteen on-time matches, at least seventeen on-time completions, and a positive remainder after measured acquisition and handling costs. These numbers are not industry benchmarks or statistical proof.
- Decision: continue narrowly if all gates pass; rework if a specific constraint remains; stop buying demand if the offer cannot support qualified supply or affordable recovery.
Limit test spend and customer commitments. Do not advertise guaranteed availability before coverage exists. Verify applicable business, worker, privacy, insurance and service-specific obligations for the actual model; using independent providers does not remove them.
Build This Business in Workhint
The operational need is a trustworthy record of each request and its exceptions. Workhint’s Workflow Engine describes configurable request steps, role-based approvals, assignments and required details, files or notes. Its Founders solution describes role-specific customer, provider and administrator experiences and marketplace request review.
Those capabilities can support the operational records behind this test. They do not establish a built-in liquidity calculator, automatic supply optimization, or a successful launch. Keep the scorecard calculations and expansion decision human-reviewed until the actual implementation is validated.
Copy-ready configuration brief:
Build a request-to-completion system for a remote presentation-rehearsal marketplace. Customers submit session goals, scope, preferred windows, deadline, agreed price and required facilitator skills. Providers onboard with reviewed skills, service boundaries, confirmed availability and accepted commercial terms. Give customers access to their own requests, providers access to assigned work, and administrators responsibility for qualification, matching and exception review.
Use Received, Details missing, Qualified, Provider review, Proposal sent, Match accepted, Session delivered, Evidence review and Closed states. Also preserve Unmatched expired, Buyer cancelled, Provider withdrew, Reschedule requested and Disputed outcomes. Require operator approval of eligibility, buyer and provider acceptance before confirming a match, and the agreed session evidence before closing. Route missing details, missed windows and delivery disputes to a named operations reviewer.
Record original intake, qualification, acceptance, service deadline and completion timestamps; preserve the original cohort and eligibility version. Keep cancellation and decline reasons, confirmed capacity and human-reviewed handling costs with the relevant records. Administrators reconcile the launch scorecard externally if needed and approve any expansion. Use only the business’s separately verified invoicing and payment process; do not infer banking, escrow or automatic refunds. The goal is auditable requests and exceptions, not an automatically profitable marketplace.
Expand only the segment that has earned it
Review the same definitions across successive mature cohorts, including normal-price transactions and repeat buying opportunities. Keep the request counts and unresolved outcomes visible. A pilot can justify another capped test; it cannot establish seasonality, long-run retention or a whole new geography.
When the gates pass repeatedly, change one material constraint at a time and give the new segment its own scorecard. When they fail, repair the observed bottleneck. When acceptable provider terms, customer willingness and affordable operations cannot coexist, stop or redesign the offer. Software can organize those decisions; it cannot manufacture a workable market.
FAQ
What is a good marketplace liquidity rate?
There is no single useful target for every service. Define the buyer’s timing promise, provider capacity unit and economic limits first. Report a numerator, denominator and observation window with any percentage rather than borrowing a benchmark from another model.
Should cancelled requests stay in the scorecard?
Qualified requests should not disappear after cancellation. A request matched on time still counts as matched, while a cancelled booking fails the on-time completion measure. Record cancellation timing and responsibility separately so the failure stage remains clear.
Can high supply utilization and poor buyer outcomes happen together?
Yes. The most suitable providers may be fully booked while other profiles are irrelevant or unavailable for the requested window. Measure relevant capacity and unserved buyer constraints together instead of treating every listed provider as equivalent.
Does high liquidity prove product-market fit?
No. It is one operating signal. Founders still need evidence of accepted pricing, repeat use where relevant, reliable fulfillment, manageable acquisition and support costs, and a model that does not depend on rescuing every transaction.

Leave a Reply