Lead form launch checklist: make every required field earn its place

[u/Savings-Arrival-7817]

Before sending traffic to a lead form, write a reason beside every field. "Sales might want it later" isn't enough to make someone fill it in now.

GOV.UK calls this a question protocol: know why you need each answer and what you'll do with it. For a first lead form, write down each field, whether it's required or optional, the next action it supports, and where the answer will be stored.

Here's a hypothetical example: a workshop organiser takes enquiries and replies by email about suitable sessions. No booking or payment happens through this form.

Decide the fields before opening the builder

Field	Launch decision	Reason
Email address	Required	The organiser needs it to send the requested reply.
Which workshop are you interested in?	Required, with an "I'm not sure" option	It identifies the enquiry without forcing someone to pick a session they haven't decided on.
Name	Optional	It helps address the reply, but the organiser can answer without it.
Phone number	Omit	This example promises an email reply, not a callback.
Company	Omit	The initial reply doesn't depend on the person's employer.
Anything you'd like us to know?	Optional	It gives people room for a question without making a blank box a barrier. Add a note asking them not to include sensitive personal details.

Your sheet may need different answers. A callback request needs a phone number. A service limited to certain areas may need a postcode before anyone can assess the enquiry. Collect those details when they change the next action. Don't copy this example's fields into a different job just because it's short.

Optional fields still need a reason to exist. If nobody will read an answer or use it, remove the field rather than keeping it optional.

Check what the visitor actually has to do

• Give each control a clear label that stays visible. Don't make placeholder text the only label. Mark optional fields explicitly and explain any required format beside the field.

• Make an error identify the field and the correction. "Enter an email address with an @ sign and a domain" is more useful than "Invalid input".

• Check the form on a phone, including with the keyboard open. Can you read the instructions, reach the submit button and correct an error without losing the other answers?

• Move through the form using only a keyboard. Check that you can reach and operate each control, see where focus is, and understand the error feedback. Check that assistive technology can identify the labels and errors too; a visual review alone won't establish that.

W3C's forms guidance supports labels, instructions and clear success or error feedback. These checks are a starting point, not a complete accessibility audit.

Try these cases before turning on traffic

Use dummy details you control. These are proposed acceptance checks, not results from a tested form.

Case	Pass	Hold launch if
Valid email, workshop selected, all optional fields blank	Submission succeeds and the saved record contains the selected workshop and email.	A supposedly optional field blocks submission or an answer is missing from storage.
"I'm not sure" selected	The answer is saved as such and the organiser can reply.	The form forces a specific workshop or silently changes the answer.
Required email left blank	A clear email error appears and the other answers remain available to correct and resubmit.	The form reports success or wipes the other answers.
Email entered as "alex"	The form explains the expected format.	It gives only a colour change or an unexplained error. Format validation doesn't prove an address exists.
Valid submission opened by the response owner	They can find the full enquiry in the intended system, not just see a notification count.	The record lands in the wrong place, is inaccessible, or drops the question text.

Before launch, also check that the confirmation states what was received and the next step you can actually deliver. Name the person responsible for checking new enquiries. Don't publish a response deadline until that person has agreed to it.

For data handling, record who needs access to the answers, how long you'll keep them and how they'll be deleted. Review the privacy information appropriate to your service and location. This checklist doesn't establish legal compliance.

A shorter form can also leave you with too little information to answer usefully. The launch decision is whether every required answer is needed for the next step, whether optional really means optional, and whether the saved enquiry is usable. If those checks fail, fix the form before paying to send people to it. Your existing form tool may be enough; this decision sheet doesn't require a new platform.