Setting Up Lead Sources in Bitrix24: Where Requests Get Lost
Setting up lead sources in Bitrix24 starts not with a toggle in the interface, but with answering the question: where exactly did the request come from and what happens to it next.
As long as a source isn't tied to a channel, a website form, a call, and a messenger conversation all fall into a common stream — and the manager only learns about the lead when the lead reminds themself.
At that moment, it's not the request that gets lost, but the context: which page the person came from, what they viewed before that, which ad they clicked on.
Duplicates in the CRM are the second most frequent cause of losses. The same client leaves a phone number in a form, writes in chat, and calls — and three unlinked cards appear in the database.
Without matching rules based on phone, email, and external identifier, they don't get merged, the history gets smeared, and a repeat lead is processed as a new one.
Lead attribution in this case breaks off at the first touch: the system records the source of the first card and doesn't see the remaining points of contact.
This is fixed by setting up sources, not by manually cleaning the database. Each channel is assigned its own source with a clear rule for lead creation, required fields are defined for forms and chats, and duplicate linking is configured before requests start piling up.
Then the CRM shows not just "where it came from," but the client's entire journey — and decisions about channels are made based on facts, not feelings.
What well-structured request routing delivers
Configured lead routing in Bitrix24 turns the flow of requests into a manageable process: each request reaches the right manager according to a pre-defined rule, rather than based on reaction speed or the administrator's memory. Let's break down what effects this delivers in measurable terms.
Speed of distribution and processing
Previously, a request waited for manual sorting — a duty officer saw it, read it, decided who to assign it to, and only then did the manager begin work.
With a flow of dozens of inquiries per day, this created a delay of hours, and during peak periods — requests were lost from sight.
Distribution rules (by source, region, product, manager workload) eliminate this stage: the inquiry appears in the responsible person's card immediately upon arrival, and the time to first touch is reduced from hours to minutes.
Distribution among managers without manual intervention
Queues and rotation rules close the gap on workload unevenness: a strong manager stops "eating up" the entire flow, while a newcomer gets their share of inquiries.
A backup assignee and timeout-based escalation prevent a request from getting stuck if the primary assignee is unavailable. This eliminates an entire class of manual sorting errors — forgotten, double-assigned, and lost-between-departments leads.
Source control and end-to-end analytics
When the source is recorded automatically at lead creation, reporting stops depending on what the manager entered manually. You can see which campaign brings inquiries, which brings deals, and where requests come in but never reach a touch.
The share of processed inquiries becomes a measurable value rather than an eyeball estimate, and it can be used to set a plan for the department.
What this delivers in total
Reaction speed increases, request losses between stages disappear, and decisions about channels are made based on data rather than gut feeling. Routing is not a one-time setup but a loop that lives together with the funnel: rules change to fit new sources and products. Describe your request flow — we'll come back with an assessment and a setup plan.
Methods for connecting sources: comparison of options
Standard capture forms are the fastest path: the builder provides ready-to-use embed code, a lead is created immediately with a link to the source, and duplicates are filtered out by email and phone.
There is one limitation — the form lives on the portal side, so custom validation logic and multi-step scenarios cannot be built into it.
Webhooks cover everything that does not fit into the builder: a request comes from an external system, a mobile app, or a landing page on another engine.
We accept the request, map the fields to CRM entities, and create a lead with the source assigned — while handling repeats idempotently so that a repeated submission does not create duplicates.
| Option | When it fits | Limitations |
|---|---|---|
| Standard capture forms | Typical website requests, quick start without development | Logic and design are limited by the builder, no complex validation |
| Webhooks | External systems, landing pages on third-party engines, non-standard field mapping | Requires development and idempotency control to avoid duplicates |
| Telephony integration | Inbound and outbound calls, linking a lead to a conversation | Depends on the provider, correct routing and recording are required |
| Messengers and social networks | Inquiries in chats, quick consultations | Limited set of fields, part of the dialogue remains outside the card |
Telephony and messengers provide a different class of data: a lead is created not from a filled-out form, but from the fact of an inquiry, and the source is assigned automatically by channel.
Here it is important that a call is linked to an existing deal rather than creating a new one on every callback.
In practice, sources are combined: forms — for the website, webhooks — for external services, telephony and chats — for the inbound flow. Next, we break down how routing and analytics are configured for each channel.
Implementation order: from audit to handover
Work proceeds in stages, and each ends with an artifact that can be verified before the next one starts. This way the client sees progress rather than "work in progress," and can stop at any step without losing what has been done.
- Survey. We collect all the points from which inquiries come: website forms, telephony, messengers, email, social media, offline visits. We record the current distribution rules and how managers bypass them manually.
- Lead flow diagram. We bring sources, responsible parties, and statuses into a single map. Here we also determine which inquiries are considered duplicates and by what attribute they are merged.
- Setting up sources and scenarios. We create sources, link fields and responsible parties to them, and configure automatic actions: task creation, response deadlines, notifications, and stage transitions.
- Testing integrations. We run a test inquiry through each entry point and check whether it reached the right manager with a complete set of data. We separately check the behavior during an external service failure — the lead must not be lost.
- Verifying reporting. We check that reports by source match actual inquiries, and that the manager sees conversion for each channel rather than an overall figure.
- Training the team. We show managers how to work with stages and what to do with duplicates, and show the manager how to read reports and change distribution rules.
- Handover. We deliver the configured system, the flow diagram, and instructions, and we establish the change policy: who adds a new source and how.
The order matters: until the flows are described, setting up scenarios turns into a rework a month later. After handover, the system remains manageable — a new channel is added according to the ready-made policy, without a repeat survey.
What the client receives after setting up sources
Setting up lead sources in Bitrix24 is not a one-time toggle in the settings, but a set of artifacts that the team uses to keep working without us. Below is what exactly remains with the client after handover.
- Source map — a table of all lead entry points: website forms, telephony, email, messengers, social media, offline channels. For each one, it states which code marks it in the CRM and in which report it is visible.
- Distribution rules — the logic by which a lead goes to a specific manager: by region, business line, workload, or queue. The rules are described in such a way that a new employee can reproduce them without a developer.
- Processing regulations — what happens to a lead at each stage: the first response time, actions when the client goes silent, conditions for transfer to the sales department, the moment the deal is closed.
- Response templates — pre-written emails and messages for each source and funnel stage. The manager does not write from scratch and does not lose the lead in the correspondence.
- Instructions for employees — short guides on working with the lead card, changing the stage, and recording the call outcome. Designed for a person without a technical background.
- CRM documentation — a single document that brings together the map, rules, and regulations. When a manager leaves or a new contractor is brought on, the logic is not reconstructed from memory.
- Configured reports — a breakdown by source with conversion and lead cost. It shows which channel brings deals and which one only wastes managers' time.
Each artifact is verifiable: distribution rules are tested on real leads, the regulations — on a control deal, and reports are reconciled against actual data. If something does not add up, we fix it before handover, not after launch.
The scope of documentation depends on the number of channels and departments. Describe your sales structure — we will come back with an estimate and a work plan.
Case study: how we got sales request tracking in order in the sales department
The client is the sales department of an industrial company, 12 managers, requests came from a website form, email, phone, and messengers.
Each channel lived on its own: some inquiries settled in personal inboxes, some in notebooks, and deals were entered into Bitrix24 after the fact.
At the start, we measured three metrics: the share of inquiries with no touch at all, the time from request to first contact, and the number of duplicates per client.
What the pre-implementation audit showed
Out of 100 inquiries per week, about 70 made it into the CRM, and for every fifth one the manager made neither a call nor an email. The average response time was more than a day, because email requests were processed once a day, and messenger requests when a manager was free.
Duplicates accounted for almost a quarter of the cards: the same client was created again with a different spelling of the phone number or email.
What we changed
We brought all channels into a single entry point: the form, email, and messengers create a lead automatically, with the source and channel tag. We set up required fields and a check by phone and email before creating a card — repeat inquiries are attached to the existing client.
We added a distribution rule: a new lead goes to a free manager, and if there is no contact for more than an hour — escalation to the supervisor.
Result after two months
The share of lost inquiries dropped from 20% to 3%: almost every one now has a recorded touch. Response time was reduced from a day to 15-20 minutes during working hours. Duplicates decreased from 24% to 4% — managers stopped wasting time sorting through identical cards.
The supervisor sees the funnel for each source and understands where deals come from, instead of guessing from memory.
Such request tracking is not set up once, but maintained: distribution and verification rules live in the CRM and work without manual control. Describe your channel scheme — we will come back with an estimate and a setup plan.
What is the difference between a lead source and a sales channel?
A lead source records the entry point — the specific place where a contact first appeared in the system: a website form, an inbound call, an email, a chat, a business card from a trade show, a request from a messenger.
This is a technical label that is set automatically at the moment the card is created and does not change afterward. A sales channel describes the method of attraction — contextual advertising, search results, email campaigns, a partner referral, cold calling.
One channel can generate dozens of sources, and vice versa: a single website form can receive traffic from different channels.
The difference shows up in CRM reporting.
The source answers the question "where did a specific contact come from," while the channel answers "by what method did we get them." If you mix these entities in a single reference list, analytics breaks down: a manager puts "cold call" where "inbound request" should be, and you no longer understand which advertising pays off and which burns budget for nothing.
In practice, a lead source is a field in the card with a fixed list of values, while a sales channel is an analytical grouping on top of it.
In Bitrix24, the source is set when a lead is created and inherited into the deal, while the channel is displayed in reports by matching sources with advertising systems.
As long as this separation is maintained, the funnel shows the real picture: how many requests each channel brought in, at which stage they drop off, and where the bottleneck is.
The mixing of concepts almost always surfaces at the stage when the client asks for a report on advertising effectiveness, and there is no data for it — sources are filled in manually and inconsistently.
We separate the reference lists at the start of implementation: we set up automatic source population from forms and telephony, link channels to advertising tags, and only after that do we build reporting.
This way, the numbers in the CRM begin to match reality, rather than what managers remembered after the fact.
Frequently Asked Technical Questions About Lead Sources
Common technical questions about lead sources
Before changing anything, it is important to understand the state of the current system. We start with an inventory: which channels already write leads, through which forms, telephony, email or messengers, and how each of them assigns a source.
In practice, half of the problems with attribution are not the absence of settings, but the layering of old integrations that duplicate each other.
Duplicate leads are the most common complaint. The reason is usually that the same contact comes from several points: a form on the website, a call and a repeat request from a messenger create three separate cards.
This is solved by matching rules based on phone and email, setting an assignee and merging duplicates on a schedule. It is important not just to enable the check, but to determine the source priority — which channel is considered primary when there is a match.
Attribution verification is built on test scenarios: we run a lead through each channel and see what was written to the source field, which assignee was set, and whether a notification was sent. If the source is inserted incorrectly, we look for which integration overwrites the field last.
We already have integrations set up — will everything have to be redone?
No. We keep the working connections and build out the missing ones. First we map the current sources, identify conflicts and duplicates, then make targeted fixes to the logic.
A full rebuild is only needed where integrations were written without a single standard and interfere with each other.
How can we make sure attribution works correctly after setup?
We run control leads through each channel and verify the source, assignee and notification fields. If at least one channel writes data differently, the rule is refined until it matches. We repeat such a test after every change so as not to catch a regression.
What should we do if leads have already accumulated with the wrong source?
We perform a one-time cleanup: we match historical deals with the real channels using call, email and form data, and set the correct source. After that, new leads follow the rules, and the old database stops distorting reporting.
Let's discuss your lead source setup task
To come back with an estimate and an implementation plan rather than generalities, we need from you a snapshot of your current lead flows.
Setting up lead sources in Bitrix24 starts not with toggles in the interface, but with an inventory: where inquiries come from, how they get into the CRM today, where they get lost, and who is responsible for each channel. Without this, any automation cements the existing chaos.
Describe the task in free form — then we will ask targeted questions about access, export formats, and current distribution rules. That is enough to estimate the scope of work and avoid building unnecessary integrations.
What this kind of review provides at the outset:
- a map of all channels: website forms, telephony, messengers, email, advertising platforms, offline locations;
- a list of gaps — where a request does not create a lead or creates a duplicate;
- the current logic for assigning responsible parties and its bottlenecks;
- a list of sources that are already tagged correctly and which ones will need cleanup;
- requirements for end-to-end analytics: which reports management needs and in what form;
- constraints on access, policies, and integrations with the accounting system;
- priorities: what we close in the first phase and what goes into the second.
Based on the review, you receive an implementation plan with phases, areas of responsibility, and a verification sequence — from setting up lead intake to reconciling reports by source.
The estimate is based on the actual scope, not a standard template, so it does not include blocks that are already working for you.
Describe your task — we will come back with an estimate and a plan.