# The Same Buyer Sent Three Forms. How Many Opportunities Did GEO Create?

> Three form submissions may belong to one buying project. Define contacts, inquiries and opportunities separately, preserve the links between them, and keep GEO attribution within the evidence.

- Canonical: https://www.aixindar.com/news/the-same-buyer-sent-three-forms-how-many-opportunities-did-geo-create
- Markdown: https://www.aixindar.com/news/the-same-buyer-sent-three-forms-how-many-opportunities-did-geo-create.md
- Author: Daoyu Guan — https://www.aixindar.com/experts/daoyu-guan
- Published: 2026-11-01T01:13:39.102Z
- Last updated: 2026-11-01T01:13:39.215Z
- Evidence checked: Not separately recorded in CMS
- Editorial status: Published
- Corrections: No correction record supplied by CMS.

*By Daoyu Guan*

An RFQ submission, a contact, a buying project, and a sales opportunity are different counting units. One engineer can submit several drawing revisions for one project. Several people can represent the same purchase. One customer can also have two unrelated projects. Deduplicate the relevant records without deleting the underlying inquiry events, and define when a project becomes sales accepted. Keep discovery evidence separate: a buyer's statement that they used ChatGPT is useful self-reported information, but repeated forms do not create repeated AI-assisted opportunities or prove that GEO caused a sale.

A manufacturer can improve its English website, attract more useful inquiries, and still misunderstand the result. The reporting error often appears after the form works: every submission receives a new row, and every row becomes a “lead.”

The solution starts with deciding what the business wants to count.

## Four records answer four questions

An **inquiry event** records what arrived, when, through which route, and with which attachments or references. A **contact** represents a person or address used for communication. A **buying project** groups work around an identifiable purchasing need. A **sales opportunity** is a project accepted into the company's defined sales process.

Those relationships are not always one-to-one. An engineer and a purchasing manager may belong to one project. A distributor may represent more than one end customer. An existing contact may return six months later with a different part family and a separate budget.

The event record should remain available even after the business decides that it belongs to an existing project. Otherwise, deduplication can remove the drawing revision, delivery condition, or clarification that made the inquiry commercially meaningful.

| Counting unit | Useful question | A common false inference |
| --- | --- | --- |
| Received form | How many submissions reached the system? | Every submission is a new buyer |
| Distinct contact | How many communication identities are represented? | One contact means one purchase |
| Buying project | How many separate needs can we identify? | A new drawing revision is a new project |
| Sales-accepted opportunity | Which projects meet our stated commercial entry criteria? | Acceptance means engineering approval or an order |
| Won order | Which business was actually contracted? | Every prior AI mention caused the purchase |

## Walk through six submissions

The following is an invented example. It describes a counting method, not a customer result or a benchmark for export marketing.

| Event | What arrived | Proposed treatment |
| --- | --- | --- |
| 1 | Alex requests a quote for a housing, drawing A | Open project H; review suitability |
| 2 | Alex sends drawing B for the same housing | Add a revision event to H |
| 3 | Sam, Alex's purchasing colleague, confirms quantities | Associate a second contact with H |
| 4 | Alex requests a different pump component for another site | Open separate project P if the buyer confirms the distinct need |
| 5 | Lea, a distributor, asks about a part without identifying its application | Keep a separate inquiry awaiting clarification |
| 6 | The website team sends an internal form test | Mark as a test and exclude from buyer counts |

There are six received submissions, five external buyer submissions, and three named contacts: Alex, Sam, and Lea. Alex and Sam represent one company; Lea represents another. If H and P pass the business's defined sales-entry criteria, there are two sales-accepted opportunities. Lea's inquiry remains unresolved under that definition.

None of those counts says how many orders will result. None establishes AI attribution. A report can present every count accurately, provided it does not quietly substitute one unit for another.

## Email deduplication does not resolve project identity

