adsoraKeep the contact, inquiry and purchase separate
A person can request replacement windows and later ask about a shower. Two people can share a phone number at the same property. One supplier can retry a post after an unanswered response. These cases may produce similar contact fields while requiring different decisions.
Preserve a contact record for the person, an inquiry record for the project request and a purchase record for the supplier transaction. Your CRM may name these objects differently. The requirement is that a merge of contact details does not erase the source and price of a purchase.
Use the source's stable ID to detect delivery retries within that source. To compare different suppliers, your team needs a separate matching rule based on the fields both actually provide. Identical source IDs from different vendors are not automatically the same record.
Write a matching rule your team can explain
| Match | Additional check | Possible agreed treatment |
|---|---|---|
| Same supplier and purchase ID | Was the first post accepted? | Recover the existing result instead of creating another purchase |
| Same contact and project | Is it within the agreed lookback? | Apply the cross-source duplicate rule |
| Same contact, different project | Does the branch install both products? | Preserve distinct inquiries for review |
| Same property, different contact | Who requested which work? | Review before merging the project |
| Existing open opportunity | Is the new inquiry the same requested work? | Apply the existing-opportunity rule |
| Older closed opportunity | Did the homeowner make a new request? | Use the agreed re-entry criteria |
These are possible treatments, not universal eligibility rules. Put the final lookback, project definition and exception process in the buying agreement. A rule that procurement approves but the receiving system cannot apply will generate disputes after delivery.
Normalize formats without discarding the original value. For example, phone punctuation can be removed for matching while the original submitted number stays available for investigation. Treat incomplete or ambiguous values as such; do not invent missing contact details to produce a match.
Decide what can be checked before purchase
List which matching fields are available on ping and which arrive only on post. A partial record may support geography and project checks while leaving contact-level matching until later. Confirm the permitted data flow and the resulting acceptance rule with the parties implementing the connection.
If the necessary fields arrive on post, ask what happens when the duplicate check fails there. If the purchase is already committed under your arrangement, define the review and credit process. Avoid assuming a CRM's later merge will reverse a supplier charge.
Ask the platform provider to demonstrate a near-simultaneous duplicate from two approved test sources. Both records may pass if each checks the database before either writes an acceptance. The system needs the agreed handling of that timing case, and finance needs a clear transaction history afterward.
Keep evidence without spreading customer data
Use internal record IDs in the exception log and limit access to the underlying contact details. When resolving a supplier dispute, share only the evidence needed under the agreed process. A full CRM export to every vendor exposes unrelated customer records.
Record the match reason, relevant dates, project category and reviewer decision. If two records are merged, retain the original supplier IDs and their relationship to the surviving record. Store credits as linked adjustments rather than overwriting the original billed amount.
Review false matches as well as missed duplicates. An overly broad phone-only rule can block a valid new project. A narrow source-ID-only rule can miss repeated inquiries arriving through different sources. Inspect examples from both groups before revising the rule.
Use repeat patterns to improve the purchase rules
Report suspected matches, confirmed duplicate purchases and approved credits separately. A high suspected-match count could reflect existing customer activity, a mapping error or source overlap. The investigation should identify which of those you are seeing.
Send Adsora your lookback and project-level duplicate requirements with the buying brief. Confirm how the chosen delivery method applies those rules and which evidence both teams will retain for review.