# Review duplicate builder inquiries without losing identities

A builder lead duplicate review separates the person, household, project and inquiry touch before proposing any merge. AgAI Labs proposes this worksheet to compare evidence, preserve source and permission histories, and record a human decision. Shared contact details alone cannot establish identity. Keep conflicting records separate until a named reviewer resolves the evidence.

## When is a repeat inquiry a duplicate?

Start by naming what appears twice. A second submission may describe an existing person, a different household member, another project or another contact attempt. Those possibilities need different decisions. A repeated contact value starts a review; it does not settle one.

| Identity | Question to record | What stays distinct |
| --- | --- | --- |
| Person | Do the records describe the same individual? | Individual role, contact evidence and permission history |
| Household | Is a shared household relationship confirmed? | Each person's identity and decision role |
| Project | Do the inquiries concern the same proposed build? | Project scope, status and next-action owner |
| Inquiry touch | Is this another interaction or a repeated copy of one interaction? | Original submission, source, time and inquiry text |

A returning person can start a new project. Two household members can discuss one project. A repeated import can copy an existing touch. Record these relationships separately instead of flattening every match into one contact.

The [builder lead intake form guide](/articles/leads-and-crm/builder-lead-intake-form/) explains why later submissions must retain their context. This worksheet prepares a decision outside the working CRM. It does not authorize a merge, deletion, bulk update or automated identity inference.

## Which evidence belongs in the review worksheet?

Copy the template below into an approved review document. Use internal identifiers instead of unnecessary contact details. Keep evidence links inside storage with appropriate access. This public template needs no real buyer records.

```
REVIEW ID / REVISION / PREPARED DATE:
Preparer identifier:
Candidate record IDs and originating systems:
Person IDs / household IDs / project IDs / inquiry-touch IDs:
Review question and proposed identity level:
Evidence for a match, with source references and observation dates:
Contradictory facts, with source references and observation dates:
Unknowns and evidence needed:
Confirmed person, household and project links:
Original source for each candidate; later source history references:
Permission history for each person, channel and stated purpose:
Current next action, due date and owner for each candidate:
Proposed outcome: merge / keep separate / unresolved
Exact proposed relationships and field decisions:
Values and histories to preserve without alteration:
Recovery evidence location and original-to-proposed ID map:
Named reviewer identifier / authority / review date:
Decision, reason and scope of approval:
Unresolved task, responsible owner and review date:
Status: preparation only; live changes require separate authorization
```

Give each evidence entry a source, a date and an explanation of what it establishes. A submitted project reference supports a project link. It does not establish that two people are identical. Mark statements, staff observations and confirmed facts separately.

Use the [builder CRM field dictionary](/articles/leads-and-crm/builder-crm-fields/) to interpret values. A blank means unknown unless the dictionary defines another meaning. Do not let a populated field defeat a conflicting statement merely because it looks complete.

Write the exact proposed action. “Clean duplicates” hides its scope. “Treat Person-A and Person-A-copy as one person; retain Project-A and Project-B separately” gives the reviewer a testable proposal.

## What proves records should stay separate?

Shared email, phone, surname or address does not establish a safe merge. Look for evidence about the people and projects themselves. An explicit statement that two records concern separate people supports separation. Conflicting project references require project review even when the person matches.

The following cases are fictional. Every label is invented. They describe worksheet decisions only; no contact details, CRM actions or buyer results are represented.

| Case | Evidence and contradiction | Worksheet outcome |
| --- | --- | --- |
| Merge proposal: Person-A and Person-A-copy | Touch-A and Touch-B each reference Project-A. A recorded clarification explicitly confirms the same person and project. No conflicting identity evidence appears. | Propose one person identity and one project link. Preserve both touches and both source histories. Reviewer-A must examine the clarification. |
| Returning person: Person-B | Touch-C concerns Project-B. Touch-D explicitly describes Project-C as a separate build. The person identity is confirmed in the fictional clarification. | Keep Project-B and Project-C separate under Person-B. Preserve the earlier project outcome and each project's next-action owner. |
| Keep separate: Person-C and Person-D | Both use Contact-Shared. Their statements identify separate people with different roles in Household-A and Project-D. | Keep two person identities. Record the confirmed household and project relationships without treating shared contact information as shared permission. |
| Unresolved: Candidate-E and Candidate-F | The contact label matches. One record references Project-E; the other has no project reference. No direct clarification establishes person identity. | Keep records unchanged. Assign evidence gathering to Intake-Owner-A. Do not select the more complete record as the presumed truth. |

