Todd Ronczka

Case study Healthcare, Australia and New Zealand

Conversion components for a booking-led clinic site

People ready to book were meeting competing calls to action and forms that were hard work on a phone. Every stalled visit risked an enquiry or booking going to the next clinic in the search results.

Client
A multi-clinic healthcare group
My role
Diagnosis to production: CTA hierarchy, forms, trust content and tracking requirements
Disciplines
Conversion optimisation, Forms and lead capture, Mobile UX, Component architecture

Client anonymised. Details are generalised and contain no confidential figures.

Context

A healthcare group with clinics across Australia and New Zealand, whose websites exist to turn people researching a treatment or a clinic into an enquiry or a booking. Calls to action and forms had built up page by page over time, so the next step looked different depending on where someone landed. The task was to find where people gave up before making contact and fix the parts of each page that carry that decision.

Constraints

  • Components were shared across every clinic and both markets, so each had to work for any location.
  • Health advertising rules restrict testimonials and outcome claims, which limits what trust content can say.
  • Mobile was the primary layout, not a scaled-down copy of desktop.
  • Enquiries and bookings had to keep flowing while components were swapped in.
  • Tracking had to carry across the changes so enquiry data stayed comparable.

Diagnosis

The first question was where people dropped out, not how the pages looked. In GA4 I traced the path from landing page to a booking or enquiry click, then on to a submitted form or started booking, split by device. Hotjar-style recordings and heatmaps on treatment and clinic pages showed what people were doing at the point they stalled.

Four patterns came out of it:

  • Too many equal choices. Booking and enquiry actions often carried the same visual weight as phone numbers and unrelated prompts, so people had to work out how to make contact before deciding whether to.
  • The action moved on mobile. On a phone the primary action often sat below long blocks of copy, and its wording changed from one page type to the next.
  • Reassurance arrived late. Content about who a patient would see and what happens at a first appointment usually sat below the form, after a hesitant visitor had already decided.
  • Forms asked too much, too early. First-contact forms requested details that only mattered at the appointment, and errors only showed after submitting.

Tracking made this harder to see. Calls to action were not tagged in a consistent way, so a click in the page header could not be compared with one further down.

None of these stopped a determined patient. Each one gave a hesitant patient a reason to leave and search for another clinic, and that is where enquiries were leaking.

Approach

The fix had to be a set of shared components with rules for where each one goes, not a list of page fixes. Fixing pages one at a time would have recreated the drift that caused the problem.

One primary action per page type

People on a clinic site arrive at different points. Someone checking a clinic’s opening hours is usually close to acting; someone reading about a treatment is often still weighing it up. I gave each page type one primary and one secondary action to match, and demoted everything else to plain links:

  • Clinic pages: book first, call second.
  • Treatment pages: enquire first, book second, with reassurance beside both.
  • Articles: a soft next step towards the relevant treatment or clinic.
  • Contact and booking pages: nothing that competes with the form.

Trust that stays within the rules

Health advertising leaves little room for testimonial-style proof, so reassurance had to be factual and sit next to the action it supports. In practice that meant clinician background and a plain description of the first appointment, written once and reused.

Hypotheses before changes

Each change was written down as a hypothesis with the signal that would show it working. For example: if the primary action stays in view on mobile, a larger share of clinic-page visits should reach the booking step. That gave every change a reason to exist and a way to check it later.

Implementation

Components

I built the components into the existing site templates, each with a small set of CMS fields and variants so the same code covers every page type.

  • Action block: primary and secondary actions, with wording set by page type rather than typed in each time.
  • Mobile action bar: keeps booking and calling within thumb reach, and steps aside when a form field has focus so it never covers what someone is typing.
  • Trust panel: clinician and first-appointment content drawn from one source, so it reads the same on every page that uses it.
  • Enquiry form: HubSpot forms styled to match the site and cut back to what first contact actually needs.

Forms

Labels stay visible, and errors appear beside the field once someone moves on from it. The confirmation message says what happens next. Hidden fields capture the page and clinic each enquiry came from, so it arrives with context instead of needing a follow-up question.

Tracking

I wrote a GA4 event specification covering action clicks (with position and variant), form starts, form submissions and booking starts, then worked through it in Google Tag Manager with the people who managed tagging. Old calls to action were swapped out template by template, with events checked in preview before each release, so reporting would carry across the change without a gap.

Every component went through keyboard-only and phone-width testing before release.

Outcome

Structural outcome: what changed in how the site works

The websites now work from one agreed CTA hierarchy and a shared set of conversion components, so each page type's primary action is set by its template rather than by whoever last edited the page. Adding a call to action or an enquiry form is now a matter of choosing a component, not rebuilding one by hand. Enquiry and booking events follow one tracking specification, so later changes can be judged against a consistent baseline.

Tools

  • HTML / CSS / JavaScript
  • GA4
  • Google Tag Manager
  • HubSpot forms
  • Hotjar-style behaviour analytics