Conversion pages — three worked examples

Three pages, built the way a real one gets built: what to ask, what to score, what the visitor sees afterwards, where the answer lands in the CRM, and what you look at a week later. Between them they use every capability in Conversion pages.

Each step below names the builder tab it happens on — Form, Scoring, Page, or Handoff. The editor shows one tab at a time, so a control you cannot find is almost always on a tab you are not looking at rather than further down the one you are.

Field IDs below are the stable identity of each answer — they must start with a letter and contain only letters, numbers, underscores, or hyphens, and once published they can only be renamed through an approved diff. Pick them deliberately the first time.

---

Example 1 — "Book a same-day repair"

The business: a residential HVAC company. Summer, phones ringing, two vans. The problem isn't lead volume — it's that half the calls are renters who can't authorise work, or people outside the service area, and the good ones wait in the same queue as the rest.

The goal: qualify in the form, hand a same-day slot straight to the people who can book one, and leave a trail the office can settle a dispute with.

Start

Start from a template → Contact us, which already binds submissions to a lead and states so before you pick it. Then edit it into the real page.

Fields — single page, seven questions and one hidden one

Form tab. When you are done it reads Form · 10 — every row in the table below, hidden capture fields and the consent checkbox included.

Keep the layout Single page: a repair request is short, and phone visitors abandon steps they didn't ask for.

Field ID	Label	Type	Notes
full_name	Your name	Text	Semantic type full_name — matched to the contact automatically
phone	Best number to reach you	Phone	Required
email	Email	Email	Required — the confirmation email needs it
service_zip	Service ZIP code	Text	Validation pattern ^[0-9]{5}$
property_role	Are you the homeowner?	Radio	homeowner, landlord, renter, business
problem	What's going on?	Select	no_cooling, weak_airflow, strange_noise, maintenance
urgency	How soon do you need someone?	Select	today, this_week, just_planning
notes	Anything else we should know	Long text	Optional
utm_source	—	Hidden metadata	Source UTM, key utm_source
consent_contact	Permission checkbox	Checkbox	Semantic type consent, required

The hidden field is the one people forget. It costs the visitor nothing and it is the difference between "we spent money on ads last month" and "the van magnets outproduced the ads three to one."

Scoring — say out loud what a good job is

Scoring tab. The tab reads Scoring · 0 until the switch is on — a rule set you have written but not enabled is not a rule set that runs, and the count says so. With the five rules and one deal-breaker below it reads Scoring · 6.

Turn on Enable deterministic scoring.

Scoring rules

Label	When	Points
Homeowner	property_role = homeowner	25
Commercial site	property_role = business	20
System down	problem = no_cooling	30
Wants someone today	urgency = today	25
Just planning	urgency = just_planning	-15

Deal-breakers

Label	When	Reason
Renter — cannot authorise work	property_role = renter	Needs the property owner to approve the visit

Outcome thresholds: qualified at 60, review at 25. Anything below is Not a fit.

Before publishing, check it in the Live simulator:

{
  "property_role": "homeowner",
  "problem": "no_cooling",
  "urgency": "today"
}

That reads back as Score 80/100 · qualified · +25 Homeowner · +30 System down · +25 Wants someone today. Change property_role to renter and the outcome flips to declined on the deal-breaker no matter what the points say.

Scoring never rejects anyone. A declined response is still captured, still visible, still exportable — it just gets a different ending and a different place in the queue.

After submitting — three different last screens

Page tab, below Page sections and the contact and privacy footer.

Outcome	Message	Booking link
Qualified	"You're in the service area and we have same-day slots. Pick one now and we'll confirm by text."	Same-day diagnostic
Needs review	"Got it. A dispatcher will call within the hour to confirm timing."	—
Not a fit	"Thanks — repairs need approval from the property owner. Forward this page to them and we'll take it from there."	—
Everyone	Kept as a fallback in case scoring is ever turned off.	—

