Website CRM integration: check that every enquiry arrives
Neaptide · September 7, 2026 · 6 min read
Connect website forms to your CRM, preserve attribution and handle retries without duplicate enquiries. Includes a failure scenario and acceptance checklist.
On this page
A thank-you message does not prove that an enquiry reached your CRM. Before signing off the website, ask to see the saved submission, its CRM record and the assigned owner. If processing stops between those stages, someone needs to be able to find it.
The integration sends website form data to the CRM, creates an enquiry, links it to a contact and assigns a salesperson according to your rules. You may be able to use the CRM’s own form or a ready-made connector; custom API development is another option. Choose the approach that supports your process.
Define what “received” means
Separate three milestones: the website saved the enquiry, the CRM confirmed the record, and a salesperson received a task. An email or Telegram notification is useful, but it does not establish that all three happened.
During a CRM outage, the website may safely store an enquiry for later delivery and tell the visitor it has been received. If storage fails too, a success message would be misleading. Offer a clear retry or another contact route. Only promise a response time that the sales team has agreed to meet.
Start with the simplest suitable connection
Check a native form or existing connector against your field, routing and recovery requirements. Ask for a demonstration of failure handling. Custom code is not inherently more reliable.
A queue separates intake from processing, but someone must monitor delayed and failed messages. A separate queue service may add little value to a small, stable workload. Compare operating effort as well as initial setup.
Decide which enquiry details the CRM needs
Create a table showing each form field and its destination in the CRM. Include details the site supplies, such as the page address, form ID, submission time and known traffic source. Check required fields and allowed values: free text from the website may not fit a fixed CRM dropdown.
Decide whether to retain the first known source, the current enquiry’s source or both. Missing UTM parameters do not establish a direct visit; the source may simply be unknown.
Keep CRM credentials on the server. Define who can view diagnostic records and avoid turning error logs into broadly accessible copies of customer messages.
A retry is different from a returning customer
Consider a fictional submission S-104. The CRM creates record C-208, but its confirmation never reaches the website. The website sees a timeout. Creating a record again without checking the outcome can produce a duplicate.
Use the same submission ID when retrying delivery. If the CRM API supports idempotency, repeated requests can be treated as one action; otherwise, a suitable way to match and check records must be designed. Simply searching before creating a record is not enough when two requests arrive together. A timeout does not tell you whether the first record was saved.
If the same person requests a different service tomorrow, that is a new enquiry S-105. You may link it to an existing contact, while preserving the new request under the sales team’s rules. Deleting every submission with the same phone number can hide real demand.
Ask to see a failure test
Use these cases in a test environment for every form and language version. They define acceptance expectations, not results from a tested CRM. Keep the submission ID alongside each observation so that you compare the same enquiry across systems.
| Test case | Expected check |
|---|---|
| Normal enquiry | Correct fields, source, record and owner. |
| Temporary CRM outage | Saved enquiry, visible pending state and resumed delivery. |
| Timeout after creation | Retry produces no second enquiry; reconcile using the ID. |
| Invalid required field | Visible error; no endless retries without correction. |
| New request, same phone | New request preserved according to agreed rules. |
| No UTM parameters | Unknown source is not replaced with an invented campaign. |
Agree the handover before launch
Ask for the field-mapping table, rules for repeat enquiries and instructions for finding and handling errors. Name the person responsible for failures and agree acceptable delivery times. Have the developer show how to resume processing after a fix without creating duplicates.
The number of new deals will not necessarily match the number of enquiries. Some enquiries are added to existing contacts or deals. Check each submission ID against its delivery status, allowing for tests, spam and pending requests. A recorded click on Submit does not prove that the enquiry arrived.
For a Neaptide website project, send the website address, CRM name, form list and a sanitised example of the desired record. Explain how returning customers should be handled and who in sales will accept the work.