Find lead forms that report success without creating an inquiry

Separate appearance from acceptance

A thank-you message does not prove that an inquiry was stored or delivered. Some forms display success after a button click while an integration fails in the background. Others create a record but never notify the responsible team.

Define the system's success boundary. Ideally, the visitor receives confirmation only after the receiving service accepts the request. Internal assignment and notifications may happen later, but failures there still need monitoring. Write down each stage rather than treating form completion as one indivisible event.

Follow a recognisable synthetic submission

Use an approved test address and unique reference in the inquiry text. Observe browser feedback, network response, stored record, routing outcome and acknowledgement. Avoid putting real personal information into debugging screenshots or analytics parameters.

W3C recommends clear feedback about successful completion and errors. Its validation guidance also notes that client-side validation alone does not ensure security. A friendly interface must not replace server-side checks or conceal a rejected request.

Run a failure-path worksheet

Test normal submission, invalid input, a controlled server rejection and a permitted integration-failure scenario. Coordinate disruptive tests with the technical owner and use staging where appropriate. Record whether the visitor can retry without re-entering everything or creating confusing duplicates.

Compare any analytics completion event with the actual acceptance point. If the event fires on click, rename or change it so reporting does not describe an attempt as a received inquiry. Keep operational monitoring separate from consent-dependent analytics.

• Success appears only after the defined acceptance condition.
• Rejected submissions provide a clear recovery action.
• Accepted requests create a traceable record.
• Notification failures reach an operational owner.

Repair feedback and reconcile affected periods

Fix the earliest incorrect assumption in the chain. Changing only the thank-you wording will not restore lost routing; changing only the integration will not stop misleading success messages on future failures. Retest both normal and failure paths after release.

Document the period during which reported completions may not represent received inquiries. Use available operational evidence to estimate the scope, without claiming records exist when they cannot be recovered. Give sales a verified list of recoverable requests rather than an inflated dashboard count.