The booking link is chosen by name from your active booking links, never pasted as a URL. If that link is revoked or expires, the button disappears rather than sending a customer to a dead page.

Submission binding — where a repair request lands

Handoff tab.

• A submission creates: Lead — create or update. Repeat callers match their existing lead instead of spawning duplicates.
• Carry answers onto the record: problem → a custom field Reported issue; service_zip → a custom field Service ZIP. Name, email, and phone are already matched from the field types, so they need no mapping.
• Confirmation email: on. Subject "We've got your repair request"; message naming the arrival window. Leave both blank and the default wording is used.
• Permission statements: one statement, ID consent_contact — the same ID as the checkbox field — purpose intake, required, text: "I agree to be contacted by phone, text, and email about this repair request."

Routing and distribution

Handoff tab, under Submission routing. With the lead binding on and both inquiries and alerts switched on, the tab reads Handoff · 3 — one destination for the lead, one for the inquiry, one for the alert.

• Inbound inquiries: on — every submission opens an inquiry someone is prompted to work.
• Service tickets: off — this is sales intake, not a help desk.
• Submission alerts: on, to the dispatch inbox. The alert says one arrived and links to the inquiry; it never contains what the customer typed.
• Tracked QR: generated after publishing and printed on van magnets and leave-behind cards, so field-sourced traffic is distinguishable from web traffic.
• Embed: the same page embedded on the website's "Service" page, so there is one form and one set of numbers rather than two.

Publish

The first attempt does not get that far. Submission alerts were switched on before anyone was added to the recipient list, so an amber dot sits on Handoff — raised as the switch was flipped, not after pressing Publish. Add the dispatch inbox and the dot clears.

Publish then shows the changes needing approval before the public URL moves — here, the renamed field from the template's message to notes. Approve, and the page goes live at {your-subdomain}.vertiqa.io/pages/same-day-repair.

Before handing the URL out, use Send a test on the Versions & test tab:

{
  "full_name": "Test Caller",
  "email": "owner@example.com",
  "phone": "555-0100",
  "service_zip": "78701",
  "property_role": "homeowner",
  "problem": "no_cooling",
  "urgency": "today",
  "consent_contact": true
}

A test validates exactly like a real response and creates nothing — no lead, no consent, no alert, no confirmation email. The row appears on the Submissions tab badged Test.

A week later

The office manager opens Submissions, searches no_cooling, and finds one row whose Routed to section shows a dispatch error from an outage. Retry routing creates the lead; the answers were never at risk, because the submission was recorded before routing was attempted.

On the lead itself, View the conversion page submission opens the exact answers that created it — including the utm_source that says it came from the van magnet.

---

Example 2 — "New client assessment"

The business: a consulting firm whose intake questionnaire already exists as a reviewed instrument: 31 questions, four sections, and permission wording their lawyer wrote. Previous attempts to rebuild it in a form tool quietly dropped questions and replaced the permission language with something generic.

The goal: publish the reviewed instrument exactly, let people finish it over two sittings, and route each completed assessment to an opportunity the partner team works.

Start — import the specification

Import specification takes a JSON specification and produces a draft with those exact fields, IDs, options, and wording. No AI, no paraphrasing. Download schema gives you the JSON shape to author against; the server validates on import and again on publish, so anything import accepts will publish.

A trimmed version of that specification:

