Bitrix24 landing page: where leads and data are lost
A Bitrix24 landing page breaks not at the layout level, but at the junction with the accounting system. The capture form sends data, the exchange is interrupted — the card is not created, and the inquiry remains in an email that no one opened.
Lead loss does not look like a crash: it is a quiet week without inquiries, even though advertising continues to run. At the peak of a campaign, the flow grows severalfold, and each such loss is paid traffic gone into the void.
A separate problem is duplicate inquiries. The button was clicked twice, the form was submitted again, and two deals with the same phone number appeared in the pipeline.
The manager spends time merging them, while reporting shows growth that did not happen: decisions are made based on distorted numbers.
Fields that did not make it to the card cost no less. A comment, the selected service, the traffic source — all of this is lost if the form and the card diverge in structure, and the manager calls without context.
At the same time, the user does not see an error response: they are sure the lead has been sent and leave.
All of this is not about layout or design, but about the integrity of the exchange between the landing page and the accounting system.
We will break down how this is addressed: where to place checks, how to protect against duplicates, and what to do when a lead still does not make it through.
What changes after implementation: speed, stability, metrics
A unified landing page template with a fixed set of blocks changes the publishing process itself: a new page is assembled from ready-made sections, and the content manager can change text, images, and block order independently, without a developer or release.
Page publishing time drops from days to hours, and edits no longer compete for engineers' time. At the same time, desynchronization of markup and connected scripts disappears — all pages inherit one structure, so the layout does not fall apart from edit to edit.
The intake of inquiries is not designed as "form directly to CRM," but through an intermediate queue with retries and an event log.
If Bitrix24 or an external service returns an error or does not respond in time, the inquiry is not lost — it remains in the queue and is delivered after recovery.
The share of leads that get through becomes measurable: you can see how many were sent and how many were actually created in CRM, and a discrepancy is a signal, not a surprise at the end of the month.
A class of failures that occurs most often on landing pages is addressed separately: inquiry loss under peak load, duplicates on repeated submission, a break when the integration is unavailable, inquiries without a source.
Each case is covered by its own mechanism — a unique inquiry key, retries with delay, mandatory recording of the source and entry page.
Metrics are taken from the same logs used for debugging: page publishing speed, share of delivered inquiries, number of inquiries without a response beyond the regulation, response time to a failure.
Separate reporting is not needed — the data is already there, and it shows exactly what changed after implementation.
Bitrix24 landing page: template, customization, external build
Three paths for implementing a landing page in Bitrix24.Sites diverge not at the design stage, but when non-standard logic appears: conditional fields, cost calculation, data exchange with CRM, or sections that are not in the block set. We will break down each option by the tasks it suits and the limitations it runs into.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made blocks | A typical landing page: benefits, lead form, reviews, callback. Edits are made by a marketer without a developer | Non-standard grid and animations run into the builder; conditional form logic is unavailable; the block set dictates the page structure |
| Template customization | You need branded design and custom sections, but the page stays inside the system: publishing, statistics, and leads in one place | Requires access to the template and developer qualifications; when the platform is updated, edits need to be migrated; delivery speed depends on cache settings |
| External build with an accounting system | The landing page is part of a separate project: heavy layout, custom components, multiple data sources | Exchange with the accounting system is described separately: fields, duplicates, error handling; support is handled on the development side, not in the interface |
The choice of approach is determined not by editor convenience, but by how much unique logic is in the page and who will maintain it. If there are many landing pages and they are typical, we use ready-made blocks and customize them selectively.
If there is one page and its mechanics are custom, we build the framework on a template and move complex sections into an external build with data exchange.
Work sequence: from connection audit to support handover
The work proceeds sequentially: first we record the current state of the landing page's connection with CRM, then we describe the data transfer scheme, and only then do we touch the settings.
This order eliminates the classic failure when the page is already receiving traffic, but lead routing and deduplication rules are not described.
- Audit of landing pages and scenarios. We compile a map of pages, forms, and traffic sources, compare the field composition with what actually reaches the cards, and look for duplicates, breaks, and leads that settle without an owner.
- Data transfer scheme. We describe the inquiry route: form, entity creation, task assignment, notifications. We record required fields, rules for merging repeat inquiries, and points where manual verification is needed.
- Scenario setup. We assemble pages and forms, connect business processes and robots, distribute inquiries across directions and branches, and set up auto-emails and response reminders.
- Connection with the accounting system. If data goes to 1C, we separately discuss exactly what is transferred in each direction, how exchange errors are handled, and what happens on repeated submission.
- Load testing. We run forms with parallel submissions, measure response time under peak load, check behavior when external services are unavailable, and verify deduplication correctness.
- Handover to support. We provide documentation on the connection, accesses, edit regulations, and marketer training: which blocks and texts can be changed independently, and what requires an engineer.
What we hand over: configuration, schemes, regulations
Publishing a landing page is not the final point. The project is delivered when the client's editor can assemble a new page from ready-made blocks on their own, and an engineer can deploy a copy and figure out what is where.
Therefore, what is handed over is not an archive of files, but a set of artifacts that the team uses without us and without back-and-forth.
- Assembled pages and blocks in the workspace: template sections linked to information blocks — a new landing page is assembled by rearranging blocks, without layout or code edits.
- Field map: which property is responsible for what, type, required status, default value, and which blocks it is displayed in.
- Access policies: editor, moderator, and administrator roles with separation — who edits content, who changes structure and permissions.
- Edit regulations: publishing procedure, work with drafts and rollback, who approves changes in templates.
- Instructions for editors: step-by-step scenarios with screenshots — replace text and image, add a block, hide a section, restore the previous version.
- Page documentation: list of templates, binding to sections, dependencies between blocks, and extension points for future tasks.
- Scheme of connected services and engineer contacts: forms, analytics, who is responsible during a failure and within what timeframes.
Case study: migrating landing pages to a managed template
The client is a chain of service centers: 14 landing pages for different cities and directions, each assembled separately and living its own life.
Editing a phone number or promotion terms meant manually going through all pages, and forms on two of them stopped writing to CRM after a design update — leads accumulated in email, and some were lost silently.
What the review showed before implementation
We walked the lead path on each page and consolidated the discrepancies into one picture. Three landing pages used different field sets, some inquiries came in as duplicates, and the manager checked them manually — this took several hours a day.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Page templates | 14 different | 1 managed |
| Editing contacts on all pages | 40–60 minutes | 2–3 minutes |
| Leads reaching CRM | 87% | 100% |
| Lead loss at peak | up to 15% per day | 0 |
| Duplicates in the database | about 10% | filtered out at entry |
The landing pages were migrated to Bitrix24.Sites: a shared template, unified blocks, forms with mandatory field validation and direct writing to CRM, and an end-to-end source tag. The content for each city remained its own — content changes, not markup.
Project result: new landing pages are now assembled from ready-made blocks in hours, not weeks. Lead loss at peak is gone, and manual reconciliation is no longer needed.
How does a standard template differ from a custom build?
A standard template in Bitrix24.Sites is a set of ready-made sections: the first screen, benefit blocks, a lead form, reviews. It is assembled in the visual editor in hours and edited with the platform's built-in tools.
The design limitations start immediately: the order and nesting of blocks are set by the template author, and display logic can only be changed using the settings they provided.
The template runs into trouble when a landing page stops being one page with one form.
Substituting content by traffic source, a step-by-step calculation with an intermediate result, different field sets for different flows, transferring a lead to an external system — standard sections do not support such scenarios.
Workarounds in the form of page duplicates and manual edits produce discrepancies in numbers and loss of some leads.
A custom build is an own site template: its own page structure, component templates, display rules, and server-side form processing.
Markup and block order are described in code, so a scenario can be made more complex without affecting other pages, and repeating parts are moved into reusable blocks.
The selection criteria are simple. A standard one is enough if there is one scenario, the form is standard, and the page changes rarely.
A project build is needed when the landing page is the main campaign channel, there are more than two scenarios, there are integrations, and there are requirements for rendering speed.
Then the design limitations stop being theoretical: each new traffic flow requires code edits, not settings.
Common technical questions: integrations, limitations, support
A landing page on Bitrix24 lives longer than the launch: offers change, fields are added to forms, and new systems are connected. Therefore, questions before the start are about how the platform survives changes, not about the appearance of the pages.
Can a landing page be edited without access to code?
Yes. Texts, images, and block order are edited in the visual editor, and the template is not affected. We move a non-standard section into a separate component template — a platform update will not overwrite such an edit.
Why do fields from the form not reach the card?
Most often because of mismatched field machine names or required fields that the system does not accept as empty; less often because of webhook permissions.
We run forms on a test environment and set up a queue with retries: the lead is not lost, even if the receiving system returned an error.
What happens at peak traffic?
Pages are served from cache, and the database is not queried on every request. Form submission goes through a queue, so during a short unavailability of the external system, leads are delivered after recovery.
How to work if the site is managed by a third-party contractor?
We hand over the template, integration scheme, and extension points, issue accesses by role, and revoke them when the work is completed. Edits do not break form logic, and the next contractor does not have to rebuild the connections from scratch.
What is included in support after launch?
Update regulations, monitoring of forms and integrations, and rollback of the template to a previous version. Minor edits accumulate and are released without a separate release.
Let's discuss the task and come back with an estimate and plan
So that the work estimate is based on facts rather than guesses, we need only the initial input data: what the task is, what result is considered successful, and by what deadline it is expected.
The rest — page structure, forms, integrations with the catalog and accounting system, access requirements — we will analyze on our side and come back with an implementation plan and solution scheme.
At the start of a project, what matters more is not the scope, but the boundaries: what is included in the first stage, what can be added later, and how that will affect timelines. Therefore, we record agreements in writing before work begins.
- Description of the task and audience: what we are promoting and what action the visitor should take.
- Block composition and priorities: what is critical at the start, what we move to the second stage.
- Materials: texts, logo, images, links to examples you like.
- Integration requirements: catalog, payment, lead export, notifications to responsible persons.
- Accesses and limitations: who accepts the result, whether there are requirements for the domain and hosting.
- Timelines and approval points: when the launch is needed and who confirms the stages on your side.
What we will analyze ourselves: page structure and logic, lead submission scenarios, the connection scheme with the accounting system, Bitrix24 limitations, and ways to work around them.
Describe the task in free form — we will come back with a work estimate, implementation plan, and clear project start timelines.