A polished form is not proof that a lead will arrive. The visitor may see an error; the message may go to an old mailbox; a spam rule may quarantine it; or nobody may own the follow-up. Treat the form as a small end-to-end workflow with a named recipient and a recorded test.
Test what the visitor sees
Submit the form on desktop and mobile using a real test email address. Leave required fields blank, enter a malformed email, then submit valid information. Confirm that labels identify the fields, error messages explain how to correct them, and success feedback appears only after the submission succeeds. The W3C forms tutorial explains why labels and usable feedback matter for accessibility as well as ordinary form use.
Check the privacy link, consent language, and file-upload rules if those are part of the agreed form. Do not silently collect extra personal information because a template included it. A visitor should know what they submitted and what to expect next, without being promised an instant reply unless the business can deliver one.
Follow the message through the system
Use a unique subject or phrase so the test is easy to find. Verify the recipient inbox, any CRM record, automatic acknowledgement, and relevant notification. Ask who checks spam or failed-delivery logs. If the form routes by service or location, test each route. A single test to the default address does not validate branching rules.
Ask the builder to show the form destination and any external service it depends on. Note which account owns that service, who receives billing or failure alerts, and what happens if it is disabled. If the business changes staff, the owner should be able to update the recipient without guessing where the configuration lives.
Record acceptance and after-launch ownership
Write down the test date, staging or live URL, browser/device, input used, expected destination, actual destination, and person who confirmed receipt. Repeat a short live test after DNS and hosting cutover; staging success does not prove production settings are identical. Do not publish real customer details in a public issue tracker while diagnosing failures.
If a form fails, identify whether the problem is front-end validation, the submission endpoint, email delivery, CRM integration, or internal handling. This prevents a design revision request from obscuring an operational issue. Put the correction owner and retest in the launch checklist.
ARCHV’s website service page says agreed forms are checked, but CRM routing, marketing automation, and ongoing monitoring depend on the project scope. If you are comparing proposals, use the website quote review to ask what “working form” includes and who owns the recipient account.
After launch, designate a person to repeat the test when the website, email provider, or CRM changes. Keep a fallback contact method visible so a form failure does not make the business unreachable. A successful form submission is a technical event; a lead only becomes useful when the team sees it and responds. That operational handoff deserves a place in the website launch plan.