{
  "slug": "new-client-assessment",
  "formConfig": {
    "type": "form",
    "schemaVersion": 2,
    "name": "new_client_assessment",
    "displayName": "New client assessment",
    "entity": "opportunity",
    "presentation": "wizard",
    "steps": [
      { "name": "about_you", "title": "About you",
        "fieldNames": ["full_name", "work_email", "company_name", "partner_code"] },
      { "name": "engagement", "title": "What you need",
        "fieldNames": ["engagement_type", "budget_band", "start_window"] },
      { "name": "current_state", "title": "Where things stand",
        "fieldNames": ["team_size", "systems_in_use", "process_maturity", "blocker_notes"] },
      { "name": "permissions", "title": "Permissions",
        "fieldNames": ["consent_intake", "consent_marketing"] }
    ],
    "fields": [
      { "name": "full_name", "label": "Your name", "type": "text",
        "required": true, "semanticType": "full_name" },
      { "name": "work_email", "label": "Work email", "type": "email",
        "required": true, "semanticType": "email" },
      { "name": "company_name", "label": "Company", "type": "text",
        "required": true, "semanticType": "company" },
      { "name": "partner_code", "label": "Referral code", "type": "hidden",
        "hidden": { "source": "query", "key": "ref" } },
      { "name": "engagement_type", "label": "What kind of engagement?", "type": "select",
        "required": true,
        "options": [
          { "value": "assessment", "label": "One-off assessment" },
          { "value": "programme", "label": "Multi-month programme" },
          { "value": "advisory", "label": "Ongoing advisory" }
        ] },
      { "name": "budget_band", "label": "Approved budget range", "type": "select",
        "required": true,
        "options": [
          { "value": "under_25k", "label": "Under 25k" },
          { "value": "25k_100k", "label": "25k – 100k" },
          { "value": "over_100k", "label": "Over 100k" }
        ] },
      { "name": "systems_in_use", "label": "Systems in use today", "type": "multi_select",
        "options": [
          { "value": "erp", "label": "ERP" },
          { "value": "crm", "label": "CRM" },
          { "value": "spreadsheets", "label": "Spreadsheets" },
          { "value": "custom", "label": "Custom internal tools" }
        ] },
      { "name": "process_maturity", "label": "How documented are your processes?",
        "type": "rating",
        "scale": { "min": 1, "max": 5,
          "labels": { "1": "Nothing written down", "5": "Documented and followed" } } },
      { "name": "blocker_notes", "label": "What's blocking you right now?",
        "type": "textarea",
        "visibilityCondition": { "field": "process_maturity", "operator": "<=", "value": 3 } },
      { "name": "consent_intake", "label": "I agree to my answers being used to prepare a proposal.",
        "type": "checkbox", "required": true, "semanticType": "consent" },
      { "name": "consent_marketing", "label": "Send me occasional research briefings.",
        "type": "checkbox", "semanticType": "consent" }
    ]
  }
}

The specification above carries only the form, so the imported draft opens in the builder with the questions already exact and everything around them still to decide: the page sections, the scoring, the endings, and the submission binding. That is the intended division of labour — the reviewed instrument comes in verbatim, the operator decides what happens to the answers.

Two details worth copying:

• partner_code is hidden, sourced from the query string. Referral partners send people to …/pages/new-client-assessment?ref=northline, and the code arrives on the answer without anybody typing it.
• blocker_notes has a visibility condition. It only appears for people who rated their process maturity 3 or below. The question that would feel accusatory to a mature team never shows up for them, and — importantly — a hidden required field can't silently block submission.

Multi-step

Form tab.

Form layout: Multi-step. The visitor gets a step counter, Back and Next, and validation per step rather than a wall of 31 errors at the end. A step whose fields are all hidden by conditions — or that only held the hidden partner_code capture — is skipped rather than shown empty.

Visitors cannot save and finish later today, so length is a real cost. Step views, completions, and abandons are recorded per step behind the scenes, but the console reports the page as a whole — views, submissions, conversion — so judge the length by that conversion number and cut questions until it stops moving.

Permission statements — the reason this page exists

Handoff tab. Under Submission binding → Permission statements, two statements matching the two checkbox field IDs exactly:

Statement ID	Purpose	Required	Channel
consent_intake	intake	Yes	—
consent_marketing	marketing_email	No	email

