Connecting your website to a CRM: how it works and what can go wrong

The form on the site sends an enquiry and the CRM simply doesn't receive it — and nobody notices for weeks, until it emerges that "the site hasn't produced enquiries in a while". Losses like this almost never come from the site itself or the CRM itself, but from how the two are joined.

Why calling the API directly is a risky design

The simplest option is to send the form data straight to the CRM at the moment of submission. The problem is that if the CRM is unavailable right then — scheduled maintenance, an outage, API limits — the enquiry is simply lost, and neither the site nor the CRM says so. A more reliable design has the site store the enquiry first and put it in a queue, and the queue then attempts delivery to the CRM, retrying on failure and logging the outcome.

What data should travel with an enquiry

• A unique enquiry id and the exact time it was created.

• Contact details in normalised form, and the language the form was filled in.

• The page, the service and the comment the user supplied.

• UTM tags, referral source and other data needed for attribution later.

• The record of consent to process personal data.

The duplicate enquiry problem

If a form is submitted twice — say the user pressed the button again because the response was slow — the CRM shouldn't create two identical records. At the same time, the same client getting in touch again later is often not a duplicate but a new opportunity, and merging those automatically is a mistake. Matching contacts on name alone is risky too: companies often share one phone number or one mailbox across several staff.

Routing and response times

A good integration doesn't just pass the enquiry across — it decides immediately who it should reach, by service, region, language or working hours, and creates a task with a clear deadline for first contact. If that deadline is missed the enquiry should escalate rather than sit in a shared list.

What to monitor continuously

• CRM unavailability or a noticeable increase in response time.

• Authentication or permission errors during transfer.

• Cases where the enquiry was processed but no record was created in the CRM.

• A growing queue of undelivered transfers.

• A gap between the number of enquiries on the site and new records in the CRM — if the figures don't match, data is being lost somewhere.

If enquiries from the site are clearly being lost or duplicated and you can't find the cause yourself, we can audit the integration and show exactly which step breaks the chain.