Website enquiry forms: which fields to keep and what to show after submission

An enquiry form should help visitors start a conversation with your company and give your team the information needed for the next step. Too many questions ask people to do work before they understand its purpose. Too little information means the conversation starts with the same questions all over again.

Design the form alongside the process for handling enquiries. Decide what to ask now, what to clarify later and how to show visitors that their request has been received.

First, decide what follows: a member of your team calls, prepares an initial estimate, clarifies the task or suggests a meeting time.

This determines the fields you need. A callback requires a phone number. A project estimate may need a short description of the task. A booking enquiry needs the relevant service and a suitable time.

Explain the purpose if a form serves several different actions. Someone requesting a consultation should understand what information to provide and what your company will do in response.

Every required field should help your team take the next step. Information needed only after the project has been agreed can usually be requested later.

For each field, ask whether your team could continue without that answer.

• Contact details for a reply. Ask for an appropriate way to get in touch. Require both a phone number and an email address only when there is a clear need for both.
• Name. It helps you address someone personally, but whether it is required depends on your process.
• Service or enquiry topic. This helps route enquiries. If the visitor is already on a specific service page, the service can be passed through automatically.
• Task description. This provides context. A short hint helps visitors understand what to write.
• Budget and deadline. These may matter for project work. Include a “Not decided yet” option if visitors are not ready to specify them.
• Company, job title, address and billing details. Ask for these at the first step only when they are genuinely needed to handle the enquiry.

A shorter form is not always better. An initial enquiry about a complex service may need more detail. Each question should have a clear purpose, and visitors should be told if they are being asked to complete a full project brief.

Field labels should remain visible once someone starts typing. Placeholder text can provide an example, but the field still needs a clear label.

Mark required and optional fields consistently. For an open question, provide a brief hint: “Describe the service you want to present on your website and the main goal of the project.”

Labels must also be associated with their fields in the implementation so people using assistive technology can use them. This is explained in the W3C guidance on labelling form controls.

Complete the form on a real phone. Check whether it is easy to choose a service, move between fields and press the button with the keyboard open.

Use suitable input types for email addresses and phone numbers. Check autofill and numbers with different country codes. A rigid input mask designed for one local format may create problems for international clients.

An error should explain what to correct and appear near the relevant field. Correcting one answer should preserve the other information already entered. Error messages must also be accessible to screen reader users. These principles are covered in the W3C guidance on form notifications.

Plan for submission failures too. Visitors should understand whether the request was sent, whether they can try again and how else to contact your company.

A broader set of checks is available in our article on checking the mobile version of a website.

After a successful submission, explain:

1. What was received: a quote request, an enquiry or a booking request.
2. What happens next.
3. How your company will contact the person.
4. When to expect a reply, if you can reliably meet that timeframe.
5. Where to find contact details for an additional question.

Receiving a booking request does not mean an appointment has been reserved. If a team member needs to confirm availability, say so clearly. Similarly, a quote request should not look like a confirmed order.

The button and confirmation message should describe the action being taken. “Request a quote” suits a pricing enquiry, followed by an explanation of how you will prepare a reply.

For a multilingual website, translate the labels, errors and confirmation messages. The email sent to the visitor should also match their selected language.

The on-screen message and delivery to your CRM or email inbox are separate parts of the process. Check the entire route: submission, storage, data transfer, notification and assignment to a responsible team member.

For an integration, decide how transfer failures will be detected and retries handled. Repeated clicks or submissions should not silently create duplicate tasks for your team.

In analytics, distinguish a button click from successful receipt of the form. The success event should reflect a confirmed processing stage. Recording that event does not by itself mean you have gained a customer.

Then assess enquiry quality: can you contact the person, is their task a good fit and does the conversation continue? If you have visitors but few enquiries, use our plan for checking a website that gets traffic but no leads.

Suppose a company provides a project-based service and replies to clients by email. This is an example to discuss, rather than a required set of fields for every business.

Fields:

• Email address: required so the company can reply.
• Name: optional.
• Short task description: required, with a clear hint.
• Link to an existing website: optional.
• Preferred deadline: optional, with a way to indicate that it is not yet known.

Button: “Request a quote”.

Confirmation:

For the live form, add a real response timeframe if one has been set, along with current company contact details. Information about data processing should be available beside the form. Present any newsletter subscription offer as a separate choice.

• The next step triggered by submission is clear.
• Each required field has a reason.
• Labels remain visible while typing.
• Errors explain how to fix the problem.
• All fields and the button are accessible on a phone.
• The confirmation reflects the request's actual status.
• The enquiry is saved and reaches the responsible team member.
• All messages and emails have been checked in the required languages.

If the form is still being designed, its different states can be agreed as part of website design in Figma. Implementation of the working form and integrations is discussed separately. For improvements to an existing website, consider website support and design, with the task assessed for your specific platform.

A good form connects a clear visitor action with a working enquiry process. Fields, messages and data delivery should form one consistent sequence.