Conversion pages

The conversion pages area is where you manage every page Vertiqa publishes — drafts, live pages, the submissions they capture, the CRM records those submissions create, and the consent proof behind them.

The rule the whole area is built around: what you reviewed is what visitors see, and every response is kept as evidence — even when routing to the CRM fails, even when the form has changed since.

Layout

• List view — one row per page: name and public address, where its submissions are routed, a 14-day submission trend, submissions and conversion rate, and status. Four tiles summarise the set — Total pages, Live now, Submissions · 30d (against the previous 30 days), and Median conversion across live pages that have been viewed. Filter by Active, Live, Drafts, or Archived, or search by name or slug.
• Detail view — the page name, a Live / Draft / Archived badge, and its lifecycle actions across the top (QR, Copy link, View Live, Edit in builder, Publish, Archive); a strip of four tiles — Views, Submissions, Conversion, and Status; then three tabs:
  • Overview — a preview frame on the left with a Desktop / Mobile switch, and a settings rail on the right: Design, Page content, Submission routing, and Embed on your website.
  • Submissions — server-paged intake evidence: search, CSV export, retry routing, pinned config versions, consent proof IDs.
  • Versions & test — publish history with Rollback, beside Send a test.

A published page lives at {your-subdomain}.vertiqa.io/pages/{slug}. Copy link and View Live appear once it is published.

Four ways to start a page

All four produce the same kind of draft, and all four go through the same review-and-publish contract.

1. New draft — the AI page builder. Describe the page; the agent proposes fields, copy, and sections you then edit.
2. Start from scratch — the same builder workspace with an empty draft. Use it when you already know exactly what you want to ask.
3. Start from a template — Contact us or Help desk ticket, offered on the builder's start screen. Each states up front where its submissions land.
4. Import specification — paste a validated JSON specification and get a draft with those exact fields, IDs, options, and permission wording. Nothing is paraphrased, nothing is dropped, and no AI is involved. Download schema gives you the JSON shape to author against. It currently trails the product on three newer keys — page endings, page routingDefaults, and the binding's confirmation — which the import and publish endpoints accept even though the downloaded schema does not describe them.

What a page is made of

The builder's centre column is the whole editable draft, under one save/publish bar. Its sections are grouped into four tabs, each showing how much is in it and an amber dot when something in it blocks publish:

• Form — Form fields.
• Scoring — Qualification scoring.
• Page — Page sections, Contact and privacy footer, After submitting.
• Handoff — Submission binding, Submission routing, and — once the page is live and bound to an instrument — Snapshot email. That last one is the same setting the Details screen edits, on the same live page, not a draft copy of it.

A failed publish opens the tab the error belongs to.

• Form fields — text, email, phone, number, long text, select, radio, checkbox, date, date & time, multi-select, rating, and hidden metadata. Each field has a label, a Field ID, an optional placeholder, description, validation pattern, visibility condition, and step assignment.
  • The Field ID is the stable identity of the answer. Once it has appeared in a published version, renaming it is a change publish makes you approve.
  • Hidden metadata fields capture context rather than asking for it: source UTM, Query, Constant, or System value, plus the key to read.
  • Rating fields take a scale with optional per-value labels.
• Form layout — Single page or Multi-step. Multi-step gives the visitor a step counter, Back / Next, and validation per step instead of one wall of errors at the end. Conditional visibility is evaluated on each step, and steps that end up empty — including steps that only held hidden capture fields — are skipped rather than shown blank. Step views, completions, and abandons are recorded per step, though the console tiles today report the page as a whole (views, submissions, conversion) rather than a per-step funnel. There is no save-and-continue-later option for visitors today.
• Qualification scoring — optional, deterministic, and explainable. See below.
• Page sections — hero, benefits, social proof, FAQ, trust bar, embedded form, and CTA band.
• Contact and privacy footer — Use standard notice, Use custom notice, or Hide contact notice. This controls the generic contact notice only; required permission statements stay part of the form either way.
• After submitting — one ending per outcome. See below.
• Submission binding — what a submission creates. See below.
• Submission routing — inbound inquiries, service tickets, and team alerts.

Submission binding — what a submission creates

A page cannot be published without one, because "where does this lead go" is the one thing the product cannot guess. A submission creates:

Mode	What happens
Lead — create or update	Opens a lead in your pipeline, matched to an existing one when the contact already exists.
Contact — create or update	Creates or updates a contact. No pipeline entry.
Opportunity intake	Opens an opportunity in your sales pipeline rather than a lead.
Review request	Recorded as a review response against the inquiry, with nothing created downstream.
Record the submission only	Nothing is created in the CRM. Submissions are still captured and visible on the Submissions tab.

Underneath the mode:

