Which fields does a service enquiry form need?

An initial enquiry needs a way to reply and the details the team cannot take the next step without. For a callback, the key field is a phone number. For an initial service estimate, the team may need the type of work, its scope and the location. To arrange an appointment, a preferred time matters, but requesting it does not confirm a booking.

For each question, note in your working document who will use the answer and what they will decide based on it. If the answer is only needed after the order has been agreed, move the question to that stage. Shorten the form by considering what each field contributes, rather than aiming for an arbitrary three fields.

This approach follows the W3C WAI guidance on forms: ask only for what the process requires. A short form does not replace a clear offer or the work of handling enquiries.

Use this table to review common contact form fields. These are possible choices, not a list to copy in full onto your website.

If you only reply by phone, call the form a callback request. If you let people choose email or phone, their chosen channel should be enough to submit the form. Do not offer a messaging app the team does not check or require a second contact method without explaining its purpose.

The following scenarios are illustrative examples, not accounts of XEVOR client results. Each set of fields depends on what the team promises to do after submission.

• Request a callback. A phone number; a name and preferred time can be optional if the team can accommodate those preferences. The introduction explains that this starts a conversation about the service, rather than confirming an order.
• Ask about cleaning a flat. Contact details, the type of cleaning, the area and an approximate floor area help the team discuss a visit and the scope of work. Let people describe the situation if they do not know which service name to choose. The exact address and access to the flat can be agreed later.
• Discuss website development. Contact details and a few sentences about the business and the intended result provide a starting point for the first reply. A link to an existing website and a preferred deadline are useful if available; a finished technical specification should not be a condition for the first conversation.

For example, a cleaning team may need the floor area even for an initial discussion. Removing it simply to shorten the form makes little sense if the team must ask for it in the next message anyway. The flat number, however, may make no difference at this stage.

When an approximate answer is enough, allow one: a floor area range, a likely month or “I do not know yet”. Do not make people invent an exact value just to pass a field check.

Make a field required only when you cannot take the promised next step without it. Mark the others as optional. If you use an asterisk, explain its meaning before the fields; do not rely on colour alone.

A field label should remain visible after someone starts typing. A hint inside an empty field can show an example, but it does not replace the label. The WAI guide to labelling form controls also explains how to associate each label with its form control — a task for the developer.

Instead of a vague “Message”, you could write “What do you need done?” and add a short hint: “Describe the task and any important conditions. We will discuss the details with you.” For a file upload, explain the allowed formats and maximum size before someone selects a file. Do not ask people to send passwords or payment details through a general enquiry form.

Beside the form, explain how you will use the contact details and link to an up-to-date data handling notice. The wording must reflect how the website actually works; copying a checkbox from someone else’s form does not ensure this.

“Send an enquiry” suits an initial discussion. “Request a callback” works if the team will phone. “Request an estimate” fits a process where the team clarifies the details and prepares an estimate after the enquiry. “Get an exact price” would be misleading if the next screen only confirms that the contact details have been accepted.

A short explanation of the next step before the fields is enough: “Leave your contact details and describe the task. We will clarify the details for an estimate.” Only state a response time the team can meet, taking working hours into account.

The wording should follow through on the page’s promise. If it is difficult to explain the service briefly before the enquiry, use our service page copy examples. Check where the page’s button leads as well: people should reach the right form with a clear understanding of its purpose.

A form’s job does not end when someone presses the button. People need to know whether submission is still in progress, whether they need to correct something and whether their enquiry has been accepted. Fields disappearing without an explanation leave them uncertain.

These are examples of states to agree with the developer. Do not show success immediately after a click. Acceptance by the system, delivery of a notification and a team member reading it are different events. Without confirmation, do not say a team member has already received the email; do not describe a requested date as a completed booking.

An error should help someone correct a specific field, and the status should also be accessible to people using screen readers. The principles behind this feedback are described in the WAI guidance on form notifications. Give these requirements to your developer alongside the wording for each state.

Open the service page on a phone and follow the journey through to the form’s response. Separately, ask your developer to demonstrate error handling and an unconfirmed submission. Use agreed test data for these checks, not customers’ private enquiries.

• The page’s button leads to the right form, with its heading and first field visible.
• Labels, hints and errors remain readable when the on-screen keyboard opens; the page does not scroll sideways.
• Email addresses and phone numbers are easy to enter and fill with autofill; a familiar phone number format is not rejected without explanation.
• Tab moves through the fields and button in a logical order, focus is visible and every required action is available without a mouse.
• An error does not erase the task description; it is easy to find and correct.
• Clicking again during submission does not create a duplicate, and the result message matches the actual state.
• A test enquiry reaches the agreed channel, and the person responsible knows how to respond.

A form helps visitors get in touch, while search readiness also depends on the website’s content and structure. Checks for URLs, headings and indexing are covered in our guide to SEO during website development. Reducing the number of fields alone guarantees neither rankings nor more orders.

Prepare a short document about one enquiry. For each field, record its label, why the answer is needed, whether it is required, its hint and its error message. This gives the developer a concrete basis for estimating the work.

• The service, the button’s promise and the team’s next action.
• The fields and their dependencies: which follow-up questions appear only for certain choices.
• The recipient, working channel, person responsible and realistic response arrangements.
• Submission, error and success messages in every website language.
• Data handling, file limits, protection against automated enquiries and repeat submission.
• Acceptance checks: success, an invalid field, a failure and confirmation that a test enquiry is received.

For a single offer, you can agree the form as part of landing page development for a service, or, for several areas of work, alongside building a business website. We discuss integrations, attachments and complex journeys separately. Send XEVOR a description of the website you need — we will define the enquiry journey and the development scope for an estimate.