The text you publish is hashed and stored with every submission, so each response proves which wording that person agreed to — not merely that a box was ticked. Change the wording later and publish makes you approve it as a change; the old responses keep pointing at the old text.

Both statements are withdrawable. A withdrawal recorded through the permission link updates the ledger without touching the submission that proves what was originally agreed.

Scoring for triage, not for rejection

Scoring tab for the rules and thresholds; Page tab for the endings they select.

Label	When	Points
Budget over 100k	budget_band = over_100k	40
Budget 25k–100k	budget_band = 25k_100k	25
Multi-month programme	engagement_type = programme	20
Low process maturity	process_maturity <= 2	15
Under 25k	budget_band = under_25k	-20

Qualified at 50, review at 20, everything else Not a fit — which here means "worth a templated reply, not a partner's hour."

Endings:

• Qualified → "Your assessment is with a partner. Book the readout call now." plus the Partner readout (45 min) booking link.
• Needs review → "We'll come back within two working days with either a proposal or a straight no."
• Not a fit → "This looks smaller than the engagements we take on. Here's the self-serve guide instead."

Binding — an opportunity, with the answers on it

Handoff tab.

• A submission creates: Opportunity intake. These are qualified engagements, not top-of-funnel leads, and they belong in the sales pipeline directly.
• Carry answers onto the record: engagement_type → Engagement type, budget_band → Budget band, partner_code → Referral partner. The partner team can then filter the pipeline by referral source without opening a single submission.
• Confirmation email: on — a 31-question form that answers with silence is a form people assume broke.
• Submission alerts: off. Nobody needs a ping per assessment; the team works the pipeline.

After publishing

Two weeks in, the firm rewords one permission statement. Publish lists the consent-text change for approval before it goes out — exactly the substitution that used to happen invisibly. The wording that was wrong for one week is still attached to that week's responses on the Versions & test tab, and Rollback would publish a new version from the previous one rather than rewriting what happened.

An assessment that arrives while the CRM is mid-outage shows its dispatch error on the Submissions tab with Retry routing beside it. The answers were never in doubt — recording the submission and creating the opportunity are separate steps on purpose.

When a client later asks what they were asked and what they agreed to, the submission sheet answers it in one screen: answers labelled by the form version they were collected under, the opportunity they created, and the consent proof IDs. If retention has since removed the answers, the sheet says when they were removed and keeps the routing and consent record.

---

---

Example 3 — "Business readiness pulse"

The business: an advisory programme that assesses the businesses it supports across several readiness dimensions. The questionnaire is already a published instrument, so the scoring is not something the page invents — the page's job is to collect the answers, hand them to the instrument, and send each participant their own snapshot report.

The goal: one public assessment page, scored by a pinned instrument version, where every participant gets a personalised report by email and the programme team gets the run.

This is the page shape to copy whenever the result is the deliverable — the submitter is owed something back, not just routed to somebody internally.

Fields and scoring — the instrument owns the maths

Form tab for the questions. Scoring tab stays off and reads Scoring · 0: qualification scoring and an instrument are two different scorers, and this page uses the instrument. Turning both on means two answers to "how did they do".

Each question that feeds the instrument needs a Field ID matching the input you will map it to. Name them deliberately now — after publish, renaming one is a change publish makes you approve.

Bind the instrument

Handoff tab, under Submission binding → Instrument, beneath the confirmation settings.

1. Instrument version — pick the published version. The page pins that exact version, so a later publication cannot change what past and future submissions are scored against without you deciding to move.
2. Fill every input — one row per declared input, one source each: a form field on this page, or a page value such as the page slug, the submission id, or a pinned programme or cohort key.
3. Fix anything flagged. Problems are stated beside the input they belong to — "The form has no field called consent", "The answer type does not match what score expects."

The pinned instrument counts as a destination, so a page that creates a lead and scores with an instrument reads Handoff · 2 even before any routing switch is on. See Score a conversion page submission with an instrument for what happens when the pinned version is later retired.

