# GHL Funnel Landing Pages — Build Workflow (the "Missed Call Diagnostic" pattern)

How RRR builds funnel landing pages in GHL. Established with the "Missed Call Diagnostic" page (`/map`); confirmed and corrected 2026-08-09 during the "One Town. One Agency." page scoping.

## The durable fact that corrects a common wrong assumption

**GHL "AI Studio" and the GHL Funnel page builder are two different surfaces.** Do NOT tell Rob to paste Claude's HTML into "AI Studio's bot" and expect a funnel page — that conflates the two. The native funnel landing page is built in the **Funnel step's page builder** (Sites → Funnels → a step = a landing page → drag-and-drop section/row/element editor).

Correct build path for a funnel landing page:
1. Sites → Funnels → New Funnel (or add a step). The first step IS the landing page.
2. Build it in the GHL page builder — from a blank page or template, dragging in native elements (Section/Row/Column, Headline, Paragraph, Button, **Countdown**, **Form**, Image, Divider, Spacer).
3. The AI assist that helps here is the **in-builder page generation** (works from a text description), NOT AI Studio.

## The proven workflow (worked for Missed Call Diagnostic — reuse it)

**Claude designs a build spec → operator rebuilds it natively in the GHL page builder.** Claude does NOT produce a standalone HTML app for this path; it produces a *section-by-section blueprint + exact copy* that Rob (or the agent) rebuilds with native GHL elements. Rationale: native build = the form wires directly to GHL contacts/workflows, and Rob can edit copy without touching code.

## Two routes, and the trade-off that forces the choice

| Route | What Claude produces | Where it goes | Editable in GHL? | Form → GHL contacts? |
|---|---|---|---|---|
| **A. Native build (default)** | Section-by-section build spec + copy | Rebuilt in the funnel page builder with native elements | ✅ yes | ✅ native Form element |
| **B. Custom-Code embed** | Standalone HTML/CSS/JS file | Pasted into a GHL "Custom Code/HTML" element on a blank funnel page | ❌ not visually editable | ⚠️ must wire a GHL form separately |

**The forcing constraint:** anything needing custom JavaScript (a self-ticking 3-state countdown, auto page-freeze logic) CANNOT be done in the native builder from a text prompt — and a Custom-Code embed is not natively editable. So you can't have BOTH "fully editable native page" AND "custom JS behavior" on one page. Pick per requirement.

## Countdown timers specifically (the One Town. One Agency. case)

- GHL's native builder has a **Countdown element** — drag it in, set a FIXED end date. This is the reliable path. Do NOT spec a custom self-ticking JS clock for a native build; the builder won't wire it from a prompt.
- Multi-state urgency (UNCLAIMED live → EXPIRED → CLAIMED/frozen) is NOT auto-wirable in GHL. Make it a **manual operator action**: build a duplicate "CLAIMED" variant of the page and publish it by hand when the town signs. Write the swap copy into the spec.
- **Purchase-triggered clock stop (added 2026-08-09):** the native Countdown element counts to a fixed date ONLY — it has no "stop when someone buys" event, and a purchase workflow cannot halt a live native timer mid-page. To honor "clock shuts down when the client completes the purchase": the countdown lives ONLY on the UNCLAIMED sales page; the "Claim Now" button goes to a GHL order form (checkout on the $497 product); the order-form submission workflow redirects to the CLAIMED duplicate page which carries NO clock. The clock doesn't freeze — it disappears, replaced by the claimed state. Requires the $497 product to exist in Payments + a connected payment gateway (verify in UI first — the V3 OAuth token 401s on /products, not authorized for that scope, so Products can't be read via API).
- If the self-freezing page + self-ticking clock is a hard requirement, that's Route B (standalone HTML / Custom Code), accepting the editability loss.

## Rob's claim-discipline rule applies to the copy (drives the countdown design)

No fake evergreen timers, no invented stats. The countdown must be a REAL fixed deadline the operator sets and honors; the "page freezes when claimed" state is real, not theater. This is why the honest 3-state design (real deadline + manual CLAIMED flip) is the approved pattern over a generic "offer expires in 47:12:33!" evergreen clock.

## Cloning an existing funnel (the fast path — with two audits)

