An enquiry form should ask only for information needed to understand the initial request and reply. Connect every required field with a decision, explain optional details and avoid collecting sensitive material by default. Provide accessible instructions, clear errors and an accurate confirmation that distinguishes receipt from an agreement to provide the service.
Justify each question before making it required
List the decisions made when an enquiry arrives: whether the request is in scope, whether timing might be feasible and how to reply. Build fields around those decisions. A name, reply address and short project description may be enough for an initial conversation. An organization, budget range or preferred date may help, but consider whether the person can reasonably know the answer at this stage.
For each field, write a private purpose note. If nobody can explain how a compulsory telephone number affects the response, make it optional or remove it. Do not request a home address, identity document or detailed personal history for an ordinary service enquiry. More fields do not automatically produce better qualified conversations; they can discourage relevant visitors or invite unnecessary disclosure.
Use a small number of examples to clarify the description field without prescribing one kind of project. Explain that a summary is sufficient and that confidential files or account credentials should not be included. If attachments are genuinely necessary, define acceptable material and handling separately. A general upload box can create responsibilities that the form owner has not prepared to manage.
Write instructions people can use
Give every control a persistent label and state which answers are required. Placeholder text should not carry the only instruction because it disappears while someone types. For date or budget fields, make the expected format and units clear. Include an “not decided” route when uncertainty is a legitimate answer. Do not force a fabricated number merely to let a prospective client send a message.
Keep validation messages specific. Tell the visitor which field needs attention and how to correct it, while preserving the text already entered where practical. Consider keyboard use, assistive technology and narrow screens as part of the actual form journey. The W3C further reading provides form instruction and feedback guidance; a short checklist alone does not establish that an implementation is fully accessible.
Explain what submission means
The confirmation should state that the enquiry was received only when the system has evidence of receipt. A local preview or button animation is not proof that a message reached its destination. Tell the visitor what to expect next, using a response window you can maintain. If sending fails, give a useful recovery route and avoid falsely reassuring them that the enquiry is safely queued.
Place an appropriate privacy explanation near the form and connect it to the actual handling process. Clarify whether the message will be shared with collaborators when relevant. Keep marketing choices separate from the request for a service response. Review old fields when your intake process changes, and test the entire route with authorized test data rather than claiming success from the visual appearance of the form.
Fictional example: shortening a consultant’s intake
A fictional process consultant reviews a form requiring a postal address, telephone number, company revenue and ten project questions. Her initial decision is simply whether a request fits her documentation service. She removes the address and revenue fields, makes telephone optional and asks for a reply email and a short description of the task. Timing offers an “exploring options” choice.
The new confirmation copy explains the intended reply window and says that receipt does not reserve work. A separate test plan covers successful sending, failure feedback and keyboard completion using invented details. The example describes a design and verification plan; it does not claim that a mail provider accepted a message, an inbox received it or a production form passed accessibility testing.
A checklist for your next step
- Link fields with intake decisions.
- Mark required and optional answers.
- Provide useful uncertainty choices.
- Explain errors and recovery.
- Verify receipt before confirming it.
Common questions
Is a shorter form always better?
No. Keep questions needed for the actual decision, but remove requirements that collect detail without a clear intake purpose.
Can I call a form working after testing the button?
No. Check the complete authorized sending route and distinguish interface feedback, backend acceptance and actual receipt where applicable.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveProfile.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.