How do you test an inquiry flow and verify a website fix?

Prepare an isolated inquiry path

Use an owned test or staging subdomain and a flow that cannot create a real booking or send a customer message. The current runner accepts test.your-domain and staging.your-domain over HTTPS. It blocks requests to other origins, so production integrations and external assets may not behave as they do on the live site.

The form must have id agenttracking-test-form, data-agenttracking-test=true, fields named name, email and message, and a submit button. Set data-agenttracking-success=true on a result element only after the test inquiry is saved. The task-test documentation explains the current runner.

Capture the baseline

Open Tests in the private workspace and run the prepared path. Save its run ID, result, error class and available release, tool and schema versions. A missing form marker is a failure of this test contract; it does not prove that an AI assistant could not find the live form.

The runner uses fixed synthetic values and has a short execution deadline. It does not choose its own strategy or measure the behavior of ChatGPT, Claude or another external model.

Document a specific correction

Create a finding linked to the baseline run. Describe the observed failure and the change, and assign responsibility if needed. Keep the proposed cause separate from what the test actually observed.

For example: the staging endpoint saved the test inquiry but the page never exposed the success marker. Correcting that marker improves the test contract. Do not report this alone as a recovered customer inquiry.

Run the same task after the change

Run the same task against the same URL and test mode. Record the new version, then link the before and after runs under Fix and retest. If test conditions differ, the comparison is shown as changed conditions rather than a controlled retest.

A comparable failed-to-passed pair is retained in Insights under Findings & fixes. Each comparison contains one run per state. Repeat checks as needed, and keep any production outcome measurement separate.

Confirm business outcomes separately

For real inquiries, integrate server outcome receipts after a durable save. Use stable receipt IDs for retries and explicit links to the originating attempt or invocation where available. A browser click is not a confirmed inquiry.

A server-reported actor and an independently verified crawler identity are different forms of evidence. Preserve those distinctions when presenting the result to a client.

Share the result in context

Add the fix and retest to the finding and share the protected site report. The recipient can review the original issue, correction, actual runs and remaining uncertainty. Public statistics do not expose these internal records.

Use the GEO/AEO measurement playbook to connect this check to a wider measurement plan. Connect your website to start a private workspace.

In short