Cloning a proven funnel (e.g. Missed Call Diagnostic → "Premium Line — Bail Bonds", done 2026-08-10) is the fastest start, but audit TWO things immediately:
1. **Inherited steps:** the clone brings ALL source steps. A diagnostic funnel's "Book" (calendar) step is wrong for a purchase flow — replace it with the CLAIMED redirect page (sales page → order form → CLAIMED, no booking).
2. **Domain:** a fresh clone shows "Please add a domain in the settings to see your Funnel live!" until a domain is attached in funnel Settings. Attach before any QR goes to print — the page is unreachable without it.
3. **URL slug inheritance (caught live 2026-08-10):** the clone also keeps the SOURCE step's URL slug — the Premium Line clone stayed live at `go.realresultsready.com/missed-call-diagnostic-page-2758`. For a QR-printed offer page you want a clean, offer-named slug, which makes cloning the wrong start for a new offer: create a FRESH funnel → "Add new step" → name + clean path (e.g. `/premium-line-bail`) → blank page. Rob's call: "we shouldn't clone... it kept the url... literally start from scratch." Clone only when the slug doesn't matter (internal/test pages) or plan to rebuild the step path immediately.

## In-builder "Build with AI" behavior (observed live 2026-08-10)

The funnel page builder's **"Build with AI"** (wand icon / "Ask AI" Build tab) opens a 5-question intake (page name, niche, goal, audience, offer) then generates a FULL multi-page site skeleton ("main-nav, authority-hero, subscription-benefits +6 more" — nav bars, extra pages) rather than a single landing page. For a tightly-spec'd page (locked copy, exact tokens, order-form logic), this is overbuild + generic copy; the manual section-by-section path is faster than cleaning up the AI output. Rob likes to let it finish + SAVE it to see what it produces before starting fresh — don't push him to cancel mid-run; treat the AI output as a discardable reference artifact. If a future AI build impresses him, audit it against the blueprint's copy rules (banned jargon, invented stats, vocabulary) before keeping any section.

The intake's **"Goal" field drives the CTA type** — "Sell a subscription" → checkout elements; "Book appointments" → calendar. Answer it deliberately or the AI wires the wrong CTA.

**Preview-before-publish 404s:** the builder's preview URL (e.g. `realresultsready.com/preview/<id>`) returns 404 until the step is actually published. Don't debug the URL — for pre-publish review, have Rob screenshot the builder canvas + section list and read it with vision_analyze.

