Keep the customer, enquiry and delivery attempt separate
Imagine a facilities company submits a website enquiry and later emails an updated site list. Those messages may belong to one opportunity. The same buyer could also request an unrelated service for another location. Combining everything under one email address can hide that second request; treating every incoming message as a new customer creates the opposite problem.
Agree which CRM record represents the company, which represents the person and where the individual enquiry belongs. Then keep the form submission or inbox message reference alongside its received time and source. The CRM record is the working customer record; the source reference explains how information reached it.
An illustrative intake record might read: enquiry ENQ-318; source form FORM-884; company CRM-C42; contact CRM-P17; request a connectivity assessment for two sites; owner service desk; next action confirm the second address. A later email can add evidence to ENQ-318 without creating another company. This is a design example using fictional records, not a customer deployment.
Check how your actual CRM creates and matches records
HubSpot documents email-based contact matching and domain-based company matching for supported creation paths. It explicitly warns that companies created through its API are not automatically deduplicated by company domain. An integration therefore needs to verify its own write path; behavior observed in a manual form does not prove the same behavior in an API connection.
Salesforce documents an external-ID upsert: one matching record is updated, no match normally creates a record, and multiple matches return an error without a write. Its documentation also distinguishes an external ID from a field configured as unique. The implementation must choose the correct field and account permissions, rather than assuming that calling an operation upsert removes every duplication risk.
Ask the implementer to show the specific create, search and update operations in your account. Record which system supplies the stable identifier and how the destination ID is saved after a successful write. Product names and connector logos do not answer those questions.
Use matching rules that preserve uncertain but useful enquiries
A known destination record ID is stronger than a similar display name. Email addresses, verified company domains, location details and an existing customer reference can contribute to a match, but they serve different purposes. A shared reception inbox does not identify every employee, and several legal entities may operate under one website.
For each intake, return one of three useful decisions: update a supported existing record, create a genuinely new record, or retain the enquiry with a specific identity question for an employee. Do not discard a useful request because its company size, contact title or secondary phone is missing.
Keep conflicting observations visible with their sources. If the form says North office and an older CRM entry says South office, preserve both until the owner establishes whether they are locations, an address change or different businesses. An AI summary can prepare that question; it should not silently merge customers or overwrite a trusted address.
Make retries safe for records and for the work that follows
A connection can finish a CRM write while the caller misses the response. Retrying an unconditional create can produce a second record. The workflow should retain the original request reference, intended action and destination reference, then reconcile the result before deciding to repeat it. A delayed response is an uncertain result, not proof that nothing happened.
Duplicate-event handling is a separate concern. Stripe, for example, documents repeat webhook deliveries and does not guarantee delivery order. Its guidance uses processed event IDs to recognize repeated deliveries. This is one provider example; check the equivalent contract for each form, inbox and CRM connection in your workflow.
Preventing a duplicate contact is not enough if the same intake still creates two employee tasks or starts two follow-up sequences. Give the intended task its own repeat-prevention reference, such as ENQ-318 plus request-details task. If the task was created but an acknowledgement is uncertain, reconcile that action separately. Do not label a received event as a completed message or booking.
Show employees a decision they can act on
An exception should explain the business problem without asking an employee to decode execution logs. For example: ENQ-318 matched company CRM-C42, but the new site address differs. The original request is saved. No customer records were merged. Confirm the site and select the existing account or a new account. Owner: account manager. Next step: review the two address sources.
The employee should be able to open the original enquiry, relevant CRM record and conflicting field evidence. Record the chosen association and who made it. A review task should cover the ambiguity that matters; it should not impose a new approval on every uncomplicated incoming enquiry.
Keep customer communications under the agreed rules. Saving an enquiry, selecting a contact route and preparing a reply are separate from permission to send. Opt-outs and replies must remain associated with the right customer and conversation when records are corrected.
Test the awkward cases before connecting real intake
Use fictional records in an isolated test arrangement. Demonstrate the destination records and employee tasks, not just a green execution icon. Include these checks in the implementation acceptance discussion:
- Replay one submission: the original enquiry remains available, with one intended CRM change and one task.
- Submit a genuinely different request from the same person: preserve the new enquiry without duplicating their contact.
- Process two simultaneous arrivals for one supported identity: check that matching and creation do not race into two records.
- Interrupt the response after a destination write: recover the destination reference before another create.
- Use the same name for different people and a shared inbox for several staff: do not merge them from those fields alone.
- Remove an optional field or break an enrichment step: retain the enquiry and expose the actual missing step.
Agree on maintenance and measure the right improvement
After launch, assign ownership for matching rules, field changes, failed connections and unresolved associations. Keep access to the source evidence restricted and agree its retention period. A parser change should not require the customer to resubmit an enquiry that was already received.
Measure distinct enquiries received, supported existing-record matches, new customer records, unresolved identities and repeated actions prevented. Keep attempted requests and repeated processing out of new-lead totals. Compare a representative baseline with the same intake channels and period before claiming an improvement; fewer records alone could also mean missing work.
Monchera can scope this around your existing CRM, enquiry sources and employee responsibilities. Bring an anonymized example of a duplicated record, a repeated task and a legitimate second request from the same buyer. Those examples help define a working acceptance test and the ongoing management needed to keep intake reliable.
