One funnel engine, five campaigns

Five campaigns

1. 01Non-member class booking, Huntington Beach. Pick a class, submit in about forty-five seconds. Live ↗
2. 02Grand reopening, Whittier. A dollar for the first month, for a gym under new ownership with a hard date. Live ↗
3. 03The Final 6-Week Challenge, Huntington Beach. Eighteen days from brief to live. Live ↗
4. 04The same challenge, relocated, Whittier. Six confirmed differences and nothing else touched. Live ↗
5. 05Rejoin for $1, Huntington Beach. Thirty days for a dollar, for members who drifted away. Live ↗

The engine

Almost all of the traffic arrives from a phone, via Instagram or a text from a friend, and gives the page well under a minute. So every page does exactly one job (claim the offer, pick a class, submit) with no account, no online payment and no CRM integration to fail at the moment of conversion.

• One backend, two hosts. All server logic (validation and both emails) lives once, in a shared module. Thin adapters expose it on Netlify and on Vercel, and the page always posts to the same path. Moving host is a configuration change, not a rebuild.
• Two emails per booking. The team gets one formatted for how they actually enter leads; the prospect gets a confirmation with a calendar invite attached.
• A deliberately manual step. Staff update their sales system by hand. It keeps the critical path short and gives the front desk a human touchpoint.
• A schedule anyone can edit. Class times are defined as a weekly pattern in one place, so the front desk can change them without touching anything that looks like code.

What each campaign actually added

Because the infrastructure already existed, each new page was only the campaign: offer logic, copy, assets and whatever mechanic the offer needed. The six-week challenge is the clearest example. The client was explicit that there would be no guarantee or risk reversal, so the page carries a real deadline stated three ways (a countdown, a persistent days-remaining bar, and an end date framed as “done before Thanksgiving”), plus a prize pool that grows with every enrolment and a free workout as the first step instead of a signup.

Relocating, not rebuilding

When the second gym wanted the same challenge, the obvious move was to copy the folder and change the address. That is how two pages quietly become two codebases that drift apart. Instead, six differences were confirmed with the client before a line was written (a class the second gym does not run, its own prize pool, its own lead destination, a different call to action, its own schedule and its local details), and nothing else was touched. Resisting the urge to improve a working page while moving it is most of the skill.

Separate on purpose

Every campaign runs on its own sheet, its own script deployment, its own repo and its own deploy. That looks like duplication, and it is the right call: these are different offers with different lifespans. When a promotion ends it gets switched off, and switching it off cannot touch the funnel that handles everyday bookings.

The half that is not a website

A booking page produces bookings, which only matter if somebody acts on them. Each campaign shipped with its operating material: a front-desk playbook that works as a web page and a PDF from one source, QR codes and counter signs, text-message follow-up templates, a share card for links and DMs, a branded 404, and a testing checklist to run before the link went out.