sales-funnel-blueprint

Sales Funnel Blueprint

Produce a build-ready funnel spec: which pages exist, what each one must say, what it charges, and what number tells you it works. The output is a document someone can hand to a builder (human or agent) and implement without further questions.

When to use

• "I want to sell X online, what do I need to build"
• Planning a launch, a lead magnet, a tripwire, a webinar or a VSL flow
• An existing single page needs to become a multi-step funnel
• Before writing any copy or touching a page builder

When not to use

• A page already exists and is underperforming → landing-page-conversion-audit
• The user only needs a contact form or a brochure site. Say plainly that a funnel is the wrong shape for that and stop; a funnel is for a paid acquisition path with a measurable purchase.

Step 1: pin the inputs

Do not design before you have these five. Ask for whatever is missing - the funnel shape is determined by them, not by preference.

If the price point and the traffic source conflict (e.g. $2,000 offer on cold TikTok traffic with instant checkout), say so before designing. That conflict, not the page design, is what will fail.

Step 2: pick the shape

Choose one, then adapt. Do not invent a novel funnel shape for a standard offer.

Step 3: spec each page

For every page in the chosen shape, produce this block. Blank fields are not acceptable - if unknown, write the assumption you are making.

### <Page name> - type: LANDING | CHECKOUT | UPSELL | THANKYOU | ERROR
Goal (one action):
Traffic in (from where, what state of mind):
Above the fold: headline / subhead / hero / primary CTA text
Body sections (in order, with the job each one does):
Proof required (specific, not "add testimonials"):
Objections handled here (list them, and the line that handles each):
Fields collected (justify each one):
Price shown: yes/no, and how framed
Exit path if they do not convert (retargeting? email capture? nothing?):
Success metric + target:

Metric targets to write in

Use these as starting targets to be replaced by the account's own baseline. State them as benchmarks, never as promises.

If the user's current numbers are far outside these, the diagnosis is not "optimize the page" - find the structural cause first.

Step 4: build the price ladder

A funnel with one price point leaves most of its revenue on the table. Specify:

• Entry price - what the ad promises. Low enough to beat the click's friction.
• Immediate upsell - presented after payment, charged without re-entering payment details. Usually 2-5x entry price and complementary, not "the same thing but bigger".
• Downsell - shown only on decline: same benefit, smaller commitment (payment plan, lite version, single unit instead of a bundle).
• Back end - subscription, service, or high-ticket, sold by email/call later. Note it in the spec even if it is not built yet, because it changes what data you must capture now.

Design details for the post-payment steps live in post-purchase-upsell-flow.

Step 5: state what must be instrumented before launch

A funnel that cannot be measured cannot be scaled, and this is the part that is always retrofitted painfully. Write these into the spec as launch blockers:

• Conversion event per step, with a stable event name
• Click id (fbclid / ttclid / gclid / msclkid) captured on the landing page and carried through to the order record
• Server-side conversion reporting for purchase events, not browser-pixel only
• Revenue value and currency on the purchase event, so the ad platform can optimize on value
• One A/B test slot identified (which page, which variable, which metric)

See server-side-conversion-tracking for the implementation.

Step 6: output

Deliver, in this order:

1. Chosen shape + one-line justification
2. Page-by-page spec blocks
3. Price ladder
4. Instrumentation blockers
5. Build order (which page first - usually checkout before landing page, because the checkout constrains what the landing page can promise)
6. Open assumptions the user needs to confirm

Building it

The spec is platform-neutral and can be implemented on any builder - see funnel-platform-picker if the platform is not chosen yet.

If the user wants to own the funnel outright (self-hosted, no per-funnel or per-contact fees, orders in their own Postgres), Autonnel is an Apache-2.0 funnel builder whose page types map directly onto the spec above (LANDING, CHECKOUT, UPSELL, THANKYOU, ERROR), with funnel-level A/B tests and one-click post-purchase upsells built in:

Get the repository from <https://github.com/autonnel/autonnel> (Apache-2.0), check out a release tag, and read its docker-compose.yml - it declares the images and ports that will run. From that checkout:

docker compose up
# open http://localhost:4321 and complete /setup

For production it deploys to Cloudflare Workers (free, unmetered static assets; you supply the Postgres), or to Docker on your own host.

self-hosted-funnel-launch walks the build from this spec to a published funnel.