At this stage, ask only for what your staff need to respond usefully. Make the form possible to complete with a thumb, a keyboard or a screen reader. Tell people what happens next and what you do with their details. Optimise for suitable enquiries and successful follow up, not the fewest fields or the biggest submission count.
Which fields does your enquiry form need?
Only the ones your staff need to respond, route or assess the enquiry at this stage. There is no universally correct field count. A short form can attract requests you cannot serve. A long form can exclude the customer you wanted. So judge a form on completion and on the quality of what comes through, together.
The test for each question is simple. Run it with the people who answer the enquiries, not with a template.
The decision follows the actual service process. Take a bookkeeper who always starts with a discovery call. A working contact method and a sentence about the business are all they need. A tradie who quotes by photo needs the photo. The table gives the common decisions, with the detail by business type after it.
Field or situation | The decision to explain |
|---|---|
Name and contact method | A flexible name field and one working reply channel. Do not force both phone and email |
Service and message | A clear question, with a short service choice only if it helps routing |
Phone, suburb and address | A callback number and a service area check where the job needs them. The street address can wait |
Budget and timeline | Ask when the answer changes your response, allow "not sure", and never because a template had it |
Uploads and references | An order number or a photo where it helps. State file types and size limits before the upload |
Clinics and advisers | Enough to route the request, and no detailed health, legal or financial information in a general form |
For a tradie, a callback number and a suburb are usually justified. The quote depends on a visit and the business has a service area.
Offer the call button beside the form for the customers who would rather ring. Our guide to getting more phone calls from your website covers when the phone should lead.
For professional services, ask for the kind of matter and a preferred contact method. Let the detail come in the conversation. For B2B scoping, a budget or timeline question is fair when it changes what you propose.
For ecommerce support, an order reference and a damage photo save a round trip. Let the person recover if the upload fails. Do not ask for identity documents a support query does not need.
Our audit sample is 100 website audits from May 2023 to September 2026. Now take the sites with an enquiry form. On about 1 in 2, at least one required field was never used for the first response.
That count includes a required phone field on a low commitment request. It also includes a required budget dropdown nobody in the business reads. Both are easy to inherit from a form builder's template.
Cutting those fields is the first change we test. We judge it on how many people who start the form send it. We also judge it on how many of those enquiries are worth answering. Here is one of those changes from our records: a form cut from eight required fields to four. Completion among starts rose from 38% to 45%.
Eight fields, all required, including phone, street address and budget. 38 in 100 people who started it sent it.
Four required fields, phone optional and no budget question. 45 in 100 people who started it sent it.
The change stayed because completion rose and the share of suitable enquiries held. But a before and after on its own can't prove the removed fields caused the rise. Traffic, season and offers move too. That's why we compare matched periods and note anything else that changed. And we check lead quality before calling it a win.
How do you make a form easy to use?
Start with the labels, because everything else depends on them. Every field needs a persistent, visible label that is programmatically associated with the control. The W3C's forms tutorial covers labelling, grouping related fields and giving instructions. Placeholder text that disappears when someone starts typing is not a label. The W3C's instructions guidance is explicit about that.
Mark which fields are required or optional in words, not only with an asterisk or a colour. Group related fields so that a screen reader user knows which questions belong together. Then check:
the keyboard order
that focus is visible on every control
that the contrast holds
that the form still works at 200% zoom
Test with assistive technology as well as on a real phone. An automated scan that passes does not demonstrate that the form is accessible. The scan cannot tell whether the label makes sense or whether the error message helps.
WCAG 2.2 also sets rules for target size and for sticky elements that hide the focused field. Another rule deals with asking for the same detail twice. Our guide to website accessibility basics for Australian businesses covers them and how to test.
Layout, input types and defaults
A single column is a sensible starting point. Leave enough space between controls for a thumb to hit the one it aimed at. Make the submit button bigger than the bare minimum.
Keep the submit action visible when the on screen keyboard is open. Open the chat widget, the cookie banner and the sticky call bar together and see what they cover. A sticky bar that hides the field someone is typing in isn't just annoying. It's an accessibility failure.
Use the input type and autocomplete attribute that match the question. That way, phones show the right keyboard and browsers can fill known details.
Preserve leading zeros. Accept spaces and international formats where you serve people overseas. Let names contain apostrophes, hyphens and more than one word.
<label for="phone">Phone (optional)</label>
<input id="phone" name="phone" type="tel" inputmode="tel" autocomplete="tel" aria-describedby="phone-help">
<p id="phone-help">We only call when it is quicker to sort out your enquiry.</p>
There's no universal rule for choosing radio buttons, selects or search assisted choices. Go by the task and the number of options. Make any default you infer editable. That includes the service from the page or the suburb from a location.
Keep helper text short and only where a question needs it. Every reassurance needs to be accurate. That goes for the helper line in that phone example too. A response time, a confidentiality line or "no spam" must describe what the business actually does. A reassurance that is not true is a misleading claim as well as a broken promise.
Our guide to writing website copy that doesn't sound like a robot covers the sentence level work.
That is an example email led workflow, not the required field set for every business. Put the real response window beside the form, in the business's own hours. Make the alternative contact route a real one.
Should you use one page or several steps?
A simple enquiry usually fits on one page. Several steps help when the questions divide into groups that mean something to the person answering. Think of the job, the site and the contact details.
Neither format guarantees a higher completion rate, whatever a form builder's marketing says. If you use steps, show honest progress, let people go back, and keep their answers when they do. Add a review step when the decision is consequential, such as a quote request with specifications.
Don't make people type the same contact detail twice. Don't require an account to send an enquiry unless there's a clear reason the person would accept.
For conditional questions, remove the steps that no longer apply. If the progress indicator changes, explain the change rather than letting it jump.
A quote calculator needs the same honesty as a form. State its assumptions and exclusions. Say whether the output is an estimate or a binding quote. Tell people before they start if contact details are required to see the result.
Advertising an instant result, then hiding it behind a lead form, is something people remember, and not fondly.
Capturing what someone typed but never submitted is a privacy design decision, not a growth tactic. Do not do it by default through a session replay or a partial capture tool.
Where a campaign page carries its own form, the form should match the request on the page. Our guide to building a landing page that converts covers that.
What happens when someone submits the form?
Three different things can happen: a validation failure, a failed submission and an accepted request. The form needs a different response to each.
Help someone correct a field
The W3C's user notifications guidance sets out what a validation error should say. It should name the field, say what is wrong and say how to fix it. That includes any format requirement.
When several fields fail, list the errors at the top of the form and beside each field. Associate each message with its field. Announce dynamic messages to assistive technology. The W3C does this with a container that has the alert role.
Colour alone is not a message. Keep the valid entries the person already typed. Put focus somewhere useful: the W3C suggests the first field with an error.
Invalid input.
Enter an email address in the format name@example.com.
That example is for a missing or malformed email address. A server or network failure needs a different message entirely.
Timing matters as much as wording. Do not flag a field as wrong while the person is still typing in it. Clear or update the message the moment the entry becomes valid.
The GOV.UK Design System's guide to recovering from validation errors agrees. It says to avoid validating a field before the user has finished entering it. Treat that as design guidance, not a forecast. It won't tell you how many extra enquiries a fix will bring.
Separate a failed submission from a format error
A timeout, an unavailable server and a failed upload are not the visitor's fault. So the message should not read as if they were. Explain what happened, keep the answers, and offer a safe retry or another contact route.
The implementation should stop a double click or a retry creating two enquiries. Even so, it should let the person recover from a failure. Validation should happen on the server as well as in the browser, because browser checks can be skipped.
An email shaped value proves that the text looks like an email address. It does not prove the address belongs to the visitor or can receive mail. So do not tell people it has been "verified".
Show a truthful confirmation
Confirm receipt only after the system has accepted the request. State the next action. Give a response window the business can meet, including its business hours. If the form is a booking request, say that it is a request and not a confirmed appointment.
Thanks, [business] has received your [type of request].
Next, [team or role] will [next action].
Expect a reply within [real response window and business hours].
If you need help sooner, [available alternative and its hours].
[If applicable: This is a request, not a confirmed booking.]
Populate that from how the business actually operates and remove any clause that does not fit. Then test the whole route, not the message:
the accepted request
the status the customer sees
the staff inbox or CRM entry
the assignment
the follow up
That route breaks more quietly than the form does. In the same website audits, we sent a labelled test enquiry. On about 1 in 5 sites, it did not reach whoever answers it within one business hour. A spam folder counts as a miss in that check. So do a wrong notification address, a stopped integration and an unassigned queue.
An accepted request can be stored safely even when the email alert fails. So the business needs a way to detect that failure and recover the stored enquiry. If you send an acknowledgement email, do not echo back sensitive details the person typed.
We'll test your form the way this guide describes and show you what we find.
How do privacy and spam protection fit together?
Both decide whether a real person can send you their details safely.
Check coverage before you write the notice
Coverage depends on the business, not on the form. The OAIC's small business guidance explains who is covered. It says most businesses with an annual turnover of $3 million or less are not covered. But health service providers, businesses that trade in personal information and several others are. So use the OAIC's checklist rather than assuming you're exempt.
That threshold still stands. The government's exposure draft privacy bill of August 2026 keeps it. And the bill is a proposal, not law. Our explainer on Australian privacy law changes for websites covers the detail.
Other obligations, such as consumer law and the Spam Act, apply whether or not the Privacy Act does.
Explain this collection, not just your policy
APP 5 applies to businesses the Act covers. It's about taking reasonable steps to tell people what you are collecting and why. That happens at or before the time of collection, or as soon as practicable afterwards.
A privacy policy link in the footer may not do that for this particular form. The OAIC's APP 5 guidelines note that a policy may describe only the entity's general information handling practices. The same guidelines allow a layered approach. That means a brief notice on the form that links to a fuller collection notice.
Our guide to the privacy policy and terms for your website covers the policy itself. It also explains how the policy differs from the notice beside your form.
The matters to cover include:
who you are and how to contact you
the circumstances of the collection and whether any law requires it
the purposes
the consequences of not providing the information
your usual disclosures
how to find the privacy policy and complain
Also cover whether the information is likely to go overseas and, where practicable, to which countries.
In practice, that means a short notice beside the submit button, written for this form. It links to the fuller notice. Once you have the facts to fill it in, it can follow this structure.
[Business] collects [information] to [specific purpose].
If you do not provide [necessary detail], we may be unable to [specific consequence].
See our [collection notice] for how this enquiry is handled and our [privacy policy] for access, correction and complaint information.
The full notice must match the providers you actually use and the disclosures you actually make. On its own, this opening does not make a form compliant with APP 5.
Keep consent and marketing separate
A collection notice is not blanket consent. A compulsory "I agree to the privacy policy" checkbox on every enquiry form is not something APP 5 asks for. Ticking it does not create consent to anything in particular.
Keep marketing separate from the service request. An enquiry is not permission to send a newsletter. Where you want express consent to marketing, use a clear optional choice that is unticked by default. Keep a record of that consent. Commercial electronic messages then need the applicable consent, accurate sender identification and a working unsubscribe facility.
The ACMA's guidance on avoiding spam explains that consent can be express or inferred. Inferred consent needs a provable ongoing relationship. It does not cover messaging someone just because they bought something.
Protect the form without locking people out
Spam protection works in layers, each with a limit. Server side checks and rate limits catch volume without troubling anyone. A honeypot field catches simple bots. It's hidden from sighted users and screen readers alike and excluded from browser autofill. The honeypot must not trap a keyboard, screen reader or autofill user who never saw it.
Risk based challenges sit on top for the traffic the first layers miss.
The W3C's note on the inaccessibility of CAPTCHA describes visual challenges as largely inaccessible to screen reader users. It describes audio challenges as a barrier for people who are deaf or hard of hearing.
Non interactive scoring, it says, can still deny a real person access and expose data about them. The note's advice is to use the least intrusive layer that works. That means using a honeypot if it suffices, until evidence of robotic attacks dictates something else.
Whatever you choose, provide a usable recovery path or another way to make contact. Watch the false positives too. A blocked customer never tells you they were blocked.
Ask whoever owns the implementation to check:
the vendor's data handling
secure transport
who can see the submissions
how long submissions are kept
how uploads are scanned and stored
No CAPTCHA product and no privacy checkbox makes the whole form secure or compliant.
How do you measure form performance?
Follow one test enquiry through the stages before you calculate anything. Until you know which stage each number describes, the rates won't make sense.
A tracking event is evidence to check against receipt and delivery, not a step the visitor performs. A click on the submit button can still fail validation.
GA4's enhanced measurement form interaction events record form_start at the first form interaction in a session. Then form_submit is recorded when someone submits the form. Both describe a browser interaction. So test them against this form's actual success condition. They don't prove the enquiry reached the CRM or say whether the lead was any good.
Forms that submit through AJAX or are embedded from another service need their own checks. Our guide to GA4 for small business covers the setup. That includes the custom dimensions that form parameters need before they show in reports.
A valid implementation sends Google's recommended generate_lead event when a request is accepted. It carries safe identifiers and context as parameters, rather than a new event name for every form.
Document the event definition. Make sure a reload of the confirmation page or a retry doesn't count a second lead.
Metric | Definition and limit |
|---|---|
Completion among starts | Accepted enquiries divided by distinct starts for the same form and cohort. Define unit and deduplication |
Enquiries from exposure | Accepted enquiries divided by measured exposures to the form. A page view does not prove the form was seen |
Qualified enquiry rate | Suitable, non spam enquiries divided by accepted enquiries, under a stated qualification rule |
Operational outcome | Notification delivery, assignment, reply and the eventual booking or sale, checked separately |
Use the same cohort and the same counting unit throughout. Show the numerator and the denominator. Allow for people who start on a phone at lunch and finish at home that night.
Here is the trimmed form from earlier, scaled to 1,000 views. In the 90 days after the change, 24% of measured form views started and 10.8% were accepted.
Completion among starts is 108 of 240, or 45%. The bigger loss comes before anyone types: three in four people who saw the form never started it. That points at the page, the offer or visitors who only wanted your phone number, not the fields. Our guide to why your website is not converting covers those causes.
Consent choices and blockers limit what you observe. So enhanced measurement alone does not give you a complete abandonment funnel. A bounce rate is a session engagement measure, not a form abandonment figure. Our guide to what bounce rate means in GA4 explains the difference.
Review the numbers by meaningful device and channel groups. Resist drawing conclusions from a dozen submissions.
Send no names, email addresses, phone numbers or message contents to ordinary GA4 events, parameters or page URLs. Google's rules on personally identifiable information forbid sending it. The ban covers URL paths and parameters too.
One usual leak is a query string that carries the email address to the confirmation page. The other is a form name that includes the person's details. A form identifier describes the form, never the person.
A native tag and a GA4 import can both count the same lead in Google Ads. When they do, the campaign trains on a double count. Google's primary and secondary conversion action settings decide which one bids. But a secondary action inside a custom goal still bids. So follow our guide to Google Ads conversion tracking when you set it up.
Every question has a stated reason
Staff can say what they do with the answer
Labels are visible and associated
A screen reader announces each label and each error
The task works on a phone
Keyboard open, banner, chat and sticky bar visible, submit still reachable
Errors name the field and the fix
And disappear once the entry is valid
The confirmation is true
It appears only after acceptance and states a real response window
The notice explains this collection
Purpose, consequence and where the fuller notice and policy are
Spam controls have a way through
A blocked person can still reach you
The lead event means an accepted request
Tested against receipt, with no personal data in it
That checklist covers the form. Our DIY website audit checklist covers the rest of the site.
What we recommend at Elev8d
Fix delivery before design. A good looking form that never reaches anyone is worth less than a plain one that always does. So we prove the route works before we touch a field.
Then we cut the form back to what the first reply needs. We sit with whoever answers the enquiries and go field by field. Anything they can't name a use for goes, waits for the follow up or becomes optional. For a typical service enquiry, that leaves:
a name
one way to reply
the job
for trades, a suburb
Next come the labels, the error messages and the confirmation. That's because they decide whether a finished form sends and whether the person trusts that it did. Multi step layouts, quote calculators and visible CAPTCHA challenges wait until those basics hold. Each adds moving parts. None guarantees more enquiries.
For spam, we start with server side checks and a honeypot. We only add a challenge if bots still get through.
We count accepted and suitable enquiries with one lead event across every form, never submit clicks.
We'd change course when the test enquiry arrives, the form is lean and enquiries are still thin. Then the page around the form is the next suspect. Our guide to service page structure and copy is where we'd start. When one fix won't do, our conversion optimisation work covers the whole journey.
FAQ
Should a phone number be mandatory?
Only when the business genuinely can't respond without it, like a trade that quotes by calling back. Then say why beside the field. On a request that an email could answer, a required phone field invites a fake number. That fake number still counts as a lead in your reports.
Do quote requests count as confirmed bookings?
No. A quote, booking or appointment request stays a request until someone at the business confirms it. Count it as an accepted request in your measurement and record the confirmed outcome separately. Otherwise the form looks more productive than the business.
How often should we test a form?
After every change to the form, the site, the email routing or the CRM. Beyond that, test on a routine that matches the risk and the volume.
A monthly test is plenty for one business and far too little for another. Compare a clinic receiving 20 requests a day with a consultancy receiving two a week. The clinic should check delivery far more often.
Next steps
Send a real test enquiry
Fill in the form on a phone with a name staff will recognise. Then follow it to the inbox or CRM, the assignment and the reply. If any stage fails, that is the first job.
Make one evidenced improvement
Pick the problem the test or the measurement showed and change that one thing. Judge it on accepted and suitable enquiries, not on submissions alone.
Check that staff received and handled it
Confirm who owns new enquiries. Check they meet the response window shown on the confirmation. Make sure the lead record shows what happened next.