• Carry answers onto the record — optional mappings from a form field to a record field or a custom field. Name, email, and phone are already matched from each field's type; mappings are for the rest of the answers.
• Confirmation email — a reply to the person who submitted, sent to the email answer on the form. Subject and message are optional; leave them blank for the default wording.
• Permission statements — one row per statement, with an ID, a purpose, the exact text, whether it is required, and an optional channel. Purpose must be one of marketing_email, marketing_sms, transactional, research, intake, assessment, or service; channel, when set, one of email, sms, whatsapp, or postal. The statement ID is immutable after publish and must match its consent checkbox field ID. The text you publish is hashed and stored with every submission, so a response proves which wording the person agreed to. Changing that wording is a change publish makes you approve.

Qualification scoring

Scoring is optional, and it never rejects, hides, or discards a response.

• Scoring rules — a label, a field, an operator (=, !=, contains, >, >=, <, <=, is_true), a value, and points. Points may be negative.
• Deal-breakers — the same condition shape plus a reason. A deal-breaker forces the Not a fit outcome regardless of points.
• Outcome thresholds — the score at which a response counts as qualified or review. Anything below both is the default outcome.
• Live simulator — paste sample answers as JSON and see the score, the outcome, and every rule that fired, before anyone sees the page.

After submitting

Endings decide what the visitor sees on the thank-you screen. Without scoring, everyone sees Everyone. With scoring you can also write Qualified, Needs review, and Not a fit endings.

Each ending has a message and, optionally, a booking link chosen from your active booking links by name — never a pasted URL. If that link is later revoked or expires, the button stops rendering instead of sending people to a dead page. An ending picks copy and offers an already-public booking link; it grants nothing, and the booking page still enforces its own availability.

Publishing

Publish computes a diff first. Changes that need a human decision — a field ID rename, a removed field, changed option values, changed permission wording — are listed for approval before anything reaches the public URL. Approve it and the version is written; cancel and nothing changes.

Publishing a page that already exists updates it in place: same URL, same token. Use Edit in builder on a live page to make structural changes; a fresh New draft can never take over another page's address.

Living with a published page

• Edit the copy — Page content changes the headline, page name, subheadline, button text, and thank-you message. Edits go out immediately.
• Restyle — Design sets accent color, background, font, text size, and button shape, repainting the preview as you choose. Use organization color clears a page-level override.
• Route submissions — Submission routing has one switch per destination, and submissions are recorded whichever of them are off:
  • Inbound inquiries — opens an inquiry in your pipeline.
  • Service tickets — also opens a help-desk ticket from the captured inquiry. See Turn a form into a help-desk intake.
  • Submission alerts — emails your team a heads-up per submission, with a link to the inquiry. Alerts deliberately never include what the visitor typed. The switch stays disabled until at least one recipient is on the list; removing the last address turns alerts off. Routing is only available on a published page.
• Embed it — copy the snippet from Embed on your website.
• Tracked QR — published pages can generate a QR code and short URL that route through l.vertiqa.io/r/{code}. See Tracked QR links.
• Archive — closes the public URL while keeping the page and its submissions readable. The token is kept, so Restore brings the same URL back. There is no delete.

Reading submissions

The Submissions tab is the record of what actually happened. Search across submitted answers, page with Previous / Next, and Export CSV for an audited export. Open a row for:

• Answers — labelled by the form, in step order. The sheet is explicit about edge cases: a value normalized on the way in shows what was originally typed, an answer with no matching field is marked as kept on the submission only, and an answer collected under an earlier version says so rather than disappearing. Hidden capture fields are counted separately and shown in the raw payload.
• Routed to — the record the binding created, with Open record, or a plain statement that this page's binding creates nothing. A failed dispatch shows its error and a Retry routing button.
• Consent — the consent proof IDs recorded for this submission.
• Technical detail — the pinned form, page, and binding version IDs plus the raw answers, structured fields, dispatch state, and metadata. This is for a dispute, not for triage.

Rows are badged Test when they came from Send a test. If your retention policy has since removed the answers, the sheet says when, and keeps the routing and consent record.

From a CRM record back to the intake

Leads, contacts, and opportunities created by a binding carry a View the conversion page submission link on their detail page. It opens the exact submission that created the record, on the right page's Submissions tab.

Versions & test

• Published versions — immutable publish history per config type, with Rollback, which publishes a new version from a previous one rather than rewriting history.
• Send a test — enter field values as JSON. Tests validate exactly like a public response, but create no inquiry, no CRM record, no consent, no workflow, no alert, and no confirmation email.

Tips

• Turn Inbound inquiries on for pages that capture leads. Submissions are always recorded, but without this switch nobody is prompted to work them.
• Check the preview at Mobile width before you hand the URL out. Most conversion-page traffic arrives on a phone.
• Submission alerts are a nudge, not a record. The inquiry is what you act on.
• Simulate scoring before publishing, not after. The simulator costs nothing; a mis-scored week of leads costs a week.
• Generate QR codes only after publishing. Drafts have no stable destination.
• Don't leave abandoned drafts in the builder. Publish them, or publish and then Archive them.

Related

• Conversion pages worked examples
• AI page builder
• Inbound inquiries triage
• Turn a form into a help-desk intake
• Tracked QR links