How this works

An education business combined practitioner benchmarks, its own funnel data, and AI-assisted brainstorming to explore pricing and offer changes before testing them. A simple funnel model makes a commercial hypothesis explicit before customers or budgets are exposed to it. Its value is in revealing assumptions and measurement gaps, not in making simulated improvements appear inevitable.

Reconcile a baseline from observed cohorts, then vary a small number of assumptions in a transparent spreadsheet or script. Keep revenue, refunds, variable costs, acquisition spend, and contribution separate. Use benchmarks as contextual ranges only after checking comparability.

Before you start

Prepare the inputs

funnel_counts

Required

Cohort table

Record stage definitions, unique-user counts, period, and missing events.

payments_costs

Required

Ledger or export

Separate gross receipts, refunds, variable delivery costs, and acquisition costs.

benchmarks

Required

Evidence notes

Include business model, market, period, source, and comparability limitations.

hypotheses

Required

Human-authored list

State the proposed offer or journey change and expected mechanism.

optional_constraints

Optional / conditional

Rules

Include capacity, pricing restrictions, customer commitments, and authorized test bounds.

Implementation, step by step

1. 01

   Reconstruct the baseline

   • Map journey stages and join compatible cohorts without mixing acquisition and payment periods.
   • Check duplicate transactions, delayed payments, refunds, and missing cost categories.

   Checkpoint: The model reconciles to observed totals or shows an explicit unresolved difference.

2. 02

   Calculate unit economics

   • Use deterministic formulas for conversion, net receipts, cost per acquired customer, and contribution.
   • Document whether each denominator is a lead, buyer, paid order, or retained customer.

   Checkpoint: Each displayed metric has a reproducible formula and unit.

3. 03

   Assess benchmark relevance

   • Compare only benchmarks with compatible offers, stages, and maturity.
   • Use broad ranges when context differs and label unavailable evidence.

   Checkpoint: External figures do not silently replace observed company data.

4. 04

   Expand hypotheses

   • Ask the assistant to identify mechanisms, dependencies, and likely tradeoffs in the human proposals.
   • Separate changing price, conversion, retention, and fulfillment cost rather than assuming they all improve.

   Checkpoint: Each experiment changes a defined part of the model.

5. 05

   Simulate scenarios

   • Build downside, base, and upside assumptions with visible inputs.
   • Compute sensitivity to the uncertain variables and identify break-even conditions.

   Checkpoint: The reader can distinguish observations from assumed future values.

6. 06

   Design the real test

   • Select a bounded hypothesis and define instrumentation, customer-facing terms, success, and stop rules.
   • After an authorized test, reconcile actual results to the predicted cohort and document model errors.

   Checkpoint: The next decision depends on measured outcomes rather than the simulation alone.

Decisions along the way

What you will produce

Check the result

• Counts and payment amounts use compatible cohorts.
• Refunds and delivery costs are not hidden in a revenue-only success claim.
• Assumed rates are visibly distinguished from measured ones.
• Calculations can be reproduced without relying on the assistant's arithmetic.

When something goes wrong

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Run a small pilot

Keep the scope clear

• A simulation is planning support, not financial advice or a guaranteed outcome.
• Do not alter prices, charge customers, or spend advertising funds without authorization.