DIRECT ANSWER
Submit an authorized test inquiry and verify what happens in the browser, the receiving system and the agreed inbox or work queue. Check invalid input and failed submissions as well as success. A confirmation screen alone does not verify the entire delivery and follow-up path.
Know where the inquiry is supposed to go
Write down the form's destination before testing. Identify whether the request is stored in a form service, delivered into a CRM or handled through another approved system. Name the person responsible for responding and the place that person checks.
Storage and notification are different checkpoints. A request might be present in the receiving system even if its email notification is missing. Inspect the actual record before concluding that nothing was submitted.
For Netlify-hosted forms, Netlify's setup documentation explains build-time form detection and submission handling. That is platform-specific behavior, not a universal requirement for every website.
Run one normal submission all the way through
Use a clear test label and a contact address you control. Avoid real customer data. Record the time and page so the test can be matched to the received record.
| Checkpoint | What to verify |
|---|---|
| Form access | The intended page opens and fields are usable |
| Submission | A valid request is accepted by the actual handler |
| Confirmation | The visitor sees accurate completion or error feedback |
| Receiving record | Submitted details are present in the intended system |
| Notification | The agreed inbox or work queue receives the notice |
| Response ownership | The responsible person can retrieve and act on it |
This is an SIS test sequence. It is not a claim that every platform has identical storage or notification behavior.
Manual test worksheet
Work through the checkpoint table above, plus an invalid-input test and a controlled failure test, and record the result of each.
Check the unsuccessful paths
Leave a required field empty. Enter a clearly invalid email format where email is required. Confirm that the message explains what needs correction and keeps the visitor's usable information where appropriate.
W3C recommends clear feedback for success and errors, including error descriptions associated with the affected fields. Its labeling guidance explains why controls need identifiable labels.
Ask the builder to test a failed network or handler response in a controlled environment. The page must not say “received” when acceptance is unknown. A retry should not silently produce multiple operational requests.
Test the way customers use it
Complete the form on a phone and with a keyboard. Verify labels, focus, required fields and the success/error state. If uploads are allowed, test the approved size/type boundaries without using sensitive files.
Keep the first inquiry limited to what is needed for the next response. If the business needs a more involved workflow, compare intake forms, assessments and calculators before adding questions.
Keep a short evidence record
Record the URL, date, test result, receiving record and unresolved issue. Recheck after a change to the form, hosting, handler or notification destination. A previous successful test does not prove a changed setup works today.
For reporting, count the accepted inquiry separately from the contact click. The lead-measurement guide explains that distinction.
Describe the form problem in your Project Brief, including the page and the last checkpoint you could verify.
Sources and method
W3C supports the accessibility and feedback guidance. Netlify supports the specific platform description. The end-to-end operational checklist is an SIS recommendation.
Sources verified October 10, 2026: