How do you check whether form submissions become qualified enquiries?

Use this guide to find where enquiries disappear, agree what counts as qualified and compare lead costs without mixing different outcomes.

Define each stage before testing it

1. Accepted enquiry: the server accepted a valid submission, rather than the visitor merely clicking a button.
2. Recorded enquiry: the intended CRM or inbox received the details once, with enough information to identify and follow up the request.
3. Qualified enquiry: a named person or approved process confirmed the agreed fit, such as service need and actual operating area.
4. Commercial outcome: the business recorded the next meaningful result, such as an appointment, accepted proposal or paid order.

These are suggested definitions to adapt, not universal qualification rules. Record unsuitable, duplicate and unreachable enquiries separately. Do not quietly change the definition mid-reporting period; note when it changed so comparisons remain understandable.

Agree what qualifies before building the automation

A qualified lead is an enquiry that meets your documented commercial-fit criteria, not simply a contact with a phone number. For a service business, an initial definition might require a genuine prospect, a relevant service need, an area you can serve, usable contact details and a realistic next step. Add budget or timing criteria only if they are material to the service and can be assessed fairly.

Make “Qualified” an explicit decision by the responsible person when judgement is needed. A booked meeting can be a useful milestone, but a spam appointment or a request for a service you do not provide is not automatically a qualified opportunity. Record a short reason for disqualification, such as duplicate, outside service area or unsuitable request.

Use opportunity-level decisions when one contact can make separate enquiries. Someone may be a good prospect for one project but not another. A permanent “qualified” tag on the contact can obscure that distinction.

A worked journey from form to qualified lead

Illustrative workflow: a business receives a request for an advertising review through its website. This is a design example, not evidence that every integration described here is already active on our site.

1. Accept: the server validates the required fields and accepts the enquiry. A button click or a browser-side validation attempt does not complete this stage.
2. Record: the CRM stores the enquiry and assigns a follow-up owner. The system retains an internal reference for this particular submission, so a retry cannot silently create a second opportunity.
3. Measure: where the visitor's analytics choice permits it, the measurement integration records the accepted-lead event and retains the permitted attribution identifiers needed for later reporting.
4. Review: the owner checks the actual service requirement and records whether it meets the agreed qualification criteria.
5. Qualify: a deliberate move to Qualified makes one qualification event eligible for delivery. The integration checks consent and previous delivery before sending it.
6. Reconcile: the owner compares the eligible CRM outcomes with the analytics delivery record and report, rather than assuming that a successful workflow action proves end-to-end receipt.

If someone moves the opportunity backwards and then into Qualified again, that should not automatically produce another conversion. Define the duplicate-prevention rule around the opportunity and event type, record delivery state, and check an uncertain destination result before retrying. A genuinely new project should have its own opportunity and follow the documented rule.

Keep an enquiry measurement record

Use a record like the following to make discrepancies diagnosable. These are illustrative entries for a coordinated test, not customer data:

• Internal submission reference: WEB-TEST-001.
• Accepted and recorded: separate server-acceptance and CRM-record timestamps, with the timezone stated.
• Business owner and outcome: the assigned reviewer, qualification timestamp and a controlled outcome reason.
• Acquisition context: the permitted source/campaign details captured at the relevant visit, not guessed later from the contact's current record.
• Consent evidence: the applicable analytics choice and the time it was recorded, with withdrawal handled by the integration.
• Delivery state: eligible, pending, confirmed, suppressed or failed, plus the reason and a reference to the verification evidence.

Keep the customer's name, email, phone number and enquiry message in the appropriate business system with controlled access. Do not copy them into ordinary GA4 event parameters, page URLs, page titles or campaign labels. Google's guidance on avoiding personally identifiable information explains why URLs and user-entered fields need particular care. An internal record reference is not a reason to expose the underlying personal information.

Trace one authorised test through the whole route

Arrange a clearly labelled synthetic test with the people who own the form, CRM and follow-up. Use no real applicant documents or sensitive customer information. Confirm whether the test is allowed to send notifications, and prevent unintended customer communication before running it.

• Submit valid test information and confirm the success response, destination record and assigned owner.
• Try a missing required field. Confirm rejection and that no successful-enquiry conversion is recorded.
• Check repeat clicks or a reload against the intended duplicate-handling behaviour.
• Record the test time, destination record identifier, expected result, observed result and the person responsible for any repair.
• Mark test records clearly and handle exclusion or removal under the agreed reporting and retention process.

