Form Testing & Lead Routing

Overview

What this task involves

A four-phase workflow that proves every contact form on the client's site actually delivers leads. Phase 1 audits the site setup. Phase 2 inventories every unique form. Phase 3 tests each form end-to-end with a unique marker, screenshots, and log evidence. Phase 4 retests every failed form after fixes are applied.

The output is a completed Google Sheet (4 tabs) and a short handover report for Melbourne. The sheet is the source of truth. The report is a summary Melbourne can act on without reading every row.

Why it matters

Form failure is the most damaging silent failure in client SEO work. We can rank a client #1 for every keyword they care about — and if their contact form sends to [email protected], they will fire us. We've seen it happen.

The rule "IM got the email does not count" exists because we have historically marked forms as working off our own notification — and the client got nothing. This workflow exists to prevent that from ever happening again.

When to run this task

Pre-launch — before any new site or significant rebuild goes live. No exceptions.
Post-migration — after any CMS migration, hosting change, or email provider change.
Post-change — after any change to form plugins, SMTP settings, CRM integrations, or DNS records.
Quarterly spot-check — Premium tier clients. One randomly selected form fully re-tested each quarter.
After a client reports missing leads — this is the first task to run in any lead-loss investigation.

The four silent-failure classes this workflow covers

DNS authentication failure — forms submit, server sends, but the receiving mail server quarantines or drops the message because SPF/DKIM/DMARC don't align. The form looks fine in every log. Nobody knows leads are missing.
Autoresponder missing — the submitter doesn't receive a confirmation, assumes the form didn't work, and re-submits or goes to a competitor.
Tracking not firing — the form delivers leads perfectly but GA4 / GTM doesn't record a conversion event, so the client's reporting shows zero conversions. We get blamed.
Fix not actually fixed — without a verified re-test, fixes ship untested. Half-fixed forms are worse than known-broken forms because they look closed on the sheet.

Workflow ownership

Hanoi runs Phases 1–3 and performs all re-tests in Phase 4. Melbourne owns client confirmation, CRM integration sign-off, and final close. The process is only complete when Melbourne confirms the lead path with the client — not when Hanoi ticks a row.

The Pass / Fail Rule

This rule is non-negotiable. It applies to every form, every time.

PASS — all four conditions met

Client receives the test email in their inbox
Dispatch evidence is captured (mail log, SMTP log, Flamingo, or CRM record)
Conversion event fires in GA4 / GTM (if tracking is configured)
Autoresponder reaches the submitter's email (if the form is configured to send one)

FAIL — any of these conditions

Email goes to IM, the developer, an old agency, or nobody
No dispatch evidence can be captured
Conversion tracking is silent when it should fire
Autoresponder is missing when it should exist

"IM got the email" does not count as a pass. Ever. The internal IM notification is incidental — the question is whether the client got the lead. Mark any test where only IM received the email as a FAIL.

Evidence is mandatory: Every test row must carry screenshots and log entries. No "trust me, it works" entries. SPF / DKIM / DMARC must be checked and recorded even if all forms pass — the absence of DMARC is a recommendation Melbourne raises with the client.

Phase 1 — Site Audit

Document the site stack

Open the client's site and record each of the following in the Site Audit tab:

Who built the site — Integral Media, the client, or a third-party developer. This determines who can fix issues.
CMS and version — WordPress, Squarespace, Webflow, Shopify, custom build, etc.
Active form plugins — Contact Form 7, Gravity Forms, WPForms, Elementor forms, etc. Note the version if visible in the plugin list.
SMTP plugin and sender domain — WP Mail SMTP, FluentSMTP, SendGrid, Mailgun, etc. Note the "from" address configured in the plugin settings.
Database storage — does the form plugin save submissions to the database? Critical for Contact Form 7, which does not save by default. Record whether Flamingo or an equivalent is installed.
External form embeds — any forms loaded from GHL, Zoho Forms, HubSpot, Typeform, JotForm, etc. These bypass the CMS email system entirely and route through the external provider.
Spam protection — Akismet, reCAPTCHA v2/v3, Cloudflare Turnstile, honeypot fields. Note what's active.

