Lead capture forms

A lead capture form should let someone make a clear request and give your team enough information to answer it. Start with the response you offer, then ask for the details needed to provide it. A completed form records a request; it does not establish that the person or project is qualified.

Design around the first response

Decide what happens after submission. Will someone answer a service question, review project details or arrange a discussion? State that outcome beside the form and make the button describe the request. “Send my project enquiry” is clearer than “Submit” when someone is asking for a project review.

The form should reflect the invitation that brought the visitor there. A service enquiry needs room to describe the need. A resource request may need only an address for delivery. Neither calls for a questionnaire about every service you sell.

Before adding a field, ask the people who handle enquiries what they would do with its answer. If they need the detail only after deciding to speak with the prospect, consider collecting it then. If it determines where the request goes, explain why it is needed now.

Make each question easy to answer

Use visible labels and mark required fields clearly. Give format instructions before someone makes an error. An example inside a field can help, but it should not replace a label that remains visible while the person types. Group related questions in a sensible order.

A first enquiry might ask for a reply method, the service of interest and a short description of the need. The fields depend on the promised response. A phone number may be needed for a requested call but not for an email reply. A full street address may matter for a site visit, while a broad location may be enough to assess whether a visit is possible.

Leave room for uncertainty. A service list can help route requests, but someone who is unsure which service applies should still be able to ask.

Associate each control with its label in the code, not just through its visual position. The W3C recommends using a label element whose for value matches the control’s id, and fieldset and legend elements to group related controls.

Put general instructions, such as which fields are required and what formats to use, before the form. Screen readers may switch to a mode that reads form controls, so instructions should also be available alongside the relevant controls, such as within their labels.

Explain collection and follow-up

Tell people how their details will be used and what response to expect.

For organisations covered by the Australian Privacy Principles, APP 3 permits collection of solicited personal information only where the applicable necessity test is met; sensitive information has additional conditions.

APP 5 requires reasonable steps to notify people of specified collection matters or ensure they are aware of them. The requirements depend on the organisation and collection circumstances.

Keep a request for an enquiry response distinct from any separate marketing preference, and check current ACMA guidance before sending commercial messages.

Collection must also be by lawful and fair means, and from the individual unless doing so is unreasonable or impracticable.

An APP 5 notice may need to identify the collecting entity and give its contact details. It may also explain the circumstances and purposes of collection. The notice may state whether collection is required or authorised by law, and the consequences if the information is not collected. It may outline usual disclosures and provide information about its APP Privacy Policy.

It must also address likely overseas disclosures and, if practicable, the countries involved.

Take reasonable steps before or when collecting the information, or as soon as practicable afterwards if that is not practicable.

Handle errors and completion honestly

When a field needs correction, identify it and explain how to fix it. Keep other answers intact where possible.

If the form cannot send the request, say that it has not been sent and give an alternative contact route that the business monitors. After a successful submission, confirm what was received and what happens next. Do not call a request a booking unless an appointment has been confirmed.

Before relying on the form, check it with a keyboard and on a phone. Try required-field errors, a failed submission and the success message. Confirm that the request reaches the intended team with its service context.

Make submission feedback available to assistive technology as well as visible on the page. When a submission reloads the page, a page title or main heading can announce success or errors; a dialog may help when other feedback could be missed, but it needs keyboard access and must respect the user’s settings.

If the form has a time limit, avoid imposing one where possible. If a limit is necessary, such as for security, the W3C recommends giving people the option to turn it off or extend it.

Judge the form by usable requests

Review successful submissions alongside the enquiries your team could answer. If many people start but do not finish, inspect the questions, instructions and technical errors. If submissions lack context, consider whether one clearer question would help the first response. If unsuitable requests are common, inspect the invitation and service explanation before adding qualifying fields.

Treat form completion, assessment and later sales outcomes as separate stages.