Define duplicate inquiry rules before merging CRM leads

A contact and an inquiry are different records

The same person can submit one request twice after a timeout, ask about another service next month or create a new buying request for a different team. Deduplicating every matching contact into one lead would erase those distinctions. Start by defining what the inquiry record represents.

Use a stable request or inquiry identifier to recognize retries where the application supports one. Contact identity helps link related records but does not independently prove that the commercial request is the same. Treat the time window as one policy input rather than a universal duplicate detector.

A decision table for common record pairs

These are proposed review rules, not proof about a particular CRM’s automatic matching capability. Choose a policy the team can explain and implement consistently. A convenient merge button should not determine the definition of a newly generated inquiry.

The payload meaning matters when a customer corrects a budget, deadline or contact route. Preserve the correction history in protected operational records. A later update should not silently replace the original acquisition evidence or be counted as a second new customer.

Prevent exact request duplication at the right layer

A database uniqueness constraint can enforce uniqueness for a chosen key. PostgreSQL documents that behavior, but the database cannot decide whether two different request IDs describe the same commercial intent. That remains an application and operating policy. [PostgreSQL: Constraints]

For an idempotent receipt design, the client reuses the same request identifier after an ambiguous timeout, and the server resolves that identifier consistently. If each retry generates a new identifier, a unique-key constraint alone will not recognize the repeated attempt. Test concurrent retries as well as a single repeated click.

Keep request identifiers out of broad marketing telemetry when they are not needed there. The operating system can retain the protected join evidence while analytics reports aggregate confirmed receipts and later acceptance. Do not upload contact values to an analytics event to make deduplication easier.

Preserve ambiguity instead of guessing

• Maintain a reviewed duplicate-of relationship rather than deleting the evidence immediately.
• Record which rule and reviewer justified a merge.
• Keep unresolved identity or intent in a visible queue.
• Reconcile raw attempts, confirmed records, deduplicated inquiries and accepted opportunities separately.
• Version the policy and note when a change affects period comparisons.

If a new policy merges 20% more records, a lower inquiry count may reflect classification rather than falling demand. Recalculate a comparable historical sample only where the evidence allows it, and preserve the original published definition. Do not present the policy change as an acquisition result.

I would test the policy on a small protected set of synthetic pairs before enabling bulk merges. The acceptance criterion is that known retries resolve to one inquiry while known distinct intents remain separate. Real exceptions should enter a review path rather than being forced into a guessed category.

• Review an initial CRM workflow
• Compare counts with explicit record definitions
• Define later sales acceptance

Sources

AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.

• PostgreSQL: Constraints — checked 2026-10-18