This checklist is for an authorised test environment or coordinated live test, not permission to submit somebody else's forms. A screenshot of a thank-you message alone does not prove the CRM handover or follow-up worked.

Separate GA4 key events from Google Ads bidding

GA4 answers a reporting question; Google Ads also needs an advertising optimisation decision. Google's recommended event reference includes generate_lead for a generated lead and qualify_lead when the agreed qualification criteria are met. Naming an event does not implement the trigger, attribution or duplicate prevention.

For this suggested design, send generate_lead after confirmed acceptance, not on every attempted submit. Send qualify_lead after the explicit CRM qualification decision and the required eligibility checks. Mark the meaningful outcome as a GA4 key event once it has been tested.

Google explains the distinction between key events and conversions. Marking something important in GA4 is not enough to assume a particular Ads campaign is bidding against it. Inspect the linked-account setup, conversion action and selected campaign goals. Choose a deliberate integration route rather than importing the same qualification through two independent routes and counting it twice.

A later CRM outcome also needs a supported connection to the earlier visit or advert. Establish the relevant identifiers, timing limits and attribution configuration before promising that every qualification will reconnect to its source. Server-side delivery must honour the applicable consent choice; it is not a way around a visitor declining analytics.

Inspect the conversion goal, not just the tag

Google explains that primary conversion actions can be used for bidding when their standard goal is selected; secondary actions normally serve observation. The important exception is a custom goal: actions in that goal can be used for bidding even when labelled secondary. Inspect the campaign's actual goal configuration before assuming an event cannot affect bidding.

Do not make every intermediate click a primary lead outcome. Decide which events are useful diagnostics and which represent the objective the campaign should pursue. Where qualification happens later, Google's offline conversion guidance explains how later outcomes can be connected to advertising. Implementation depends on identifiers, supported integrations, correct data handling and the applicable consent requirements. Hashing data does not remove those responsibilities.

Calculate lead quality on a consistent basis

Illustrative reporting example, not D4J or client performance: suppose one campaign's enquiry cohort (the group acquired during the same period) has R6,000 in media spend, 30 unique accepted enquiries, 12 qualified opportunities and three won customers by the stated reporting cut-off. Use the same cohort and attribution basis throughout.

• Media cost per accepted enquiry: R6,000 ÷ 30 = R200.
• Qualification rate: 12 ÷ 30 × 100 = 40%.
• Media cost per qualified lead: R6,000 ÷ 12 = R500.
• Qualified-to-won rate: 3 ÷ 12 × 100 = 25%.

These are media-only costs. Include management, creative and other acquisition costs separately if reporting total acquisition cost. State whether VAT is included. None of these figures establishes profit or return on investment without revenue, margin and an agreed cost basis.

Do not divide this month's spend by all leads qualified this month if many originated earlier. Qualification takes time, so recent cohorts can be incomplete. If no leads qualify, report that fact; do not show a zero cost per qualified lead. Keep business-wide CRM totals separate from the analytics-eligible subset when consent or missing attribution prevents a like-for-like comparison.

Diagnose the failure before changing the campaign

• Clicks rise, accepted enquiries do not: check form usability, validation and the offer before celebrating the click count.
• The form succeeds but the CRM is empty: inspect the server-to-CRM handover and failure handling. A thank-you page cannot verify that connection.
• CRM enquiries exist but source is missing: inspect consent, identifier capture, redirects and cross-domain journeys. Do not overwrite unknown attribution with an assumed source.
• Qualified counts jump unexpectedly: check repeat stage transitions, duplicate workflows and multiple import routes.
• Qualification drops: check response handling, changed qualification criteria and the audience or offer. More traffic is not the only possible remedy.

Use the management, training or review decision guide to assign the resulting work. If AI is proposed for triage, apply the readiness and human-review checks before allowing it to qualify or reject prospects automatically.

Keep delivered capability separate from measured benefit

In the Rental Buddies workflow, approved verification results return to CRM stages, fields, notes and tags, while uncertainty is routed to staff. That is evidence of a connected process. The published case study explicitly leaves application conversion, review time and revenue impact as outcomes to measure.

Next step: use lead-generation review for the acquisition and qualification journey, or an existing-account audit when the CRM handover needs diagnosis. Bring the stage definitions and the failed test, not just a screenshot of the total lead count.

Find the gap in your enquiry journey

Not sure whether the problem is the form, tracking or CRM handover? Discuss your enquiry-tracking problem with us. Describe the expected outcome, what actually happens and which systems are involved. Keep customer details out of the initial enquiry.