Conversion pages — two worked examples

Two complete conversion pages built end to end — a same-day repair request with scoring and booking, and an imported multi-step client assessment.

Reviewed Aug 19, 2026AdminVertiqa 1.74.1+

Two 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.

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

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

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

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

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

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

Publish 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 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

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

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

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.

What to take from both

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.

Related guides

Account vs contact vs location

← PreviousContacts overview Next →Edit a contact