# Prepare a duplicate-contact review list

Canonical page: https://agents.paretoid.com/workflows/prepare-a-duplicate-contact-review-list/

Category: CRM & Follow-up

Practice relevance: cross-practice. A general operational method. Review the stated tool and jurisdiction limits before use.

Jurisdiction/provider scope: 

Group possible duplicate contacts for review while keeping shared-number cases separate.

Status: Proposed / not tested. The public discussion supports the problem; the method source supports only the documented features. No outcome from this adapted recipe has been verified.

Verification: The linked sources support the complaint and documented method components. We have not run this recipe or verified its results. The example below is synthetic, not a customer result.

## The problem

Group possible duplicate contacts for review while keeping shared-number cases separate.

Why it matters: Duplicate contacts can split correspondence and matter history, but shared contact details do not always mean the same person. A review list keeps possible matches visible without merging distinct or adverse parties.

## Sources and evidence

- pain: [Pain evidence: Public discussion](https://www.reddit.com/r/LawFirm/comments/v4tlj1/does_anyone_have_any_advice_about_software_for/)
  ; first-person comment 2022-06-05. A former Clio user, -Not-Your-Lawyer-, describes integrations creating “duplicates, triplicates, and sometimes even quadruplicates,” requiring repeated manual cleanup. Older practitioner evidence.

- method: [Method: Clio contact editing limits](https://help.clio.com/hc/en-us/articles/9290520359579-Edit-and-Delete-Contacts)
  Clio Manage does not automatically merge two contacts. Staff can move data manually. Lawmatics separately warns against duplicate LSA syncing across systems.

- method: [Method: Clio contact editing limits · supporting guide 2](https://help.lawmatics.com/en/articles/10699994-google-ads-and-google-lsa-integration)
  Additional official capability reference. It does not validate the complete proposed recipe.

Source checked: October 15, 2026. Pain reports are self-reported and identities are unverified. Method documentation supports components, not a tested end-to-end workflow.

## Suggested approach

Start when: Weekly export or new integration rollout

1. group likely duplicate records, compare stable IDs and linked matters, identify the creating integration

2. Keep row or page references and mark missing or ambiguous evidence. Do not apply the suggested changes.

3. The responsible staff member checks the draft against the source records and approves any separate action.

## What you need

- Clio Manage contact export permission and authorized visibility of the selected matter/contact relationships.

- Approved matching policy, normalization rules and permitted identifier tokens. Shared household details are not person identity.

- Firm-approved Excel; optional Copilot entitlement and tenant approval for the exact minimized data. Native Excel analysis can be done manually if Copilot is absent.

- Keep raw exports and identifying source pointers in a separate restricted location. The AI workbook contains only approved alias-based tables and visible policy/scope text, never raw client records on another tab.

- Use synthetic inputs first. Keep real data in firm-approved accounts and processing, with appropriate access, confidentiality and retention controls. Aliases alone do not anonymize records. Never paste credentials, API keys or unnecessary client details.

## How to use

Documentation-checked proposed route; source collection and human approval required

- Contact export includes basic/custom contact fields, not billing preferences or a guaranteed complete relationship graph. created_at/created_by_system/household_group must not be invented if absent.

- Candidate duplication does not authorize merge or deletion; clients, relatives and adverse parties may legitimately share contact details.

Access and setup:

- Actual account access, plan and source-data completeness have not been tested.

### 1. Download the actual contact list

Tool: Clio Manage

Location: Contacts > All / People / Companies > Filters > bottom Export > CSV > Export

Choose the authorized scope and all or selected visible columns. Retain raw headers and capture filters/time/count. Review related contacts on each relevant matter Dashboard separately; the contact CSV alone is not the matter-links table.

Expected output: Native contact CSV and manually checked matter/contact relationships.

Next step: Keep identifiers restricted and prepare approved alias/token records.

Check before continuing: Do not assume matching names/emails mean one person; check People/Companies scope and hidden contacts.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://help.clio.com/hc/en-us/articles/9290532034843-Filter-and-Export-Contacts https://help.clio.com/hc/en-us/articles/9285920226075-Get-Started-With-Matters

### 2. Map the observed records to the starter input

Tool: Excel and authorized staff

Location: Separate analysis workbook > Home > Format as Table

Map contacts.csv to contact_alias and normalized_identifier_token using the approved normalization policy locally. Assign an opaque equal-value token to identical normalized identifiers; do not expose the underlying email/phone/address. Preserve household_group_if_known,created_at,created_by_system and relationship_role only when observed. Build matter-links.csv from verified Dashboard relationships with contact_alias,matter_alias,role. Paste matching-policy.txt into Policy with scope exclusions. Create named tables for Contacts and MatterLinks. Put the policy and review scope in visible worksheets or paste them into the next prompt.

Expected output: Alias/token Contacts and MatterLinks tables; unknown creation metadata remains unknown.

Next step: Check the mapping against each original source before using AI.

Check before continuing: Aliases and missing policy fields are staff-created; do not relabel a native export as the kit schema. Unknown stays blank/unknown, not false or zero.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://support.microsoft.com/en-us/excel/tutorial-import-data-into-excel-and-create-a-data-model

### 3. Review the bounded evidence with Copilot

Tool: Excel Copilot, optional

Location: Approved analysis workbook > Copilot icon at lower right > Chat only

Use Chat only and submit the prompt. Without Copilot: group identical approved tokens, then inspect relationship conflicts and policy exclusions.

Prompt:

```text
Apply the supplied matching Policy to Contacts and MatterLinks. Return candidate contact_alias pairs/groups, exact matching token evidence, relationship differences, conflicting facts and source rows. Separate shared-household or business contact details from possible duplicate persons. Unknown metadata stays unknown. Recommend human checks only; never merge contacts, infer identity or erase matter roles.
```

Expected output: Evidence-linked duplicate-candidate list, not merge instructions.

Next step: Copy the draft exception list to the reviewer; retain row references.

Check before continuing: Check every flagged row and the scope. A fluent answer is not evidence of completeness; no automatic workbook or source-system edits.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://support.microsoft.com/en-us/excel/copilot/get-started-with-copilot-in-excel https://support.microsoft.com/en-us/excel/copilot/frequently-asked-questions-about-copilot-in-excel

### 4. Approve the review result

Tool: Responsible staff reviewer

Location: Reviewed local worksheet

An authorized contact administrator opens both original contact records and their matter relationships, decides whether they are actually the same entity and records the evidence. Any merge is a separately reviewed action.

Expected output: Reviewed identity candidates and explicit keep-separate decisions.

Next step: Any external message, source change, payment or deletion requires its own authorized process.

Check before continuing: Never merge client/adverse-party or family records based only on a shared email, address or phone.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://support.microsoft.com/en-us/excel/tutorial-import-data-into-excel-and-create-a-data-model

## What you will get

contact-review.csv: group_id, candidate_contact_aliases, match_evidence, conflicts, linked_matters, possible_origin, proposed_review, approval_status

## Human review and limits

Shared household numbers do not prove identity. Never merge adverse parties, destroy history or delete records automatically; administrator approves each repair.

The assistant drafts or reports only. Check source records and review the output before a human performs any separately approved send or change. No automatic legal decision, money movement, account connection or publication is included.

What to measure: During the pilot, count findings confirmed by the reviewer, false alarms, and missing-input cases. Do not infer time or money saved.

## Original prepared-input schema

contacts.csv: contact_alias, normalized_identifier_token, household_group_if_known, created_at, created_by_system, relationship_role

matter-links.csv: contact_alias, matter_alias, role

matching-policy.txt: approved rules, ambiguous-match handling, backup scope; use non-reversible synthetic tokens in the pilot

Synthetic example input:

```text
C1/C2: exact stable token, same role, no conflicting matter links
C3/C4: same household phone token, different people
C5/C6: similar names, adverse-party relationship
```

Expected synthetic output:

```text
C1/C2: possible duplicate, administrator review
C3/C4: ambiguous shared number, keep separate
C5/C6: conflict warning, do not merge
```

Failure check: Remove the provenance field. The output must say the creating integration is unknown, rather than name one.

## Starter files

Native blank scaffolds and original synthetic examples may use different schemas. Follow NATIVE-INPUT-MAPPING where supplied. These files do not connect accounts or install automation.

- [Download starter kit](https://agents.paretoid.com/assets/starter-kits/g10-starter-kit.zip) — All inputs, synthetic examples and review notes in one ZIP. No automation is installed.

- [Start here: get the sources and prepare the review](https://agents.paretoid.com/assets/starter-kits/g10/START-HERE.txt) — Documentation-checked acquisition, explicit manual mapping, exact prompts and human review limits

- [Setup and review checklist](https://agents.paretoid.com/assets/starter-kits/g10/README.txt) — Required inputs, file use, review steps and limits

- [Contacts blank CSV](https://agents.paretoid.com/assets/starter-kits/g10/contacts-template.csv) — Blank input headers for contacts.csv

- [Contacts synthetic example](https://agents.paretoid.com/assets/starter-kits/g10/contacts-example.csv) — Synthetic test records for contacts.csv

- [Matter links blank CSV](https://agents.paretoid.com/assets/starter-kits/g10/matter-links-template.csv) — Blank input headers for matter-links.csv

- [Matter links synthetic example](https://agents.paretoid.com/assets/starter-kits/g10/matter-links-example.csv) — Synthetic test records for matter-links.csv

- [Matching policy template](https://agents.paretoid.com/assets/starter-kits/g10/matching-policy-template.txt) — Required policy or native-input preparation aid; synthetic when marked example

- [Matching policy example](https://agents.paretoid.com/assets/starter-kits/g10/matching-policy-example.txt) — Required policy or native-input preparation aid; synthetic when marked example

- [Synthetic example expected results](https://agents.paretoid.com/assets/starter-kits/g10/expected-results.txt) — Compare a pilot result with the planted exceptions

## Optional original prepared-input prompt

Destination: Your firm-approved AI assistant · prepared files

This original prompt uses its own prepared-input schema. Do not mix it with native-step tables without the supplied mapping.

```text
Find likely duplicates in this anonymized contact export. Use exact normalized identifiers first; show conflicting names, shared numbers, relationships and linked matters. Group possible matches without merging. Recommend the surviving record only when the evidence is explicit, and list recorded creation systems; label a possible origin as a hypothesis and leave it unknown without evidence.

INPUTS
contacts.csv: contact_alias, normalized_identifier_token, household_group_if_known, created_at, created_by_system, relationship_role
matter-links.csv: contact_alias, matter_alias, role
matching-policy.txt: approved rules, ambiguous-match handling, backup scope; use non-reversible synthetic tokens in the pilot

OUTPUT
contact-review.csv: group_id, candidate_contact_aliases, match_evidence, conflicts, linked_matters, possible_origin, proposed_review, approval_status

Use only the supplied synthetic or firm-approved inputs. Cite source row or page IDs for each finding. Keep unknowns unresolved. Return a draft for the responsible staff reviewer. Do not send messages, connect accounts, change records, move money, or make legal decisions. Keep source files unchanged. If an input or permission is missing, list what is needed and stop that check.
```

Proposed / not tested · editorial prompt

Published by Law Firm Agents. Proposed adaptation; not tested. Not legal advice.