For the merge proposal, record Person-A as the proposed continuing identifier and Person-A-copy as a preserved original identifier. List Touch-A and Touch-B separately. The proposal changes the identity mapping, not the meaning of either inquiry.

For the returning person, a matching identity does not close Project-B or transfer its tasks to Project-C. Record a separate owner and next action for each project. Keep household membership unknown unless evidence establishes it.

For the shared-contact case, record each person's preferred response and permission evidence independently. For the unresolved case, write the missing question before assigning follow-up. A review deadline does not turn weak evidence into a match.

## How do source and permission histories survive?

Keep the original source for every candidate beside its later touches. Preserve conflicting source descriptions with their origins. A later form submission must not erase an earlier referral. Use the [Lead attribution stage](/process/lead-attribution/) for the broader source design.

Record permissions by person, channel, purpose, evidence and date. A shared contact method does not transfer one person's permission to another person. A newer inquiry does not resolve an unexplained permission conflict. Mark the conflict for an authorized person to review under the builder's existing process.

Prepare a before-and-proposed comparison for every field affected by the decision. Include original identifiers, project links, source references, permission records, current tasks and their owners. Keep the source snapshot unchanged in approved storage. Record where the snapshot can be recovered.

A recovery record should show how each proposed identifier maps back to the original candidates. The worksheet alone cannot guarantee that a CRM operation is reversible. Keep any later change held until the administrator confirms a recovery method appropriate to the system.

The [lead data ownership guide](/articles/leads-and-crm/lead-data-ownership/) explains portable records and preserved transformations. This worksheet adds the identity decision and its reviewer. It creates no new retention period or permission policy.

## Who authorizes the final action?

The builder designates a reviewer with authority over the proposed record change. Use a named internal identifier, such as Reviewer-A in these fictional examples. An empty approval field keeps the proposal unresolved.

1. **Capture the candidates.** Prepare unchanged snapshots and record every original identifier.

2. **Separate the identity questions.** Compare people, households, projects and touches independently.

3. **Complete the worksheet.** Attach supporting evidence, contradictions, unknowns and current task owners.

4. **Propose a bounded outcome.** Describe merge, keep-separate or unresolved decisions at each identity level.

5. **Obtain human review.** The reviewer records the decision, reason, date and exact approved scope.

6. **Return unresolved work.** Assign missing evidence and a review date to a responsible owner.

Keep approval of the worksheet separate from authorization to change a live system. This guide stops at preparation and human approval. It supplies no live merge instructions or automatic matching rules.

For each outcome, preserve the active next action until its owner accepts an explicit replacement. Two tasks with similar wording may concern different projects. Record task conflicts for the reviewer instead of dropping whichever task looks older.

## What else should a duplicate reviewer check?

### Can matching email addresses settle a person match?

A matching email address can flag builder records for review. It cannot establish person identity alone. Compare attributed evidence and contradictory facts before proposing any merge.

### Does a returning buyer need a separate project record?

A confirmed returning person can have a separate builder project. Keep the project scope, inquiry touches, outcome and next-action owner distinct when the evidence describes a different build.

### What happens when identity evidence stays incomplete?

An incomplete builder identity review stays unresolved. Preserve the candidate records, identify the missing evidence and assign a review task. Do not infer identity from whichever fields contain values.

### Does worksheet approval authorize a CRM merge?

Worksheet approval records a human identity decision. It does not authorize a live CRM merge. Obtain separate authorization for the exact system change and confirm recovery arrangements first.