Your working checklist
- Can a real visitor complete and submit the form?
- Did the provider accept the test?
- Was it marked for spam review?
- Does the right form have the right notification?
- Can the business find the actual email?
- Did the CRM or next owner receive the context?
- Does the page report errors honestly?
1. Reproduce the problem with a fictional inquiry
Use the published page on a phone and a desktop browser. Try an ordinary valid inquiry and note the time, page and result. Use a business test address you control, not a customer’s information. Describe what failed precisely: the button did nothing, an error appeared, the confirmation page opened, or the owner received no notification. Those symptoms point to different parts of the system. Test after a relevant change as well as before a redesign.
2. Check the browser and submission route
Confirm that required fields can be completed, labels are understandable and the submit action is reachable on a small screen. Check visible errors and whether the form sends to the intended destination. A custom script should handle rejection honestly and retain the answers for a retry. A design that opens a confirmation page without checking acceptance can make a broken process appear healthy. Development previews and production hosting may also process submissions differently.
3. Find the submission in the form provider
Look in the actual provider account for the test at the recorded time. If there is no accepted record, focus on the website-to-provider route. If a record exists, inspect its status and captured fields before changing the page. Provider spam checks may place an entry in a separate review area. On Netlify, notifications can be configured for verified submissions to a specific form or all forms; provider acceptance and inbox delivery are separate checkpoints.
4. Check notification scope and recipient settings
Verify the recipient, selected form and notification type. A newly named form may not be covered by a notification attached to an older one. Check whether a webhook or connected service is enabled and which event it expects. Inspect the provider’s result where available. Do not keep resending the same inquiry blindly: determine whether a retry can duplicate a CRM task, email or owner alert. A test should have an identifiable reference so the stages can be matched.
5. Check the mailbox and sender configuration
Search the receiving mailbox, junk folder and relevant message rules. For custom email sending, use the authorized sender and the email provider’s authentication guidance; do not treat the visitor’s address as a sender you control. Microsoft describes SPF, DKIM and DMARC as complementary email-authentication standards. Ask the administrator to inspect actual delivery evidence and the current domain configuration. Turning off mailbox protections is not a sensible substitute for fixing an incorrect sender or route.
6. Verify downstream ownership and notifications
A received email can still sit unread. Identify who reviews the inquiry and what happens when that person is unavailable. If the route includes a CRM or private notification, inspect the resulting fields and the next owner. Repeated delivery should not generate repeated customer follow-ups without an explicit reason. Preserve the useful business context, but avoid copying unnecessary personal information to extra destinations. An internal receipt is evidence of delivery, not evidence of a qualified opportunity or sale.
7. Keep a small acceptance checklist after launch
Test required fields, a realistic message, a long message, a rejected request and the confirmation path. Check the provider entry and the receiving inbox or workflow. Repeat after changing the form, integration or notification configuration. Agree on who notices failures and how they are investigated. Puzinski’s own website inquiry-system example shows a clearly labeled walkthrough of a working implementation; a separate project can assess the route used by your business.