Build an inquiry form that asks only useful questions

Your inquiry form is the beginning of a conversation. It needs enough information to start that conversation well. It does not need to complete your entire sales interview before someone can ask for help.

Start with one live form and the person who receives its submissions. For each question, finish this sentence: “We use this answer to decide…” If nobody can name a decision, remove the question or move it to a later conversation. The aim is useful information with a clear next step, not the smallest possible field count.

Give each field a job

Separate three needs: how to reply, what the person wants, and what determines whether you can help. A local service business may need a service area. A studio may need the kind of project. A specialist consultant may need a brief description of the problem. These are different forms because the first decisions differ.

Do not require a budget range simply because another website has one. If it genuinely changes the route, explain why and include “Not sure yet” when that is an acceptable answer. Avoid demanding a full street address when a town or postal code is enough to check coverage.

Treat this worksheet as a starting point. If a phone-only service cannot act on an email request, offer a different usable contact path. Keep the reason for every required field beside the worksheet so future edits do not quietly turn optional questions into barriers.

Make labels useful before and after typing

W3C recommends associating each control with a label that describes its purpose. For this inquiry form, keep that label visible above the field; text that disappears while someone types is not a durable label. Ask your builder to associate the visible label with the actual control, not just place text nearby. [1]

Write labels in the customer’s language: “What do you need help with?” is clearer than an internal department code. Put short explanations beside unfamiliar questions. Mark required and optional fields consistently, and explain any required symbol before people start. A field should still make sense when someone returns to correct it.

Make mobile entry practical

Ask your implementer to choose an appropriate field type for email and telephone entry, then check the keyboard on real phones. W3C explains that input types can help mobile entry. Its input-purpose guidance separately describes autocomplete values for supported personal-information fields; a type and an autocomplete purpose do different jobs. [1][2]

For example, an email field should identify email entry and, when it asks for the visitor’s own email, support the matching autocomplete purpose. Do the same for their name and telephone number where applicable. Do not turn a postal code into a quantity with increment and decrement buttons. Test the actual countries you serve instead of assuming every code contains only digits.

Complete the form one-handed on a phone. Check that labels stay near their fields, the keyboard does not hide the next action, and zooming does not make help text unreachable. Include a long name and a copied email address in your test. These are acceptance checks for your implementation, not a promise that one field setting fixes every device.

Make errors something people can fix

W3C’s form notification guidance recommends clear feedback, errors that explain a correction, and useful confirmation after submission. It describes both a linked error summary and messages beside the affected fields. Ask your implementer to expose dynamic feedback to assistive technology and connect each message to its field. [3]

Compare “Invalid input” with “Enter an email address so we can reply.” The latter names the missing action. Keep correct answers in place after a failed attempt. Do not make someone recreate their project description because one field needs attention. A red border alone leaves the person guessing.

Test an empty required field, a malformed email, a connection failure, and a second click while the first submission is pending. The interface should distinguish a question that needs correction from a request that could not be delivered. Show a recovery path without claiming receipt before the server has accepted the request.

Explain the next step, then make it happen

Replace an ambiguous button such as “Go” with the action being requested, such as “Send my inquiry.” Before submission, say who responds and give a response window only if the receiving team can support it. After successful receipt, repeat that expectation and explain any genuine next action.

In the receiving system, assign an owner and a backup. Give an unrecognized service choice a review queue rather than dropping it. Check that the owner receives the context already supplied. This is where the form joins your wider lead handoff; a thank-you message alone does not establish follow-up.

Test the whole change before adding more fields

• Use only the keyboard: reach every field, understand the focus position, correct an error, and submit.
• Use a screen reader: check field names, required status, instructions, errors, and confirmation with someone who can assess that experience.
• Submit clearly marked test inquiries on a phone and desktop; confirm the correct owner receives each one.
• Check the failure path and an unmapped request, then verify that successful entries are not duplicated.
• Have the receiving person identify any answer they had to request again. Decide whether it belongs on the form or in the conversation.

Measure accepted inquiries, routing failures, and requests needing clarification separately. If your analytics platform is Google Analytics, its policy prohibits sending personally identifiable information such as email addresses and phone numbers. Keep form answers out of analytics events and URLs; use non-personal event names and totals instead. [4]

A shorter form is not automatically a better form. Keep a question when it earns its place, make it understandable, and verify that the answer reaches someone who can use it.