Website CRM Integration: Enquiries, UTM Tags and Delivery Checks
A website CRM integration is ready to launch when every accepted enquiry can be traced to its CRM record. Test retries, CRM errors and attribution too. A confirmation message in the browser should reflect the stage that the server has actually completed.
The business outcome is straightforward: each enquiry reaches the right pipeline with its form data and source, gets an assigned owner and survives a temporary outage. Developers need to agree on these rules before connecting the API.
The workflow below is intended for service and business websites. Use it to prepare requirements and acceptance tests. Check the exact fields, permissions and limits against your CRM documentation and account settings.
Decide what the CRM should create
Start with the sales department process. For one business, a new request becomes a lead; for another, it becomes a deal and a related contact. The word “enquiry” on the site does not automatically determine the type of CRM object.
Record the contact path: what form is submitted, what object is created, what funnel it goes into, who receives the notification, and what the manager does next. If the “Order a quote” and “Become a partner” forms process different commands, these must be different routing rules.
Separately designate the owner of the directories. Services, sources, stages and employees have their own identifiers. Binding to a text name without verification may break after renaming. Changes in CRM require an integration update procedure and a benchmark test.
General issues of system design and exchange with other services are discussed in CRM architecture guide. Here the task is more specific: reliably deliver the request from the site and check its processing.
Map the fields
For each field, define the source, transformation, and destination. It is better to check the final card with the manager: a technically successful request may create an object that is inconvenient to work with.
| Data | Where do they come from? | What to agree on |
|---|---|---|
| Name and contacts | Form fields | Obligation, format and behavior in absence |
| Service or product | Form and open page | CRM directory or separate field |
| Comment | Visitor input | Length limitation and safe display |
| Contact page | URL of the page with the form | Which parameters are retained and which are excluded? |
| Form ID | Site setup | Distinguishing the header, service page and affiliate form |
| UTM parameters | Transition and consistent storage | First or last touch, retention period |
| Source CRM | Integration Rule | Compliance with available source directory |
| Case ID | Site server | Find, resend and link to a CRM object |
| Responsible | Routing rule | Replacement in the absence of an employee and control of assignment |
Do not send the entire page address to CRM indiscriminately. The parameters may contain data that is not needed for sales. Agree on what is allowed, such as ad labels and page ID. For service logs, also determine the composition of the data, access and storage period.
Check CRM limitations before development: required fields, text length, connection rights, availability of required objects and automatic actions. For example, Bitrix24 documentation for crm.item.add describes checks for rights and required fields; After saving, robots can be launched. Test enquiries should therefore be routed to the agreed test process.
Preserve UTM tags and enquiry attribution
UTM parameters help connect the call to an advertising campaign. Their values must travel from the input page to the form and then to the required CRM fields. If the person opened another page before sending, reading only the current address may not be enough.
Before implementation, choose a model: store the first known ad touch, the last, or both in separate fields. Write down what to do the next time you visit directly and when the saved data is no longer used. This is the rule of your analytics; There is no single suitable option for all companies.
Do not replace the source with a previous campaign unless the rule no longer considers it relevant. Don't write an unknown source as "organic" just because it doesn't have UTM. The visitor may have arrived via an unlabeled link or with data transfer restrictions.
The metric classifies sources by tags and other information about the transition. The CRM receives the data provided by your integration. Therefore, the reports of the two systems may differ, especially if they have different accounting models. For verification, you need an identical test transition with known parameters and an understandable attribution rule.
Practical test: open the site using a marked link, go to the service page, submit the form and check all agreed values in the CRM. Then repeat the scenario without tags, with another campaign and returning to the site. In each case, the result must match the selected rule.
Separate enquiry acceptance from CRM delivery
One option for your own form is to first securely store the request on the server side, then transfer it to the CRM. This approach requires storage, a retry handler, and delivery monitoring. It allows you to separate the wait for the external system from the response to the visitor.
If you are using an off-the-shelf CRM form or connector, find out which of these functions the vendor provides and what is available for review. Don't assume a queue, log, or retries just because the connection was successful.
It's useful for a custom handler to negotiate states:
| Condition | What has already happened | What to check |
|---|---|---|
| Accepted | Data verified and saved by server | There is a case ID |
| Awaiting transmission | CRM has not yet confirmed the creation of the object | The request remains in queue |
| Delivered | CRM returned a successful result with object ID | The card exists and is filled out correctly |
| Requires parsing | Automatic retry does not solve the error | Responsible person assigned and reason saved |
The acknowledgment in the interface must correspond to the state. If the request is reliably accepted and will be delivered later, you can report acceptance. If it is not saved, the success message will hide the loss. The analytics event should also be tied to the agreed stage, otherwise button clicks will be considered hits.
For temporary unavailability of CRM, repeated attempts with pauses and a limit are required; for permanent field errors, a notification to the responsible person is required. If access is revoked or a required field has changed, repeating the same request endlessly will not fix the problem.
Store the connection secret on the server. Only the data required by the form is transmitted to the visitor's browser. Limit integration rights to the tasks being performed; include the procedure for replacing and revoking access in the project transfer.
Distinguish a delivery retry from a new enquiry
These are two different scenarios. A re-delivery occurs when a site does not receive a response and sends the same request again. New case - when an existing customer requests a different service or returns at a later date.
Each accepted enquiry requires a stable identifier. The retry uses the same identifier, and the system checks which object already matches it. This protection is called idempotency: repeating an operation does not create an extra result. Its implementation must be consistent for the selected API and site storage.
Finding a person by phone or email solves another problem - connecting with an existing contact. Bitrix24 provides a search for matches by communications, but the choice of further action remains up to your process. One client can have several independent requests that cannot be lost when merging contacts.
Example: A customer clicked a button twice due to a slow response. This is one enquiry and possible re-delivery. A week later he requested another service with the same phone. This is a new request from an existing customer. Verifying by phone only risks confusing these situations.
Check the timeout especially carefully after the card is actually created. CRM could save the object, but the site did not receive a response. Before repeating, you need to be able to check the result by the request ID or an agreed upon characteristic. The mere presence of a successful API method does not provide such protection.
Integration acceptance tests
Ask the contractor to run tests on agreed upon test data and report the results. View the site interface, the status of the request on the server, and the CRM card at the same time.
| Scenario | Expected result |
|---|---|
| Correct enquiry from each form | Required object, fields, funnel and responsible person |
| Missing required contact | An understandable mistake; no false confirmation |
| Double click and repeat the request | One accepted enquiry, no extra card |
| New request from an existing client | The contact is connected according to the rule, the new request is saved |
| Transition from UTM across multiple pages | Labels in CRM correspond to the selected model |
| CRM is temporarily unavailable | The accepted request is saved and delivered after recovery |
| CRM response lost after creation | Repeat doesn't create a second object |
| A required field has been changed or access has been revoked | The error is visible to the person responsible and can be reprocessed |
| Spam and invalid format | The request is rejected according to the agreed rule, a normal request passes |
Test forms on a mobile device, from service pages, and from pop-ups. The same appearance does not mean the same processor. In the report, list all the forms and results so that the missed option is visible.
To recover from a failure, you need a person who sees undelivered requests, understands the reason and can start a replay. Procedures should be reviewed prior to launch, including in the event of resignation or absence of the primary person in charge.
What to include in the implementation brief
Pass the form list, field map, source rules, CRM object, routing and validation scripts. Supplement them with the procedure for issuing access, the test environment and the support owner. The contractor will be able to evaluate integration based on specific behavior.
B article about the cost of CRM development The broader components of the project are described. To connect the site, ask for a separate assessment of reception, delivery, repetition and error control: a single line of “CRM” hides significant differences in the scope of work.
If automation is required on top of existing data, the next step could be connecting an AI agent to CRM via MCP. First, verify that initial cases are being delivered and contacted correctly.
The composition of the implementation and setup of processes can be discussed through CRM implementation service. It is useful to attach a completed field map and examples of current errors to your enquiry.
FAQ
Can you receive enquiries only by email?
Yes, if such a process suits the team. For CRM, you then need to separately define the transfer of the request, the appointment of a person in charge, and the control of processing. The letter may be a backup notification, but the presence of the letter does not prove the creation of the card in CRM.
Should you keep every new enquiry from an existing customer?
Maintain self-directed inquiries according to sales process. Process a technical repeat of one request using its identifier. A phone match helps find a contact, but does not prove that the request has already been processed.
Why does Metrica show a conversion with no enquiry in the CRM?
Check when the goal is triggered: on click, server acceptance, or CRM confirmation. Find the case ID and delivery status. Then check API errors, field settings and accesses. Until the cause is clarified, the system numbers cannot be considered interchangeable.
Can you use an existing connector?
Yes, if it covers the necessary fields, routing, replays and diagnostics. Carry out the same procedure. If the functions are not enough, compare the development of the connector with your own server processor in terms of support and responsibility.
Sources
- Yandex Metrica: processing source labels.
- Bitrix24: search for duplicates by communications.
- Bitrix24: creating a CRM element via crm.item.add.
Documentation reviewed October 2, 2026. The delivery diagram and acceptance table is a recommended approach for discussing the project, and not a description of the capabilities of any off-the-shelf connector.