AI page builder

The page builder is where a conversion page is written. It opens from New draft or Start from scratch on Conversion pages, and it produces exactly one kind of thing: a draft that goes through the same review-and-publish contract however it started.

The workspace

Three columns, on screen together once the window is wide enough:

• Conversation — the AI rail. Describe the page you want, answer any clarifications, and ask for revisions. Revisions keep your manual edits.
• Editor — the draft itself, under one Save draft / Publish bar and grouped into four tabs: Form, Scoring, Page, and Handoff. Each tab shows how much is in it — Form · 6, Handoff · 2 — and an amber dot when something on that tab is the reason Publish would refuse. Only the tab you are on is on screen, so a control you are looking for is on another tab rather than further down the page.
• Preview — the page as a visitor sees it, repainting as you edit.

On a narrower window the three become one view at a time behind a Conversation / Editor / Preview switch. In the wide layout you can drag the rails wider or collapse them, and the widths survive a reload.

Four ways to start

• Describe it — type a brief and let the agent propose the fields, copy, and sections. A specific brief produces a specific page: "same-day AC repair request for homeowners in Austin, urgent tone, ask about property type" beats "service page."
• Start from a template — Contact us or Help desk ticket on the start screen. Each says up front where its submissions land.
• Start from scratch — an empty draft, when you already know what to ask. The AI can still take it over later; the page works the same either way.
• Import specification — from the conversion pages list. Paste validated JSON and get those exact fields, IDs, options, and permission wording, with no AI involved. Download schema gives you the shape to author against; the server is the validator of record.

Working the draft

Everything the agent proposes is editable, and nothing about the AI path is special at publish time. See Conversion pages for what each section does, and the worked examples for two pages built end to end.

• Save draft validates as you go and reports what needs fixing.
• Publish computes a diff first. Changes that need a human decision — a renamed or removed field, changed option values, changed permission wording — are listed for approval before the public URL changes.
• A draft cannot be published without a submission binding: something has to happen in the CRM, even if that something is "record the submission only."

Which tab holds what

Tab	What its count counts	Sections it holds
Form	Questions asked	Form fields
Scoring	Rules and deal-breakers	Qualification scoring
Page	Public page sections	Page sections, Contact and privacy footer, After submitting
Handoff	Destinations a submission reaches	Submission binding, Submission routing, and — on a live page bound to an instrument — Snapshot email

The counts are nouns, not a general busyness score, and two of them are worth reading closely:

• Scoring counts zero while the scorer is switched off. Three rules you have written but not enabled are not three rules that run, so the badge never contradicts the switch beneath it.
• Handoff counts destinations, not settings. A binding that creates a lead, contact, opportunity or review request is one. A pinned instrument is another, because the submission is handed to a scoring run whether or not a CRM record is created. Inbound inquiries, service tickets, and submission alerts are one each. Record the submission only is not a destination on its own — a page in that mode with no routing switches on reads Handoff · 0, which is accurate: the submission is captured and goes nowhere else.
• Page counts page sections only. The footer and the endings live on that tab but are one setting each, so counting them in would make "4 sections" mean something other than four sections on the public page.

When Publish refuses

The dot answers which part of the draft, which used to mean scrolling the whole editor to find out.

Two things raise it, and they appear at different moments:

• Rules the builder can check as you type. Switch Submission alerts on with nobody on the recipient list and the dot appears on Handoff immediately — before you press Publish at all.
• Errors the server returns from a publish attempt. Press Publish with an empty Form fields list and the attempt comes back refused; the dot appears on Form and the editor opens that tab for you.

A draft with problems on two tabs opens on the earlier one in tab order, so you work them front to back rather than in whatever order the errors arrived.

One case behaves deliberately differently: an error about something this screen does not render — a slug that collides with an existing page, for example — marks no tab and moves you nowhere. The banner above the editor still states it. A dot that appeared on an arbitrary tab would send you hunting through a tab with nothing wrong on it, so the dot abstains instead.

On a phone the four tabs do not fit at once. Selecting one scrolls it into view, including when a failed publish jumps you to Handoff.

Tips

• Read the clarifications carefully — they are the agent telling you what is ambiguous. A good answer there saves a regeneration round.
• If a reviewed instrument already exists, import it rather than describing it. Import preserves every question and the exact permission wording; a prompt paraphrases.
• Don't leave drafts abandoned in the builder. They never reach the conversion pages list until published.

Related

• Conversion pages
• Conversion pages worked examples
• Agent library overview