A useful contact form collects enough information for someone to take the next step. Before adding a required field, ask who will use the answer and what they will do with it. If the answer is “we might want it later,” consider asking later.
This guide is for an established business reviewing an enquiry form, not a checkout, regulated application or detailed tender submission. There is no universal best number of fields. A repair request and a wholesale quotation need different details. The aim is a workable first conversation, with a clear route from submission to reply.
1. Start with the next action
Write down what happens after a buyer presses Send. Will someone arrange a call, check service availability or prepare a quotation? Then list the details needed for that action. Keep information required for an exact final price separate from information needed to begin helping.
For example, a service business may need a reply address, a description of the job and a service area. A wholesaler may need a product reference, quantity and destination to assess an enquiry. These are illustrative choices, not fixed templates. If a buyer does not know a product code yet, offer a way to describe the requirement rather than forcing a made-up code.
The GOV.UK Service Manual recommends documenting why each question is needed and how its answer will be used. Apply that reasoning to your own form: assign each field a purpose and a person who uses it. Its government-service context does not make every GOV.UK layout a requirement for a commercial site.
2. Decide which fields belong in the first enquiry
Use this suggested worksheet when reviewing the form with your designer. “Required” should mean the team cannot take the agreed next step without an answer, rather than everything the team would like to know.
| Information | When it helps the first response | When to leave it optional or ask later |
|---|---|---|
| Name or business name | Someone needs to address or identify the enquiry | Separate legal and trading names rarely need to block an initial conversation |
| Email or phone | Provides a usable reply route | Requiring both needs a business reason; agree how a preferred channel is handled |
| Service or product needed | Routes the request to someone who can help | Add a general enquiry option when a fixed list may not fit |
| Location or destination | Establishes service coverage or delivery feasibility | A full street address may be unnecessary before coverage is confirmed |
| Quantity, dimensions or reference | Helps assess a trade or technical enquiry | Allow an explanation when the buyer does not know the exact specification |
| Budget or deadline | Helps check whether the request is feasible | Do not force an invented answer when the buyer needs advice first |
| Attachment | A photo or list can clarify a complex request | Keep an alternative route and explain allowed formats and size limits if offered |
Review every required field against a real task your team performs. Removing a field is not automatically an improvement: losing the destination on a delivery enquiry can create avoidable follow-up. Conversely, copying a full account-registration form onto a contact page can demand details that no one needs yet.
Do not ask people to enter sensitive documents or payment details into a general enquiry box. If a later stage needs more information, provide an appropriate process for that stage.
3. Make the questions easy to answer
The W3C forms tutorial supports short, simple forms that request information needed for the process. It also explains the role of labels and instructions. This is a reason to review unnecessary questions, not evidence that deleting a particular number of fields will produce a particular increase in sales.
Use visible labels that remain understandable after typing. Mark required and optional information clearly. Explain unfamiliar terms near the field, and give an example when the format matters. A message prompt such as “Tell us what you need, the quantity if known, and where it will be used” is more useful than an empty box headed “Details” when those facts help your team.
Ask the designer to show missing-answer and invalid-answer states. The buyer should be able to identify the problem, correct it and retain the rest of the message. Review the W3C guidance on form instructions for how requirements and help text should be presented. A placeholder that disappears during typing should not carry the only explanation.
Check the actual phone experience. Can someone read the labels, select an option and reach Send without awkward scrolling inside a control? Can a keyboard user follow the form in a sensible order? If you need broader accessibility checks, use the small-business accessibility guide.
4. Agree what Send actually does
A visible confirmation needs to describe the stage the system has reached. Saving a request is different from a staff member reading it, accepting a booking or confirming a price. Ask your designer to explain what happens if storage succeeds but the notification email fails.
Give the buyer an honest next step: which team handles the enquiry, how they can follow up and any response window your business can actually support. Do not copy a “reply within an hour” claim from a template unless your operations can meet it. Offer a contact alternative that your team maintains.
Assign responsibility for checking new requests, including spam or failed-notification cases. If the form appears to work but messages do not arrive, follow the separate contact-form delivery troubleshooting guide. That guide traces missing messages; this one helps decide what the buyer should be asked before sending.
5. Accept the form with a complete test enquiry
Before approving the work, test a normal enquiry and relevant failure cases on desktop and phone. Use a controlled test destination or arrange the test with the receiving team. Record the page, device, test reference, result and person who checked receipt.
- Submit a realistic request and confirm that all intended answers reach the receiving record. Check accented names and longer descriptions where relevant.
- Leave a required answer blank, then enter an invalid reply address. Confirm that the form explains the problem and preserves other answers.
- If attachments are offered, test an allowed file and a rejected format or oversized file against the stated limits.
- Check that an optional field can be left empty and the preferred reply route is visible to staff.
- Open the enquiry as the receiving person, then verify that Reply reaches the intended test contact rather than a no-reply address.
After launch, distinguish form activity from useful business outcomes. A button click is an attempted action; a stored submission still needs review. Record genuine enquiries, whether the team could respond, and what information was missing. Use those observations to adjust the form. Do not treat spam, duplicate tests or a confirmation screen as proof of a new customer.
For a wider review of the route into the contact page, use the website self-audit checklist. Start with one decision now: identify the field your team cannot explain, and agree whether it belongs in the first conversation.