Publish first — the snapshot email needs a live page

The Snapshot email section appears on the Handoff tab only once the page is live and bound to a supported instrument. It is not a draft field: it is the live page's own setting, the same one the Details screen edits, on the same row. Editing it in the builder and editing it on Settings → Conversion Pages → your page → Overview are the same edit — there is no draft copy to publish and no second version to keep in step.

So the order is: bind the instrument, publish the page, then come back to Handoff and set up the email.

Snapshot email

Handoff tab, below Submission routing, on the live page.

1. Enable Email participants their snapshot.

2. Write the Email subject, Introduction, and Closing. These are the participant-facing wrapper around the report.

3. Under the advanced fields, write the dynamic paragraphs. They are templates, not fixed sentences, and the fallbacks exist because a real result does not always have a clear winner:

   Field	Used when
   Support heading / Priority support paragraph	Normal case — names the lowest-scoring dimensions that need development
   Support paragraph when all dimensions show strength	Nothing is lagging enough to single out
   Strengths heading / Strengths paragraph	Normal case — names the highest-scoring dimensions
   Strengths when all dimensions are at an early stage	Scores are level and early; there is no differentiated strength to name
   Strengths when all dimensions are balanced at a later stage	Scores are level but mature
   Strengths when no priority dimension needs support	Strengths exist but nothing needs singling out for support

   Write every one of them. The fallbacks are what a participant reads when their results are flat, which is exactly the participant most likely to conclude the report is generic.

4. Save email draft, choose a completed submission, then Preview email and Preview PDF. Previews send nothing.

5. Publish email template.

Editing this wording changes presentation only. It never changes a score, a dimension classification, or what consent allows the report to include.

What publishing the email template does and does not reach

Publishing applies to future submissions. Reports already prepared keep the copy and appearance they were prepared with, so a participant who asks about the report they received last month is asking about a document that still exists as they received it.

If you are also changing the report's branding — logo, colours, font, section headings — publish the appearance first on the instrument's Snapshot format card, then publish the page's email template, so the template captures the appearance you intend. See Customize the instrument snapshot report.

The confirmation screen is a different setting

The screen the participant sees the moment they submit is not part of the snapshot email. It is on the Page tab under After submitting, and an authored ending for the submission's outcome takes precedence over the page's general thank-you message on the Details screen's Page content.

Two surfaces, two edits — the confirmation screen is instant, the snapshot arrives by email once the report is prepared. Say so in the confirmation copy, or the participant reads silence as a failure and submits again.

An optional copy, only with permission

In Snapshot email, add up to five named recipients — a programme manager, an advisor — and enable Offer participants an optional copy to these recipients.

The assessment then shows those names and addresses with an unchecked optional consent checkbox, and the copy is sent by BCC only when the participant agrees. This is a separate permission from the participant's own report. Change the list and the participant must review it again before the next send.

A week later

The programme lead opens the page's Submissions tab and finds each response, the run it produced, and the record it created. On a run, the Snapshot email card states delivery — prepared, accepted by the email provider, or needing attention with the reason beside it — and Download snapshot PDF produces exactly what the participant received.

A participant who never saw their report is answered from that card, not from a guess about whether email works.

What to take from all three

• Decide what a submission creates before you write a single question. It's the one thing the product can't infer, and it's why publish asks for it.
• Score to triage, never to reject. Every response is captured either way.
• Spend the thank-you screen. It's the one moment the visitor is guaranteed to be looking.
• Give hidden fields to the questions you'd otherwise have to ask — source, referral code, campaign.
• Test before you share, and simulate before you publish.
• When the submitter is owed a result, write the fallback wording as carefully as the normal wording. The flat result is the one that reads as generic.

Related

• Conversion pages
• AI page builder
• Score a conversion page submission with an instrument
• Customize the instrument snapshot report
• Inbound inquiries triage
• Booking links
• Tracked QR links