Website enquiry forms: clearer requests and better first conversations
If visitors complete the form but your team cannot understand what they need, field count is only part of the problem. A useful enquiry form helps someone describe their situation and lets you respond with the right conversation. Collect the information needed to begin that conversation, rather than as much information as possible.
Give every field a clear purpose
A name, one way to contact the person, the relevant service and a short description are useful starting points to consider. Before requiring both telephone and email, ask whether your team genuinely needs both at this stage.
An existing website URL may help with a redesign but should not be mandatory for a first-time website owner. If you ask about budget, allow “Not decided yet”. Making uncertain information mandatory can exclude someone who is ready for a useful conversation but not a complete specification.
Use understandable labels and examples
The W3C form tutorial identifies clear labels, instructions and accessible error or success feedback as parts of usable forms. Do not rely only on placeholder text that disappears during typing. A prompt such as “What would you like help with?” may offer more direction than the label “Message”.
An example instruction could be: “You can include your current website, required pages and target period.” Treat this as guidance rather than a compulsory checklist. Let visitors explain their needs in their own words without expecting a detailed technical brief.
Preserve entered information after errors
If something is missing, explain which field needs attention. Use a written message rather than a red outline alone. A network or server failure should not be presented as though the visitor entered incorrect information.
Give the developer this acceptance scenario: enter a project description, leave the email incomplete, submit and then correct the address while retaining the original description. Set aside separate checks for phone keyboards, keyboard navigation and screen-reader use. A visually neat form does not prove those journeys work.
Match confirmation to actual receipt
A button click is not a delivered enquiry. Show a success message after the server has accepted the submission, and provide a way to retry when it fails. Do not promise a response time that your team has not agreed to meet.
Trace a test enquiry all the way to the real recipient inbox. Receiving a notification and creating a record in a customer system are separate checks. Include double-clicks, interrupted connections and repeat submissions in the development scope so the same request is handled deliberately.
Complete the form with a team workflow
Who responds, how are requests assigned and where is the outcome recorded? These decisions outside the contact page determine whether the form is useful. Keep form views, successful submissions and actual sales conversations distinct in measurement.
A simple workflow might use: new / reviewing / call scheduled / outside scope. Do not place message contents or contact details into analytics event names. Read the service page guide for the step before the form, or explore our conversion optimisation service for the complete journey.
Frequently asked questions
How many fields should an enquiry form contain?
There is no universal number. Establish how each field will be used in the first conversation, and avoid requiring information that is unnecessary or can be requested later.
Can a WhatsApp link replace the form?
It can suit some workflows. Plan how enquiries will be recorded, assigned and followed up. Do not count a click on the link as a message that has actually been sent.