Check DNS authentication records

Use mxtoolbox.com or dmarcian.com to check the sender domain's DNS records. Record all three in the Site Audit tab:

SPF (Sender Policy Framework) Specifies which mail servers are authorised to send on behalf of the domain. Must include the SMTP provider being used (e.g. SendGrid, Mailgun, Google Workspace). Record: Pass / Fail / Missing.

DKIM (DomainKeys Identified Mail) A cryptographic signature that verifies the email wasn't tampered with in transit. Must be published and aligned with the SMTP provider. Record: Pass / Fail / Missing.

DMARC (Domain-based Message Authentication) Tells receiving mail servers what to do with emails that fail SPF or DKIM. Record: Policy (none / quarantine / reject) / Missing. Even a "none" policy is better than missing.

Misalignment between the SMTP "from" address and the domain's SPF/DKIM record is the single largest cause of "form submits but no email arrives." Document this clearly — it is the first thing to investigate in any failed form test.

Note any unusual setup or risk flags

Before moving to the form inventory, record anything unusual that the tester or Melbourne should be aware of:

Forms on a staging subdomain that are still active on the live site
Recipient addresses using a free email provider (Gmail, Hotmail) — these have aggressive spam filters and may reject SMTP-sent emails
SMTP provider not matching the domain's DNS records — flag as high risk
Contact Form 7 without Flamingo — form submissions are not stored; a failed email means a lost lead with no recovery option
Any known previous issues with form delivery mentioned in Zoho history

Phase 2 — Form Inventory

Find every unique form on the site

Browse the site systematically — homepage, contact page, each service page, the footer, any landing pages. For each unique form, record one row in the Form Inventory tab with:

Form name A descriptive name you assign — e.g. "Contact Page Enquiry", "Footer Quote Form", "Blog Sidebar Email Signup"

Plugin / source Contact Form 7, Gravity Forms, GHL embed, Zoho Forms, etc.

Form ID The plugin's internal ID (visible in the plugin settings or in the page source). This helps identify the form if its appearance changes.

Recipient email address Where the notification email is configured to go. Check the form plugin settings — do not assume it goes to the client.

Deployment scope Where on the site the form appears — "Contact page only", "Sitewide via footer widget", "Homepage hero section"

File upload Yes / No — forms with file uploads need an additional test step

Linked CRM Any CRM the form feeds into — Zoho CRM, HubSpot, GHL, etc.

Notes Anything unusual — custom redirect on submit, multi-step form, conditional logic, etc.

Verify recipient addresses before testing

Before running any test, open each form's plugin settings and confirm where the notification is configured to go. Do not assume — check it. Record the configured recipient address in the inventory.

If the recipient address is anything other than the client's own domain (e.g. it's going to an IM address, an old agency, or a developer's email), flag this immediately in the inventory and notify Melbourne before testing. Do not run a test that will send a lead to the wrong recipient without Melbourne being aware.

Phase 3 — End-to-End Test

Prepare before each test

Create a unique marker for this test — e.g. TEST-CONTACT-001 @ 14:30. The date and time makes each submission uniquely identifiable in logs.
Use a hygienic test email address — [email protected]. Using the + alias means replies and autoresponders go to a trackable address.
Open GA4 DebugView (go to GA4 → Configure → DebugView) and GTM Preview in a separate browser tab. Keep them visible during the test.

Run the 13-step test for each form

Work through these steps in order for each form. Record the result at each step:

Screenshot the form before filling it in — shows the form's state at time of test
Fill in every field with realistic test data. Include the unique marker in the message field or name field.
Screenshot the filled form before submitting
Submit the form
Screenshot the result — success message, redirect page, or error state
Record the post-submit behaviour (success message text, redirect URL, no-feedback/broken)
Check the configured recipient inbox — screenshot showing the test email arrived. Note the timestamp.
Capture dispatch evidence — mail log from SMTP plugin, Flamingo record, mail server log, or CRM entry. At least one evidence source is required.
Verify the autoresponder — check the test email address ([email protected]) for a confirmation email from the client's site. Screenshot it if it arrives. Note "No autoresponder configured" if the form doesn't send one.
Verify conversion tracking — confirm the form submit event fires in GA4 DebugView or GTM Preview. Screenshot the event firing. Note "No tracking configured" if GA4 / GTM are not set up for this form.
Test file upload if the form has one — upload a small test file. Confirm it is received by the recipient and stored if applicable.
Mark PASS or FAIL using the rule on the Pass/Fail tab. A form passes only when all four conditions are met.
Add any notes or flags for Melbourne — recipient address concerns, CRM sync issues, autoresponder wording that needs updating, etc.

Unique marker convention: Use the format TEST-[FORM-ID]-[NNN] @ [HH:MM]. Example: TEST-CF7-001 @ 15:42. The marker must appear in the notification email so you can match the inbox screenshot to the test log row without ambiguity.