**Section-scoped Build WORKS (proven 2026-08-10) — the productive middle path between full-manual clicking and page-level AI overbuild:** click into ONE empty Section on the canvas so the Ask-AI input shows the "Section" context tag, then paste an exact per-section spec. Given the blueprint header spec it produced the correct 2-column row (logo text left ~70%, #2563EB CTA right-aligned, Inter 700 #111, mobile stack, white/#EFF6FB bg) on the FIRST try. Prompt formula that worked: name the element, give copy VERBATIM in quotes, hex colors, column fractions ("70% width"), alignment, and mobile behavior ("stack vertically"). Build loop: one AI prompt per blueprint section, review each before adding the next. The page-level and section-level AI are the same panel — scope is set entirely by whether a Section is selected when you invoke it.

**Section-AI pitfalls (all hit live 2026-08-10):**
- **Long multi-row prompts can stall the generator.** A single prompt asking for a 4-row numbered feature grid + styled callout box hung in a "Thought for 0s / defining structure" loop and never emitted. Keep each prompt to one visual block (≈1–2 rows); a 4-row "what it does" grid should be 2 prompts or built as stacked rows. If it stalls, don't re-paste the same long prompt — split it.
- **Verify the Countdown element's date after an AI build.** The AI reported "countdown set to Aug 14, 2026 11:59 PM MT" but the element rendered 0:0:0 — the date didn't actually persist. Always click the countdown, confirm the fixed end date + timezone with your own eyes, and only then trust it. Same class of check for any Order Form product wiring the AI claims to have done.
- **The AI cannot close element settings panels** (pure UI control) — when it says "close the panel," Rob clicks the panel X / collapse arrow or presses Esc before adding the next section. If he doesn't, the next prompt edits the PREVIOUS element instead of the new section.

**Section-AI DEGRADATION over a long build (burned 2026-08-10, the second half of that session):**
- **Output quality decays with accumulated context.** Sections 1–7 built clean from detailed prompts. Section 8 came out with broken vertical-text layout + mid-syllable word wrapping; THREE "fix the layout" prompts each made it different-but-still-wrong (Rob: "this AI is getting dumber the longer we use it"). Only a **"delete this section and rebuild from scratch"** prompt fixed it. Rule: after 2 failed correction prompts on one section, stop correcting — prompt a full delete+rebuild of that section (or build it manually).
- **The AI can WIPE the page on a bad generation.** A Section-9 checkout prompt "grinded to a halt and wiped out half the page" — sections 8+9 had to be recovered. Rule: **hit the builder's Save button after EVERY successful section**, and the moment a generation damages existing content, **stop using the AI for the rest of the build** — close the panel and finish manually. Do not "give it one more chance."
- **Order Forms are only partially AI-patchable (schema validation failure).** The AI can PLACE a native Order Form element but cannot set most of its config — attempting to returned "issues while applying the changes," and what it did apply was partial (button text changed, but the form still showed placeholder "Dynamic Item $99", shipping fields, and a coupon box). Rule: let the AI place the element, then configure it MANUALLY in the right-side settings panel: shipping OFF (the toggle exists — "Toggle Shipping / Hide Shipping"), coupon OFF, button text. Verify the product NAME + PRICE render in the form preview — placeholder text means it isn't wired.
- **The One-Step Order Form settings panel has NO product selector (burned 2026-08-10).** Full tree walked live (General tab: Contact Options → Form Options → Main Product Options → Order Bump → Coupon → Terms → Colors): toggles exist for shipping, coupon, terms, company name, phone, cart mode — but NOTHING attaches the product. "Main Product Options" holds only Cart Mode / Product Description / Pricing Information. RESOLVED (second session, 2026-08-10): the product attach lives at the funnel STEP level — save the page, back out to the funnel overview, click the step, step-level **Products** sub-tab (Overview / Products / Publishing) → "+ Add Product". The editor canvas keeps showing the stale "Dynamic Item $99" placeholder after attach; the truth check requires PUBLISHING the step (Publishing tab) and viewing the live URL — the preview URL 404s until published. Don't burn a loop hunting for a product dropdown inside the element settings; it isn't there. Check the STEP-level Products sub-tab, not page-level settings.
- **Build order should front-load the risky sections.** Because the AI degrades with session length, prompt the highest-configuration sections (order form, countdown) EARLY while it's fresh, not last. Simple sections (footer, math) can be built last — or manually in seconds.
- **Closing the AI panel is itself a UI action.** When switching AI→manual, Rob closes the Ask-AI panel first (X / collapse / Esc) or element clicks keep routing through the AI context.

**The funnel-build task is bigger than the page sections — track the wiring checklist explicitly.** The AI session built sections but silently skipped every cross-element wiring task because no prompt asked for them (Rob's audit: "header button NOT wired... never asked... never asked for claimed"). After the last section lands, run this checklist explicitly: (1) header/CTA buttons → anchor link to the checkout section; (2) order form → real product selected (name + price visible in preview); (3) custom fields added (Agency name, Town dropdown — GHL order forms don't auto-include them; native order forms CANNOT take custom fields at all — launch workaround: Toggle Company Name ON + mandatory + relabel to "Agency Name", collect Town post-checkout via automation; upgrade path = two-step flow, GHL native Form (supports custom fields) → order form pre-filled); (4) Confirmation/"You're In" page built as a second funnel step ("+ Add new step or import" in the step sidebar → clean path like `/confirmation` → create from blank — do NOT use the page-level AI, it overbuilds; 3 elements by hand: full-width Section → 1-col Row → Headline + Paragraph); (5) order-form success redirect → the native default "Button Actions → Go to Next step" handles it automatically once the Confirmation step exists (verify the setting, don't rebuild it); (6) countdown expire redirect → CLAIMED page (can only be set after the CLAIMED page exists and has a URL).

**Button → on-page anchor wiring (verified 2026-08-10):** GHL sections expose NO CSS ID field (section settings = General / Styles / Animations only; "Element name" is an internal label, not an anchor). The native route: button settings → Button Actions → "link to" dropdown → **"Scroll to Element"** → second dropdown lists named page elements → pick the checkout section (set its Element name to "checkout" first so it's findable). Two burn patterns: (a) the setting can look saved in the panel but the LIVE page does nothing — editor saves are not live; must Back out → Publishing tab → republish, then hard-refresh (Ctrl+Shift+R) the test tab; (b) verify by REOPENING the button's settings panel (did "Scroll to Element" stick or revert to "Website URL #") before debugging anything else.

**End-to-end checkout testing with Stripe (verified 2026-08-10):** GHL's Stripe integration (sub-account → Settings → Integrations → Stripe) can hold BOTH live and test keys simultaneously ("Stripe live mode is enabled" + "Stripe test mode is enabled" — both green checks is normal, not a conflict). Which keys get used is decided PER-FUNNEL: funnel → Settings tab → "Payments & checkout" → "Payment mode" toggle (badge shows Live/Test). There is no test toggle inside the page editor. Safe test flow: flip the funnel to Test → incognito → fill the form → card `4242 4242 4242 4242`, any future expiry/CVC/ZIP → verify order submits + lands on the Confirmation step → flip Live back ON before traffic. Also: trial checkouts show $0.00 everywhere by design (item line, order summary, total) — that IS the correct trial render, not a wiring bug. "Require credit card" toggle ON means card details are collected even at $0.