From website form to CRM: avoid lost enquiries and duplicate records

A visitor fills in your form, sees "Thank you!" and leaves. Three days later nobody has called back: the enquiry never reached the CRM. In the opposite case, they clicked "Send" twice and your team now has two records for the same person, each handled by someone different.

These two problems have little to do with which software you picked. They come from the order in which things happen and from what is planned when one of them fails. This article sets out principles, not a recipe: the details depend on your form, your CRM and how your team works. It describes no setup we have tested or delivered, and it promises no result.

A success message is not a received enquiry

The confirmation on screen only proves that the browser got a response. It says nothing about what was stored. We suggest a stricter definition: an enquiry is received once its reliable storage is confirmed, meaning it is saved somewhere durable where a person can find it even if everything else fails afterwards.

Three practical consequences:

• The success message appears only after that confirmation. If saving fails, the visitor sees it and can try again or use another way to get in touch.
• Creating the CRM record comes after storage, not instead of it. If the CRM is down, the enquiry still exists and can be passed along later.
• The confirmation email does not decide whether the enquiry was received. A failed acknowledgement must not make a valid enquiry disappear.

The same idea applies to email generally: SMTP specifies that a server that confirms it has accepted a message takes responsibility for delivering it or reporting the failure (RFC 5321, section 6.1). In other words, confirming a step should match a responsibility actually taken. A form should follow the same logic.

The steps, what each proves, and how to recover

The table below is illustrative: it describes general reasoning, not a specific setup or a measured result.

The right-hand column matters as much as the others. An enquiry that fails at step 4 is an incident to handle, not a lost enquiry: it is still at step 2.

Avoiding duplicates

Duplicates come from two sources: the visitor who submits twice, and your own automation retrying after an error.

For repeated sends by the system, a common technique is the idempotency key: a unique identifier attached to each request that lets the receiving side recognize a retry and avoid repeating the operation. As a documentary example only (not a tool recommendation), Stripe's API saves the result of the first request using a given key and returns it for later requests with the same key; it also compares parameters and returns an error if they differ (Stripe, Idempotent requests). Stripe notes that it may remove keys once they are at least 24 hours old, so a late retry cannot rely only on the provider's memory. An IETF draft, expired and not adopted as a standard, describes a similar HTTP header (The Idempotency-Key HTTP Header Field); we mention it as a lead, not a rule.

For people you already know, decide on an identity rule before connecting anything: does the same email address mean the same contact? What if the person writes about another company, or from a new address? A simple rule (for example, update the existing record rather than create one) beats a sophisticated rule nobody understands. Keep a trace of what was merged, and plan for a person to settle ambiguous cases.

Who sees what, and for how long

A form carries personal information. Two organizational questions come up before go-live.

Access. Who can read stored enquiries, and who can edit or delete CRM records? Limit it to those who need it, and avoid multiplying copies: every notification email that reproduces the form content is one more copy to protect. The access keys between the site and the CRM deserve the same care as any password.

Retention. Keep information only as long as needed for the stated purpose, then destroy it. This principle appears in the PIPEDA requirements summarized by the Office of the Privacy Commissioner of Canada: limit retention, and protect information in proportion to its sensitivity. In Quebec, the Commission d'accès à l'information gathers information for private-sector businesses, including consent, security measures and retention (page in French). We do not give legal advice: confirm your specific obligations and your privacy policy with the appropriate resources.

One last point: form content does not belong in your measurement tools. To track form submissions without sending personal data, see our article on the roles of GA4 and Google Tag Manager and our Analytics and tracking page.

Keeping a person in the loop

Automation handles expected cases well. So plan for what is set aside for a person to handle: a record that could not be created, a possible duplicate, an enquiry with no owner. An exceptions list that someone reviews on a fixed schedule beats an alert nobody reads.

The same reasoning applies to replies: a standard acknowledgement can go out automatically; a personalized reply, proposal or price commitment should be reviewed before sending. For choosing which tasks to automate and where to place checkpoints, see What to automate first in a small business.

FAQ

Do I need to change CRM to connect my form?

Not necessarily. The principles above apply regardless of the tool. What varies is what your CRM can do (available connections, usage limits, duplicate handling), which you should check in its documentation.

Is a connector plugin enough?

It may suit a simple need, but check what it does when the CRM is unavailable and when the same enquiry arrives twice. If the answer is "nothing" or "we don't know", the enquiry is not protected.

How do I check that nothing is lost?

Periodically compare the number of stored enquiries with the number of records created, and look into any gap. Also run a deliberate failure test: if the CRM is cut off for a few minutes, what happens to the enquiry?

Next step

Sketch your current path in five steps (entry, receipt, acknowledgement, record, follow-up) and note what happens on failure at each. The gaps often show up right there. To look at your needs with us, see our CRM and integrations page.

Describe your enquiry path