Quick answer: Make a form field required only when you cannot make the next useful decision without it. Ask later when the detail is needed for delivery, and remove it when nobody uses the answer. The goal is a request your team can act on—not the shortest form at any cost, and not a customer census.
For: small service businesses designing an enquiry or quote-request form. This guide focuses on choosing questions; use our contact-page checklist for the whole page and delivery route. Examples below are fictional operating choices, not measured conversion results.
Jump to: Field decision table · Worked example · Acceptance tests · Decision record
- Start with the decision after submission
- Which enquiry-form fields should be required?
- Worked example: a local repair enquiry
- Budget questions need an honest next step
- Write questions a visitor can answer
- Handle unknown answers without breaking the workflow
- Six acceptance tests before publishing
- Judge the change by useful requests, not field count
- Copy this field decision record
- Useful detail: Keep the question visible after typing begins
- Sources and review date
Start with the decision after submission
Write down the first decision your team makes: reply with advice, check service coverage, assign a specialist, arrange an assessment, or offer an appointment. Then work backwards to the information that decision needs.
“It might be useful someday” is a weak reason to make a visitor stop and think. “We cannot tell whether we serve this area” is stronger. A question earns its place when somebody can name the action that changes because of the answer.
- Required now: without it, the next step cannot be taken reliably.
- Optional now: it helps preparation, but a blank answer has a workable route.
- Ask later: necessary for a quote or delivery, but not the first reply.
- Remove: no defined action depends on it.
These are Practical SaaS Lab’s planning categories. W3C’s forms guidance supports asking for information needed for the process; it does not prescribe a universal field count or this four-way decision method.
Which enquiry-form fields should be required?
Swipe the table sideways on a narrow screen. Treat each row as a starting question, not a rule for every business.
| Field | Require when | Otherwise |
|---|---|---|
| Email or phone | The chosen reply method needs it. | Avoid requiring both just because both fields exist. |
| Service type | It changes the responder or available route. | Use a short message if your services cannot be described by clear choices. |
| Service area | Coverage determines whether you can help. | Ask later; do not substitute a full street address without a reason. |
| Budget range | A real minimum changes the next step and visitors can answer meaningfully. | Allow “Not sure yet” with manual review, or discuss it after the first reply. |
| Target timing | A deadline determines availability or suitability. | Offer a flexible range rather than forcing an invented date. |
| Company and role | They determine eligibility or the right discussion. | Make optional or ask during qualification. |
| Attachment | The initial assessment genuinely depends on a document and a suitable upload route exists. | Request specific material later through the agreed route. |
| How did you hear about us? | Usually a reporting question, not an obstacle to replying. | Consider optional; keep self-reported source separate from observed traffic data. |
Worked example: a local repair enquiry
Imagine a small repair business whose first decision is whether it can assess the appliance in the customer’s area. This is a fictional workflow; it is not advice for an emergency service.
- Ask now: appliance type, service area, a short description of the problem and a reply address.
- Make optional: model number if the customer can find it easily.
- Ask later: full address and access instructions once the team agrees to arrange a visit.
- Remove from initial enquiry: company size and a mandatory marketing-source question.
“Not sure which model” is a valid customer state. Give the responder a manual follow-up route instead of forcing a fabricated answer. If the business really cannot triage without the model number, explain where to find it and offer a monitored alternative for people who cannot.
A consulting firm may make different choices. A useful first message might be the problem, current website URL if applicable, timing and one reply channel. Detailed access credentials, internal spreadsheets and a full project brief can wait. The worksheet should fit the work, not the other way around.
Budget questions need an honest next step
If you show budget bands, explain what happens to each answer. A minimum project scope may justify an eligibility question. It does not justify pretending every visitor knows the final cost before talking to you.
For example, “Not sure yet” could route to a short scoping conversation. A request below your minimum could receive a clear explanation and an appropriate alternative. If every choice triggers exactly the same reply and nobody reads it, reconsider why the question is required.
Do not use a required budget field to compensate for a service page that explains nothing about scope. Fix the offer description first. Our service landing-page guide explains how to define the offer before designing the page.
Write questions a visitor can answer
Use the customer’s words. “What do you need help with?” is easier to answer than “Select your solution vertical.” Keep persistent labels, clearly identify required or optional input, and give format instructions where the format matters. Placeholder text should not carry the entire explanation.
Compare “Preferred implementation commencement date” with “When would you like to start?” An estimated month may be enough for planning. If an exact date is essential, explain why and what happens when it cannot be met.
W3C describes associating labels with their controls and giving understandable feedback. Ask your implementer to check those associations and error announcements; a neat screenshot does not demonstrate an accessible form.
Handle unknown answers without breaking the workflow
A dropdown can look tidy while storing guesses. Add an honest unknown option when the team can investigate it. Define who reviews that option and how it affects assignment. Do not silently treat unknown as a qualified request or discard it as unsuitable.
Conditional questions can help when one service needs details another does not. They also add testing work. Verify that hidden questions stop blocking submission, relevant answers reach the responder, and changing an earlier choice does not send contradictory information.
If qualification leads to an appointment, follow the booking-link versus enquiry-form guide. Receiving a request is not the same as confirming a booking.
Six acceptance tests before publishing
- Minimum valid request: complete only required fields. Can the responder take the promised next step?
- Unknown answer: choose “Not sure.” Confirm that a person receives a clear review task.
- Incorrect input: submit a clearly labelled test with a missing required value. Check that the error identifies the field and explains the correction.
- Changed choice: switch service type. Verify that conditional fields and the received record match the final choice.
- Phone and keyboard: reach every field and button, read instructions and correct an error without losing your place.
- End-to-end delivery: trace one safe test request to its destination, assigned owner and reply. Exclude it from real-lead counts.
Use a controlled test arrangement so you do not create a real customer booking or trigger unwanted messages. If delivery fails, use the missing form-email checklist before sending more traffic.
Judge the change by useful requests, not field count
Record genuine received enquiries, enquiries with enough information for a next step, and the follow-up work needed to fill gaps. Keep spam, operator tests and duplicate submissions separate. Website events and inbox records are different observations; do not assume they match automatically.
In a fictional comparison, an old form receives 12 genuine requests and nine are actionable immediately. A revised form receives 15 and eight are immediately actionable. The second form has more submissions but creates more clarification work. These counts illustrate a trade-off; they do not prove that either design performs better.
Compare similar periods and traffic sources, note staffing or offer changes, and label small samples inconclusive. Removing a question may help, hurt or make no detectable difference. Decide using the work your team actually receives.
Copy this field decision record
- Question and plain-English label:
- Decision this answer changes:
- Required / optional / later / remove:
- What happens if blank or unknown:
- Responder and backup:
- Expected received value and test evidence:
- Review date and observed clarification work:
Start with one questionable required field. Find out who uses it, write the blank-answer route, and test the revised journey. One justified change is more useful than deleting half the form because somebody promised a magic number.
Useful detail: Keep the question visible after typing begins
W3C says placeholder text is not a replacement for a form-control label.
A short intake form can still be hard to finish when the only instruction disappears inside the field. Use the placeholder for an example, while keeping the actual question available.
Try this:
- Type an answer in every required field.
- Check that its question and any format instruction remain understandable.
- Trigger one harmless validation error and confirm the person can identify the field to correct.
Source: W3C WAI: form instructions and labels. Checked October 3, 2026. The practical check is a PSL suggestion.
Sources and review date
- W3C WAI: Forms Tutorial — focused forms.
- W3C WAI: Labeling Controls — label associations.
- W3C WAI: Form Instructions — required input and format guidance.
- W3C WAI: User Notifications — errors and feedback.
Sources checked September 30, 2026. The field matrix, fictional examples, workflow tests and review record are Practical SaaS Lab recommendations. This is not a product trial or a full accessibility audit.
