Separate a Form Attempt from a Completed Request

A form attempt records an interaction, such as pressing Submit. An accepted request means the receiving system validated and recorded the submission. A qualified lead is a separate business judgment. Keep these states distinct so a failed validation, a page reload or a spam submission does not become a claimed customer opportunity.

Define the Two States in Your System

Write a definition for each state and identify the system that can substantiate it. Browser interactions describe attempts; a receiving-system acknowledgment or stored record supports receipt. Staff or an agreed qualification process determine whether the request fits the services offered.

Do not require the visitor to read a confirmation email before acknowledging that a request reached your system. Conversely, a confirmation screen shown before successful receipt is not proof that the system saved anything.

• Attempt: defined visitor action, with its limits recorded
• Accepted request: verified receipt in the receiving system
• Qualified lead: a separate service-fit decision, not an analytics label

Map the User Journey and Capture Events

Map where validation, storage, receipt confirmation and follow-up occur. Have the implementation owner explain the success and failure signals. Record duplicate-handling rules and distinguish repeat page views from separate submissions.

Avoid sending personal contact details into analytics. Use only the identifiers and event fields approved for that implementation; the business record and reporting record need not contain the same data.

• Identify the receiving system and its success response
• Document what happens if receipt succeeds but the confirmation screen fails
• Document which records can and cannot be reconciled

Worksheet for Daily Review

Use a blank reconciliation sheet instead of assuming that every attempt must become a completed request. Some visitors stop, some submissions fail validation, and some recorded interactions cannot be matched. A difference is a question to investigate, not proof of lost revenue.

• Period and time zone
• Attempt definition and count
• Accepted-request definition and count
• Available matching evidence
• Duplicate and spam handling
• Unmatched records and known measurement gaps
• Issue owner and next verification step

Edge Cases to Watch

A visitor may close a tab after the server accepted the request but before the confirmation renders. Check the receiving record before classifying the outcome. A repeated submit action may create one accepted record or more; confirm the implementation instead of guessing.

A thank-you URL may be opened directly or reloaded. Those visits are not necessarily new submissions. A received request can also be spam or outside scope; that affects qualification rather than whether receipt occurred.

Next Action Checklist

When you finish the worksheet, follow this short list to close any gaps.

For help connecting the page, the request and the follow-up, review WeLead Lab’s website conversion service and working process. Confirm the scope that applies to your business before changing a live customer journey.

• Confirm the documented receipt signal
• Verify success, validation failure and retry behavior using an authorized test environment
• Keep QA records distinguishable from customer requests
• Give unresolved mismatches an owner and retain the evidence