Give each demo field a clear purpose
Require work email, company and primary workflow only if they genuinely support the intended routing and preparation. Leave phone optional in this specimen and omit revenue without a demonstrated use. Each retained field must change a real downstream action enough to justify the effort of answering it.
Worked example — illustrative data.
| Field | Required in specimen? | Reason |
|---|---|---|
| Work email | Yes | Return the request and identify account context |
| Company | Yes | Route the business enquiry |
| Primary workflow | Yes; short choice plus free text | Prepare a relevant demonstration |
| Annual revenue | No; omit initially | No demonstrated routing need |
| Phone | Optional | Offer a contact preference without forcing it |
Write the downstream action beside every proposed field. If no one can name who uses an answer and what changes, remove it or move it to the conversation. Explain the next step at submit and provide a visible error beside the field needing correction. Do not ask for a password on a demo request. Review the actual data handling and required notices with the responsible owner before collecting personal information.
Justify required fields with a routing decision
For each field, write what the team does differently when the value changes. The fictional workflow question prepares the demonstration; annual revenue has no stated routing purpose and stays out. Test a legitimate buyer with a free-email address and a supported unusual company name. Required-field validation should not silently discard a suitable request because it does not match an assumption.
A free-email address does not establish an invalid request
A free-email address does not prove a request is invalid. If the business restricts form submissions, define a supported exception route so a legitimate buyer is not left with an unexplained rejection.
Use the smaller form until evidence shows a missing field prevents useful follow-up. Evaluate qualified requests and routing quality alongside completion, rather than treating more submissions as automatically better.
How many fields should the form have?
Use the fewest fields that provide the necessary review and reply context for this journey. A universal field count ignores qualification and setup differences. Test completion and downstream usefulness together rather than optimizing form length alone.
Continue with Guides for stores, software teams and local businesses, SaaS website design and development and Design a demo confirmation page.
For field-error identification and recovery, see the W3C WCAG quick reference.