Design a Clean Split Test for One Call-to-Action

You are a conversion testing adviser for an Australian small business that wants to split test the call-to-action on one landing page — and get an answer it can trust. Most small-business A/B tests fail from too many variables or too little traffic; your design must survive both.

Details:
- The page and its job: [PAGE — e.g. 'the quote-request page for a Cairns solar installer']
- Current CTA exactly as it appears (text, placement, look): [CURRENT CTA — e.g. 'button: "Submit" below a 6-field form']
- What happens after the click: [POST-CLICK — e.g. 'form sends; we call within a day']
- Monthly visitors to this page and current conversions if known: [TRAFFIC — e.g. '~900 visits, ~25 form fills']
- Why the owner suspects the CTA (observations, complaints, heatmaps): [EVIDENCE — e.g. 'people call instead of using the form; "Submit" says nothing']
- Testing tool available: [TOOL — e.g. 'none yet' / 'built into the page builder']

Before designing, do the traffic reality check: using [TRAFFIC], state roughly how long a test would need to detect a meaningful lift (explain the logic in plain English — small pages need bigger differences or longer runs; give the arithmetic at a couple of assumed lift sizes, clearly labelled as assumptions, not promises). If the page is realistically too small for a valid test, say so and pivot the plan to a sequential before/after with its honest limitations — don't run a fake A/B.

Then:
1. Write the hypothesis from [EVIDENCE]: 'Because we observed X, changing Y to Z should increase [conversions] — measured by N.' One variable only; name what you are deliberately NOT changing.
2. Design variant B: new CTA text (3 candidate phrasings, pick one, justify against [POST-CLICK] — the button should say what happens next), and any single supporting change bundled with it stated explicitly if unavoidable (and the cost of bundling acknowledged).
3. Set the run rules: 50/50 split, run whole weeks (why: weekday/weekend behaviour differs), no peeking-and-stopping early, minimum run length from the reality check, and what invalidates the test (a promo, a site change, seasonal spike).
4. Define the decision protocol BEFORE launch: what result ships B, what keeps A, what a murky result means (usually: run longer or test a bigger swing). Include the follow-up test queue — the next 2 CTA-adjacent tests, ranked.
5. Practicalities: how to implement in [TOOL] (or the free options if 'none', described by capability not tutorial), and the one tracking check to do before starting (both variants recording into analytics correctly).

Format: 'Traffic reality check' → 'Hypothesis' → 'Variant B' → 'Run rules' → 'Decision protocol' → 'Practicalities'. Under 900 words, Australian spelling, honest about uncertainty.

Rules: use only supplied numbers — where [TRAFFIC] is missing, stop and ask for it; a test can't be designed without it. Never fabricate conversion benchmarks or promise lift sizes. CTA copy must be honest about [POST-CLICK] (no 'Get instant quote' if a human calls tomorrow).

Copy the block above straight into Any AI tool — anything in [BRACKETS] is yours to fill in.