In our archive of 30,096 public project briefs, 690 ask for lead generation and 176 of those also mention a CRM. In almost every one of those, the join between the two — the website form writing into the CRM — is described in a single clause, as though it were a checkbox.
It is also, in our experience, the single most common place a business loses enquiries without knowing it. Here is one client discovering the problem the hard way:
Why the failure is silent
A form has two halves that are almost always built separately: what the visitor sees, and what happens to the data. The visitor's half shows a thank-you message when the button is pressed, because on most sites that is a front-end behaviour. It runs whether the data reached the CRM, reached nothing, or reached somebody else's CRM.
So there is no error anywhere a human looks. No red banner, no bounced email, no support ticket. The business receives fewer enquiries, attributes it to a quiet quarter, and the actual cause sits in a broken connector from a plugin update four months ago.
Field mapping is where the data quality is decided
Most integrations are built by matching whatever the form has to whatever the CRM has, and stopping there. Three decisions get skipped, and each one costs later:
- **What happens to a field the CRM does not have.** It is silently dropped by default. If the form asks for budget and the CRM has nowhere to put it, the sales team never sees an answer the customer took the trouble to give.
- **What happens to a required CRM field the form does not collect.** Some CRMs reject the whole record. One missing required field can mean an entire day of enquiries never landed.
- **What format each side expects.** Phone numbers are the usual casualty. A UAE mobile written five different ways by five visitors becomes five formats in the database, and none of them match when somebody searches.
Decide the duplicate rule before you build
The same person will submit twice. They will use a different email the second time, or the same email with a different phone, or fill the form again six months later on a different device. What the system does at that moment has to be a decision, not a default.
| Rule | Good for | Costs you |
|---|---|---|
| Match on email | Simple, mostly right | Misses the same person on a second address |
| Match on phone | Better in this market | Formatting differences create false uniques |
| Match on either | Catches the most | Occasionally merges two real people at one company |
| Never merge | Nothing is lost | The team works the same lead three times |
There is no universally right answer, which is exactly why it should be chosen deliberately. In this market, matching on normalised phone plus email catches the most without merging colleagues who share a company switchboard.
Build the error path first
Every connector fails eventually. An API key expires, a required field is added on the CRM side, a rate limit is hit during a campaign, a plugin updates. The question is not whether it breaks but what happens in the hour after it does.
- 1Retry the submission a few times with a delay, since most failures are transient.
- 2If it still fails, store the raw submission somewhere durable. A queue, a spreadsheet, a database table — anywhere it can be replayed from.
- 3Notify a named human immediately, on a channel they actually watch. Not an unmonitored alerts inbox.
- 4Send the enquiry to that person by email as a fallback, so the lead is workable even while the integration is down.
- 5Record the failure so somebody can see it happened twice this month rather than treating each one as a surprise.
Steps two and four are the ones that get skipped, and they are the difference between an outage that costs an afternoon and one that costs a fortnight of enquiries.
Capture attribution at the moment of submission
Every record should arrive carrying the page it was submitted from, the campaign or referrer that brought the visitor, and the timestamp. Written at submission, into fields on the record itself.
Reconstructing this later is not possible. Six months on, when somebody asks which pages produce enquiries, the honest answer without this is a guess — and that guess usually gets used to decide where the next year's budget goes.
Common questions
Usually a broken connector nobody noticed, because the failure is silent. The visitor sees a thank-you message since that is a front-end behaviour that runs whatever happened to the data, so no error appears anywhere a human looks and the shortfall gets blamed on a quiet quarter.
Submit the form yourself from a device that is not logged in, then confirm the record appears in the CRM with every field populated. The thank-you screen proves nothing. Repeat this after every site deployment and every plugin update, which is when these connections most often break.
Decide the rule before building rather than accepting a default. Matching on normalised phone plus email catches the most in this market without merging colleagues who share a company switchboard. Every option has a cost: email-only misses second addresses, phone-only creates false uniques through formatting, and never merging means the team works one lead three times.
By default, nothing visible. Build the error path first: retry, store the raw submission somewhere it can be replayed from, notify a named person on a channel they watch, and email them the enquiry as a fallback so the lead is workable while the integration is down.
The page it was submitted from, the campaign or referrer, and the timestamp, written into fields on the record at the moment of submission. It cannot be reconstructed later, and without it the answer to which pages produce enquiries is a guess that ends up deciding next year's budget.
