Why an enquiry form needs more than a submit button

Define success beyond the click

On this website, I did not treat a success message as the end of the form test. We sent a clearly labelled test through the project inquiry form and another through the teardown form, then confirmed that both notification emails arrived. That is the distinction I want this checklist to make: a visitor-facing confirmation and an inbox receipt are two separate things to verify.

Ask for enough information to take the next step

Choose fields by what the team needs to decide after reading the enquiry. A project form may need contact details, the type of work, and a short description. A website review needs the site URL. A new business may not have a website yet, so making that field required everywhere can exclude a relevant lead. Explain optional fields and give examples that clarify the expected answer. Keep labels visible instead of relying on placeholder text that disappears when someone starts typing.

Validate in a way that helps someone recover

When a field needs correction, explain the issue and how to fix it. Keep the visitor’s other answers intact. A useful message says “Enter an email address such as name@company.com,” rather than “Invalid input.” Browser validation helps catch mistakes, but the receiving service also needs suitable validation because client-side checks can be bypassed. Make error messages available to assistive technology and connect field-specific guidance to the field. Test the form with a keyboard as well as a pointer.

Make sending and uncertainty visible

While a request is in progress, prevent repeat submissions and show a clear sending state. Only show the accepted confirmation after receiving an accepted response. If the connection drops before the response arrives, the request may already have reached the service. Do not confidently say it failed or encourage repeated clicks. Explain that delivery could not be confirmed, preserve the details, and provide a way to contact the business. That distinction helps avoid duplicate requests while giving the visitor a practical route forward.

Give the confirmation a useful next step

Confirm what was submitted and where the reply will go. State what your team will do next without inventing a response-time promise. A project enquiry is not automatically a booking, and a request for a free review does not automatically reserve capacity. Where useful, offer a calendar link or a relevant page to read. If a form only prepares an email draft, say that clearly: the visitor must still open their email app and send it. A prepared draft must never be described as an accepted submission.

Assign notification and reply ownership

Choose the destination inbox, the person who watches it, and the backup when that person is unavailable. For a service such as Formspree, inspect the notification workflow rather than assuming the form’s existence guarantees email delivery. Its email field can supply the visitor’s reply address when named correctly. Separate different enquiry types when that makes routing clearer. On this site, project enquiries and teardown requests have separate configured endpoints. That configuration explains the intended routing; actual inbox receipt still needs a real test.

Keep spam protection compatible with the experience

Honeypots and provider filtering can reduce unwanted submissions, while challenge-based protection may require an additional browser integration. Formspree supports a honeypot named _gotcha; submissions that populate it are silently ignored. Do not fill that field in a legitimate test. If a CAPTCHA or domain restriction is enabled, test with the final public domain and the actual form implementation. Do not remove protection simply to get a green test result. A blocked legitimate request should produce a useful recovery path rather than an unexplained dead end.

Run a test that reaches the inbox

• Use a real email address you control and mark the message clearly as a delivery test.
• Submit through the published form once, including representative optional fields.
• Check that the accepted state shows the expected name, email, and next step.
• Find the matching submission in the provider dashboard, using a unique test marker.
• Confirm the notification reaches the intended inbox and inspect spam if it does not.
• Check that replying targets the visitor and that URLs, selected options, and source-page details are usable.
• Repeat for each distinct form, and repeat relevant checks after changing a domain, endpoint, inbox, or spam setting.

Keep a lightweight operational check

Record which form was tested, when it was tested, who checked the inbox, and any unresolved issue. Decide on a review frequency that fits how important the form is to your business and how often the website changes. Automated interface checks are useful, but they do not read your team’s inbox or prove that someone responds. No-Code Dev can help review the whole enquiry journey, including the handoff between the website, form service, and your team.