SoulGait / calculators
Practitioner marketplace revenue calculator
Estimate completed bookings, gross booking value and platform share for a practitioner marketplace with transparent assumptions.
The working tool
Build a scenario.
A marketplace processes value for both sides, but its own revenue is usually only a portion of the transaction. This model separates completed booking value from the platform’s share so that a promising transaction volume is not mistaken for company revenue.
Know the inputs
What the calculator measures.
Gross booking value is the customer spend processed through the marketplace. The platform’s modeled share is gross booking value multiplied by its take rate. Provider gross share is the remainder before any provider-side costs or taxes. This does not model subscriptions, listing fees or advertising income.
Read the inputs before changing them.
Start with a measured value where one exists. Where it does not, run a low, expected and high scenario rather than treating one guess as a forecast.
| Input | Meaning and practical check |
|---|---|
| Active practitioners | Providers who are available and complete at least some bookings in the period. Do not include dormant listings. |
| Bookings per practitioner / month | Completed paid bookings per active practitioner after cancellations and no-shows. |
| Average booking value | Amount the customer pays for a completed booking, before refunds and payment costs. |
| Platform take rate (%) | Share of booking value retained by the platform before payment processing, support and other expenses. |
Transparent method
Formula and worked examples.
The calculation is transparent and uses only the fields above. It does not import market benchmarks, current prices or external account data.
A worked example
If 50 active practitioners complete 12 paid bookings each at $75, the marketplace processes 600 bookings and $45,000 in gross booking value. A 20% take rate produces $9,000 in modeled platform revenue. The remaining $36,000 is the providers’ gross share before their own expenses.
Compare three versions of the same decision
These figures are examples with illustrative inputs, not expected results for your business. Change the form above to use your own numbers.
| Scenario | Assumptions | Modeled output |
|---|---|---|
| Low activity | 50 practitioners · 6 bookings each · $75 · 20% take | $22,500 bookings · $4,500 platform |
| Illustrative case | 50 practitioners · 12 bookings each · $75 · 20% take | $45,000 bookings · $9,000 platform |
| Higher activity | 50 practitioners · 18 bookings each · $75 · 20% take | $67,500 bookings · $13,500 platform |
Put it to work
How to use the estimate.
A calculator helps when its assumptions lead to a specific next action. Use this three-step check before committing budget or building a product.
Validate liquidity
Measure whether a client can find an available practitioner who fits the need, at the relevant time and price.
Measure completion
Track requested, accepted, paid, completed and refunded bookings separately; use completed paid transactions here.
Model net contribution
Subtract processor fees, refunds, support, acquisition and provider incentives from the platform share.
Where the number can mislead
Uniform provider activity and one take rate simplify a real marketplace. In practice, some practitioners get most bookings; different categories may have different rates; discounts and refunds change collected value. Measure repeat bookings and the cost of balancing supply and demand by segment.
Straight answers
Frequently asked questions.
Is gross booking value revenue for the platform?
Usually not. The marketplace may collect the entire payment but recognizes or retains only its contracted share under its business and accounting model.
What counts as an active practitioner?
A provider available to accept relevant demand and completing transactions in the time period. A profile that never takes a booking is not active supply.
Should cancellations be included?
Use completed paid bookings for the core model. Track cancellations separately to understand lost demand and operational cost.
Can I add subscriptions or promoted profiles?
Those are separate revenue lines with their own conversion and churn assumptions. Avoid folding them into the transaction take rate.
How can I test the idea before building the platform?
Manually recruit a small provider cohort, match real buyers and process a controlled set of transactions to observe trust, scheduling and payment problems.