[HubSpot's deduplication documentation](https://knowledge.hubspot.com/records/deduplication-of-records) describes automatic contact matching by email address and company matching by domain, with additional identifier-based options for specified operations. Those are CRM record rules. They do not decide whether two drawing requests describe the same buying project.

The distinction matters for shared inboxes. “Purchasing” may be used by several employees or sites. A person may also change address or move employer. Treat the CRM's identity result as one input, then inspect the actual buying context before merging opportunities.

Avoid inventing a universal project key from email plus month. That would merge separate needs from a busy customer and split a long project across calendar boundaries. Prefer a buyer-confirmed project reference where available, with a recorded decision when your team must infer the relationship.

## Match on the purchasing need, then preserve revisions

A proposed project review should inspect the part or assembly, buyer project reference, site, purpose, expected quantity pattern, and relationship to an existing request. These are suggested review inputs, not mandatory fields every first-contact form should demand.

Drawing revision alone is a poor project identifier. The revision may change while the commercial project stays the same. The same revision label can also appear on unrelated drawings. Keep the document number, revision, received date, and buyer context together.

When a second submission belongs to an existing project, add the new event and identify which requirements it supersedes. Preserve the earlier version for the people permitted to see it. Do not leave two active requirements merely because both arrived through valid forms.

The opposite decision also needs a reason. If the same contact requests a second project, record why it is separate: a different application, site, purchase reference, or independently managed requirement. A later reviewer should be able to follow the decision without guessing from filenames.

## Associate the conversation with the correct project

A contact record can accumulate conversations about several needs. That does not mean every conversation belongs to every opportunity linked to the contact. An email about a replacement part should not become evidence of progress on an unrelated new machine order.

[HubSpot's record-association guide](https://knowledge.hubspot.com/records/associate-records) illustrates linking several contacts and a company to a deal. Its [activity-association documentation](https://knowledge.hubspot.com/records/associate-activities-with-records) separately explains how activities can be linked to records. Association behavior, availability, and permissions should be checked in the actual account.

For your acceptance test, use a fictional contact with two projects. Submit a revision for one project and a clarification for the other. Ask the operator to find the relevant history from each project record. Passing a contact-import test does not establish that this project-level separation works.

## Define sales acceptance before reviewing results

A small manufacturer might require an identifiable need, a plausible fit with its offer, a reachable buyer, and enough information for a meaningful next conversation. Another may need a different threshold. The important point is to write the rule before counting the campaign's outcome.

Keep commercial acceptance distinct from engineering feasibility. A sales team may accept an RFQ for investigation while material, tolerance, tooling, or regulatory questions remain open. The website should not convert that administrative status into a promise that the factory can manufacture the part.

Record rejection and clarification reasons as useful findings. “Outside size range,” “drawing missing,” and “distributor relationship unclear” lead to different improvements. Grouping them all as bad leads can hide a content problem or an intake process that asks the right buyer too little.

## Keep AI discovery evidence at the event level

A form may carry a referring URL, campaign parameters, a landing page, or the buyer's answer to “How did you find us?” Preserve these as separate observations with their original wording and time. A contact's latest source field should not overwrite the origin of an earlier project.

Suppose Alex says ChatGPT helped identify the supplier for H, then returns directly for P through an existing relationship. The self-report supports an AI-discovery statement about H's inquiry. It does not automatically make P a second AI-sourced opportunity.

Likewise, an independently observed AI recommendation proves that a particular answer recommended the business under recorded conditions. Without a link to the buyer's actual research, it does not prove that Alex saw that answer. The monitoring ledger and CRM can inform each other without being presented as a complete attribution chain.

## Show the denominator beside cost figures

Assume, only for illustration, that the work associated with the six-submission example cost $1,200. Dividing by all six received submissions gives $200 per received form. Dividing by the two sales-accepted opportunities gives $600 per accepted opportunity. Both calculations are arithmetically correct and describe different things.

Neither is necessarily an incremental acquisition cost. The example does not establish what would have happened without the work, and the cost allocation might include reusable assets or activity benefiting other channels. Do not attach an “AI-generated pipeline” label merely because an AI-monitoring dashboard exists.

A useful report provides the counting definitions, the period, the included cost, and unresolved cases. If an opportunity is later merged or rejected, show the revision rather than quietly changing last month's result.

## Give the website owner a practical acceptance exercise

Test one repeated submission, one revised drawing, two contacts on one project, one contact on two projects, a shared inbox, and an internal test. These are proposed test cases; use dummy data and documents rather than exposing a real customer's drawing in a general marketing review.

For each case, check receipt, routing, event preservation, contact association, project association, status, and reporting treatment. Also check what the buyer sees in the confirmation. “Your request was received” should not imply that engineering accepted the specification or committed to delivery.

For [Xindar's B2B export marketing work](https://www.aixindar.com/services/export-marketing), this makes inquiry quality a concrete discussion. Public service descriptions cover buyer-facing content and inquiry paths. A particular CRM integration or data migration still needs an explicit scope and acceptance test; it should not be inferred from a marketing-service label.

## Questions from export teams

### Should duplicate form submissions be deleted?

Usually the reporting duplicate and the underlying event should be handled separately. An event may contain a changed requirement or attachment. Preserve the evidence under your access and retention rules, even when it does not count as a new opportunity.

### Does one email address mean one buyer?

It means one observed communication address under the CRM's matching rule. Shared inboxes, staff changes, and multiple projects require additional context. Do not use email matching as a universal definition of commercial identity.

### Is a revised quote a new opportunity?

Not automatically. Determine whether the purchasing need is continuing or genuinely separate. Record the decision and keep quote versions distinguishable from the project count.

### Can an AI discovery question settle attribution?

It adds useful self-reported evidence. It does not independently verify the whole journey or isolate the causal effect of GEO. Report the response as a self-report and preserve unknowns.

## Sources and method

The three linked HubSpot documents support limited statements about record matching and associations. They do not prescribe the project-counting model in this article. The six-event scenario, proposed acceptance criteria, and cost arithmetic are original illustrations. Related reading: [preserving buyer constraints through an RFQ form](https://www.aixindar.com/news/the-buyer-knows-the-constraint-does-your-rfq-form-keep-it). Form meaning and opportunity identity require separate checks.

## Editorial references

- [Editorial policy](https://www.aixindar.com/editorial-policy)
- [Research methodology](https://www.aixindar.com/research-methodology)
- [Corrections policy](https://www.aixindar.com/corrections)