Spam filters: If the test email doesn't arrive in the recipient's inbox within 5 minutes, check the spam / junk folder before marking as FAIL. Screenshot the spam folder if the email is found there — it still counts as a FAIL (the client won't check spam for leads), but the failure reason is different from a total non-delivery.

Phase 4 — Retest & Sign-Off

For each FAIL: log the fix

In the Test Log tab, add a "Fix log" row beneath the FAIL row. Record:

The root cause — what was actually wrong (e.g. "Notification email was configured to send to [email protected]")
What was changed to fix it — with enough detail that it's verifiable (e.g. "Updated recipient address in CF7 settings to [email protected]")
Who made the change — Hanoi (if we have access) or developer / Melbourne (if not)
Date and time the fix was applied

Re-run the full 13-step test for each fixed form

Do not assume a fix worked without re-testing. Re-run all 13 steps for the fixed form, using a new unique marker (e.g. TEST-CONTACT-001-RETEST @ 16:15) to distinguish the retest from the original failed test.

Record the retest results in a new row in the Test Log. If the retest passes, mark the retest row as PASS and add a "Fixed" status to the original FAIL row.

If the retest still fails, log the new failure, flag to Melbourne, and begin a new fix cycle. Do not close the row until it passes.

Get client sign-off for each fixed form

Melbourne must confirm with the client that the lead path is working from their perspective. This means:

The client or their designated contact receives a test submission from Melbourne (not just our internal test)
Melbourne records who confirmed receipt and when — this goes into the sign-off line in the Test Log
Test entries are deleted from the CRM after sign-off so they don't pollute lead pipelines

The task is not closed until the sign-off line is in the sheet. A form that Hanoi has re-tested and marked PASS but not yet confirmed with the client is still open.

Close criteria: Every form in the inventory has a PASS in the Test Log with a sign-off line, or has an open Melbourne flag with a clear action owner. No form remains in FAIL state at close. Test submissions removed from the client's CRM.

Handover Report

Write a short summary report for Melbourne alongside the completed Google Sheet. This is what Melbourne uses to brief the client and plan any follow-up work.

Write the handover report

The report should be one page maximum. Include:

Overall status "X of Y forms passed. Z forms failed and have been fixed. [N] forms have open flags requiring Melbourne action."

Pass/fail summary table Form name | Result | Notes — one row per form.

Failed forms detail For each FAIL: what failed, the root cause, what was done to fix it, and whether it has been re-tested and confirmed.

DNS authentication findings SPF / DKIM / DMARC status for the sender domain. Flag any missing records as a recommendation for Melbourne to raise with the client, even if all forms passed.

Tracking findings Which forms have conversion tracking configured and whether it is firing correctly. Flag any forms without tracking as a gap.

Melbourne next steps Explicitly list what Melbourne needs to do — client confirmation calls, CRM cleanup, developer work, DNS record additions.

Save and share

Save the Google Sheet and the handover report to the client's Drive folder. Add a Zoho comment with the link to the sheet and a one-line summary of overall status. If any forms have open issues, flag them explicitly in the Zoho comment — do not leave Melbourne to find them by reading the sheet.

Standards Checklist

The task is complete when every item below is ticked.

Phase 1 — Site Audit

CMS, form plugins, and SMTP plugin documented

Database storage status noted (especially for CF7 — is Flamingo installed?)

SPF, DKIM, and DMARC records checked and recorded for the sender domain

Any DNS misalignment or high-risk setup flagged

Phase 2 — Form Inventory

Every unique form on the site listed — one row per form, not one row per page

Configured recipient address verified in plugin settings for each form

Any incorrect recipient addresses flagged to Melbourne before testing

Phase 3 — End-to-End Test

All 13 steps run for every form in the inventory

Unique marker used for each test submission

Screenshot of filled form, post-submit state, and recipient inbox for each test

Dispatch evidence captured (mail log, SMTP log, Flamingo, or CRM record)

Autoresponder verified (or "not configured" noted)

Conversion tracking event verified in GA4 DebugView or GTM Preview (or "not configured" noted)

Every form row marked PASS or FAIL using the non-negotiable rule

Phase 4 — Retest & Sign-Off

Root cause documented for every FAIL

Full 13-step retest run for every fixed form — new unique marker used

No form remains in FAIL state at task close

Melbourne sign-off line in the sheet for every fixed form

Test submissions removed from the client's CRM

Handover

Google Sheet (4 tabs) saved to client's Drive folder

Handover report written with overall status, failed form detail, DNS findings, tracking findings, and Melbourne next steps

Zoho comment added with Drive link and status summary

Any open Melbourne flags explicitly noted in Zoho — not buried in the sheet

Common Mistakes

Mistake	Why it's a problem	What to do instead
Marking a form as PASS because IM received the email	This is the exact failure mode that this workflow was created to prevent. We have lost clients over this. IM's internal notification is not a lead delivery confirmation.	The PASS condition is that the client receives the email. Check the configured recipient address in the form settings and confirm it is the client's address before testing.
Testing without a unique marker	If two test submissions look identical in the logs, you cannot be certain which inbox screenshot matches which test row. Evidence becomes ambiguous.	Always include the unique marker (e.g. `TEST-CONTACT-001 @ 14:30`) in the message field or name field. Every test is uniquely traceable.
Closing the sheet after Hanoi's retest without Melbourne sign-off	Melbourne and the client haven't confirmed the lead path. The fix may have worked in a test but still not be delivering leads for real reasons (CRM routing, spam filters on the client's mail provider, etc.).	The sign-off line in the sheet requires Melbourne to confirm with the client. Hanoi cannot close a FAIL row — only Melbourne can.
Not checking DNS records because all forms passed the basic test	SPF/DKIM/DMARC failures don't always show up in test conditions — some mail servers only enforce DMARC for bulk volume, not single test emails. The issue can emerge at scale or with specific receiving mail providers.	Check and record DNS authentication status regardless of test outcome. A missing DMARC record is always a recommendation for Melbourne, even if forms are passing.
Listing the footer form once per page it appears on	A single form that appears on 50 pages generates 50 inventory rows and 50 test rows — all for one form. This inflates the workload and creates confusion.	List each unique form once. The "Deployment scope" field documents where it appears on the site.
Leaving test submissions in the client's CRM after sign-off	Test leads pollute the client's pipeline, affect conversion rate reporting, and create unnecessary follow-up work for the client's sales team.	Delete all test entries from the CRM as part of the Phase 4 sign-off process. Confirm deletion in the Zoho comment.