What should a website contact form ask?

Start with the next step, then choose the fields

A contact form often grows one reasonable-sounding question at a time. Phone number. Company size. Full address. Budget. Where did you hear about the business? Before long, a visitor needs to assemble a brief just to start a conversation.

For each question, finish this sentence: “This answer helps us decide…” If the answer changes who handles the request, whether the work is a fit or what the first reply should say, it may belong. If it only becomes useful after an agreement, save it for that stage.

This follows the GOV.UK Design System’s question-planning guidance: understand why each piece of information is needed and make optional answers clear. A short inquiry form and a detailed application have different jobs. Their questions should reflect that difference.

For a new project inquiry, the immediate job is usually to understand the request and make a useful reply. A complete specification can come later.

• Ask now when an answer determines the next action: what the request concerns and how to reply.
• Make it optional when it helps but a useful conversation can still begin without it: a preferred launch month or an existing website link.
• Ask later when it belongs to delivery or onboarding: account access, a complete content inventory or a detailed specification.

Keep passwords and payment details out of a general inquiry form. If the work later needs sensitive information, arrange an appropriate way to collect it at that stage.

A worked example: six questions with a purpose

Consider a fictional website-project inquiry form. The business needs to distinguish new builds from improvements, understand the goal and know how to reply. The following questions are a starting point to adapt, rather than a universal template.

That is five questions on the ordinary path and one additional question when relevant. The useful part is the reasoning behind the fields, not the total. A repair request may need a location; an illustration inquiry may need a format. Neither is automatically necessary for a website project.

A phone number can be optional when email is enough to begin. A budget question can help if it changes the proposed scope, but give people a truthful way to say that they have not decided. Avoid requiring an invented answer just to reach the Send button.

Make each question easy to understand and answer

Use the visitor’s language. “What should the website help people do?” is easier to approach than “Describe your functional requirements.” Help text can offer two or three examples without turning the field into a checklist of everything a project might include.

Keep labels visible while someone types. Placeholder text can disappear as soon as an answer begins, so it should not carry the only explanation of a field. The W3C’s form-label guidance also explains why a label must be associated with its control in the page’s markup.

Group related questions under plain headings, such as “About the project” and “How to reply.” Mark optional fields clearly. If a specific answer format matters, explain it before submission and give a useful correction when it is wrong.

Error messages also need to be connected to the affected fields and available to assistive technology. For several errors, a clear summary with links to the relevant fields can help someone work through the corrections. The W3C’s guidance on form notifications explains these patterns.

Separate an answer that needs correcting from a service failure. If delivery is unavailable, changing a valid email address will not solve it. Explain the problem, preserve the entered answers where practical and provide a supported next step.

Try the example in the Form & Intake Planner

The free Form & Intake Planner lets you arrange questions, try conditional sections, map delivery and export a specification before building the working form.

Download the example plan (.json) to edit it in the planner. For a readable copy without opening the tool, download the build brief (.md). Both files contain the fictional questions above, with no submitted answers.

1. Import the example. Save any plan you are already working on. Choose “Import plan JSON,” select the downloaded file, then choose “Replace current plan” when the replacement notice appears.
2. Review the questions. The example has three sections: project details, an existing website and contact details. Change the labels, help text and required choices to fit the first response your business needs to make.
3. Try each path in the preview. Choose “New website,” then “Improve an existing website.” The website-address section appears only for the second choice. “Not sure yet” leaves it hidden.
4. Check corrections and confirmation. Select “Test confirmation” with required answers empty. Then enter fictional answers and an email such as name@example.com to try the completed path. Previewing sends nothing.
5. Plan delivery and follow-up. Add each answer’s destination field, then open “Delivery and follow-up” to name the receiving system, response owner, storage decisions and recovery steps. The downloaded example leaves these business-specific decisions blank. Add a failure message and choose “Delivery problem” under “Preview outcome” to rehearse it.
6. Keep delivery checks separate from the preview. Use the checklist to record results from the working form after implementation. Leave untested checks at “Not checked”; the planner does not run them or mark them passed.
7. Save a handoff and an editable copy. Under “Export format,” choose “Markdown build brief (.md)” for a readable specification or “Reusable form plan (.json)” to continue editing later. Use the matching Download button.

The planner keeps its work in the current browser tab and does not autosave. Download your JSON before closing it. Both exports include questions, help text, conditions, messages, destination mapping, handoff decisions and your recorded test results. Preview answers are excluded.

One conditional section is enough for this example. Test what happens when someone changes their first answer: the planner clears answers in sections that become hidden. Specify and test the intended behavior in the finished form too.

Plan what happens after Send

A form is part of a process. Add these decisions to the build brief alongside the field list:

• Destination: the inbox or system that receives the inquiry, and the person responsible for checking it.
• Acceptance: the step that makes the request safely received, and what happens if an email notification or later task fails.
• Reply: how the business responds and what the confirmation can accurately promise.
• Storage: what is retained, who needs access and when old inquiries are removed.

Show a success message only after the submission has actually been accepted. Explain the next step and include a reply timeframe only when the business can support it. The GOV.UK confirmation-page guidance offers useful questions to consider about what happens next and how someone can get help.

The receiving system needs its own checks. As MDN’s form-validation guide explains, browser checks can help people correct their answers, but they do not replace validation on the server.

If the form passes an accepted inquiry to another system through a webhook, verify that the receiving workflow finishes as intended. A message being accepted by one system does not establish that every later notification or task succeeded.

Record these decisions in the planner’s handoff section and assign an owner to unresolved work. Connecting email or another destination, preventing spam, enforcing retention and testing delivery happen in the implementation. The saved plan describes that work; it does not configure it.

Check the finished form before sharing it

Use the plan to guide these checks on the working website. A successful planner preview cannot establish that the live form receives or delivers anything.

• Try a phone-sized screen. Read every label, enter a longer answer and check that the buttons and errors remain usable.
• Use only the keyboard. Follow the focus indicator through every control and complete the form without a mouse.
• Make ordinary mistakes. Leave a required field blank and enter an incomplete email. Confirm that corrections are clear, focus can reach the affected field and the other answers remain intact.
• Try every branch. Change an earlier answer after filling a conditional section. Check that hidden fields do not block submission or send unintended details.
• Follow an actual test inquiry. Use fictional information to check the receiving system and intended destination. Verify both success and failure handling; a visible thank-you message alone is insufficient.
• Review the next step. Make sure the confirmation matches the actual response process and provides a useful contact option when appropriate.

Start with the questions needed for one useful reply. Add detail when there is a clear reason, and give the delivery process the same attention as the visible page.

For help turning a plan into a working inquiry process, explore Plainview Web’s forms and workflows service.