How Should You Price a Funnel-Building Project?

Start with scope, not a market-range guess

There is no responsible universal price for “a funnel.” A project might mean message research and a sales page, or it might include offer strategy, a VSL, email sequence, page design, implementation, integrations, analytics, QA, launch support, and several rounds of revision. The same label can conceal radically different work. Before discussing a number, list the decisions and artifacts the operator will own.

Scope also includes uncertainty. An operator working from a clear offer, approved claims, existing brand assets, and reliable access is solving a different problem from one asked to discover the offer while building the system. Price should reflect the work and risk that are real in this project—not an invented “going rate,” a competitor’s headline number, or a promise that the funnel will produce a particular result.

• Name the audience, offer, sales path, and first release.
• Separate strategy, copy, design, implementation, integrations, QA, and optimization.
• List inputs the creator must provide and decisions that require creator approval.
• Define acceptance criteria, revision limits, dependencies, and exclusions.

Use a flat fee when the first release is knowable

A flat fee fits a bounded project with a clear beginning and end. The agreement might cover a VSL outline and script, one landing page, a welcome sequence, and implementation in an identified platform. Payment can be split into sensible points, but the total obligation remains legible. This gives the creator a defined budget and gives the operator protection against an open-ended build.

The flat fee is only as clear as the definition of done. State what counts as a revision, who supplies missing assets, how approvals work, and what happens when the creator requests a new page or changes the offer. If the project is likely to change materially during discovery, a short paid diagnostic or first milestone may be more honest than pretending the entire build is already known.

Use milestones when risk is discovered in stages

Milestone pricing divides a project into accepted stages such as diagnosis, message architecture, copy, build, and launch QA. This structure is useful when each stage produces a reviewable artifact or decision. The creator can pause after learning something important, while the operator is not expected to finance every uncertain stage before the brief is understood.

Milestones need more than a payment schedule. Describe the output, review window, approval owner, and transition condition for each stage. A milestone should not quietly become a retainer or an unlimited revision bucket. If new evidence changes the plan, document the change and agree whether the next milestone is revised, deferred, or replaced.

• Discovery ends with a written diagnosis and recommended first release.
• Copy ends with the agreed scripts, pages, or emails in a reviewable format.
• Build ends with a functioning path tested against the acceptance checklist.
• Launch support ends with documented observations and the next decision.

Use a retainer for an ongoing operating job

A retainer is appropriate when the operator will provide recurring capacity rather than one fixed build: weekly funnel maintenance, email production, experiment planning, analytics review, or coordination with other specialists. Define the capacity, response expectations, meeting cadence, deliverables, and rollover policy. “Available for anything funnel-related” is not a scope.

Retainers require a decision about unused time and priority. Does unused capacity expire, roll over, or convert into a defined artifact? Who decides which request comes first when the creator has more work than the operator can handle? A written queue and a regular review keep a retainer from becoming a vague subscription to hope.

Use hybrid or revenue share only when the downside is discussable

A hybrid arrangement combines a base fee with a performance-linked component. It can be useful when the operator contributes beyond a one-time build and both parties want some upside alignment, while the base still recognizes real delivery work. The hybrid should identify the exact offer, channel, attribution rule, reporting source, payment timing, term, cap or review point, and exit process.

Pure revenue share transfers substantial risk to the operator. That risk is difficult to evaluate when demand is unproven, the creator controls traffic and offer decisions, checkout data is inaccessible, refunds are unknown, or several contributors influence the sale. Do not use a percentage to avoid an uncomfortable scope conversation. If the operator cannot inspect the relevant evidence or control the work tied to attribution, a fixed or milestone structure may be fairer.

• Define whether the share uses gross receipts, an agreed net basis, or another auditable formula.
• Name exclusions such as refunds, taxes, discounts, and processing costs.
• Set a measurement window, reporting access, payment date, and dispute process.
• State what happens when the offer pauses, changes, or moves to another channel.

Put the choice in the Statement of Work

The final pricing decision belongs in a Statement of Work that connects compensation to contribution. It should name the parties’ responsibilities, access boundaries, ownership, approvals, acceptance, change control, and the payment structure. A creator should be able to explain what they are buying; an operator should be able to explain what they are accountable for and what remains outside their control.

Review the arrangement after the first release rather than making every future task part of the opening promise. A project can move from milestone work to a retainer after the system is understood, or from a hybrid to a fixed optimization sprint if attribution proves too ambiguous. Re-pricing based on new information is healthier than preserving a structure that neither side can administer honestly.