Measure qualified inquiries instead of form totals

Measure qualified website inquiries by connecting accepted requests to a documented review decision. A form total measures activity, not whether the requests fit your services. Count delivery first, qualification later, and show how much of the cohort is still waiting for review.

For a business serving Costa Rica and US buyers, language and requested service can help route an inquiry. Neither should become an automatic proxy for commercial value. Qualification needs an explicit definition that the sales and delivery teams can apply consistently.

Define qualification before building the dashboard

A useful definition describes observable fit. For example, a request may qualify when it concerns an offered service, names a concrete business need, and has a contactable person who can continue the conversation. Those are suggested criteria, not a universal rule.

Keep “not yet known” available. A buyer who has not chosen a budget is different from spam, and a genuine support request is different from a new project opportunity. Record reasons so the team can revisit the classification.

Use a small status model:

Status	Meaning
Accepted	The receiving system stored the inquiry
Pending review	No qualification decision yet
Qualified	Meets the documented criteria
Not qualified	Reviewed, with a recorded reason
Duplicate or spam	Excluded under a defined rule

Do not let a dashboard silently treat pending requests as rejected ones.

Separate acceptance from browser events

Track success after the receiving system accepts the inquiry, not when someone clicks Send. Keep a stable internal reference so retries and repeated notifications do not multiply one request into several leads.

Google Analytics documents separate generate_lead and qualify_lead events. Those names support different stages; they do not define your qualification policy or automatically connect your CRM.

Store contact details in the appropriate operational system. Avoid placing email addresses or free-text inquiries in analytics parameters or URLs. Google’s Measurement Protocol and User ID policy prohibits uploading data that lets Google personally identify someone. This technical boundary also makes a cleaner reporting design possible.

Calculate a hypothetical cohort honestly

Suppose a hypothetical month produces 100 unique accepted inquiries after spam and duplicate exclusions. Reviewers assess 80, qualify 24, and leave 20 pending. These are illustrative numbers, not 5e Labs results.

The qualification rate among reviewed inquiries is 24 divided by 80, or 30%. Reporting “30% of all inquiries qualified” would misstate the denominator. Show the accepted total, reviewed total, qualified total, and pending count together.

Use the inquiry’s acceptance date to define the cohort, while allowing qualification to arrive later. Otherwise a late review may appear as new demand in the following month. Keep the report’s observation date visible so readers know how complete the review was.

Use the result to improve one decision

Compare service and language groups only when the same definitions and review process apply. A small sample can point toward a question, but it does not establish that a headline caused a change. Read disqualification reasons before redesigning the form.

Start with a manual review of recent inquiries and agree on the categories. Then map how accepted requests and review decisions should connect. Custom software development at 5e Labs is relevant when that connection requires a CRM integration or a shared operational workflow, rather than another isolated counter.