Lead setup in Bitrix24: pipeline automation, stages, and robots

Setting Up Leads in Bitrix24: Where the Pipeline Breaks

The pipeline breaks not in reports but at the entrance.

A request comes from a web form, open channel, mailbox, telephony, and messengers — and if each channel is set up with a separate configuration, some inquiries never become leads at all, but settle in correspondence without an owner and a first response deadline.

The second bottleneck is manual transfer of requests.

While a manager copies an inquiry into the card themselves, any workload, vacation, or shift change results in lost requests in the pipeline, and from the history it is impossible to understand who failed to process an inquiry and when.

Duplicate requests from different channels finish off the picture: a client wrote in chat, then called and filled out a form — the database has three cards and three calls from different managers.

The standard duplicate search matches phone and email address, but with different number formatting or an inquiry from a corporate mailbox, no match is found.

A separate story is stalled stages.

A lead goes into “In Progress” and stays there: there is no robot to return the task when there is no activity, required fields are not set when moving to the next stage, rights to change the responsible person are vague, and the time spent at the stage is not controlled by anyone.

Setting up leads in Bitrix24 is exactly about this: bringing channels into a single entry point, removing manual operations, enabling duplicate control and stage movement. We explain how this works and what is covered at each step.

What Automation of Request and Stage Processing Provides

A request that lands in Bitrix24 without configured rules lives at the manager's whim: until they open the card, the system is silent.

Automation begins with a combination of robots, triggers, and distribution rules — when a lead appears, a responsible person is assigned, a task with a deadline is created, and the card gets the stage “In Progress.” Response stops depending on who is on shift today: time to first touch is reduced from hours to minutes and is recorded in the lead history.

The second layer is deadline control at stages. A robot counts how long a request stays at a stage, and when the limit is exceeded, it creates an activity, returns the card to work, or passes it to the supervisor.

This removes a whole class of failures — “the request was not seen in time”: the share of processed requests is brought up to the entire sample, not just the part the manager managed to pick up.

The third layer is rejection reasons. Moving to “Rejected” requires filling in a required field from a reference list, so reasons become data rather than a retelling at a planning meeting.

You can see where requests are lost: at the entrance, during terms approval, or after sending a commercial proposal. A report by reasons shows not the department’s emotions but the structure of losses.

Pipeline transparency is a consequence of these three layers. At each stage, you can see the number of leads, average and maximum time to pass through, and the share of transitions further.

The bottleneck is determined by numbers, not by feelings, so a targeted adjustment of a robot or rule changes the result across the entire flow of requests, not on a single deal.

Lead Distribution Options: Comparing Approaches

Requests can be distributed in different ways, and the chosen mode determines what happens to a lead when all managers are busy, someone has gone on vacation, or a message came at night.

Below are options found in Bitrix24 and their real limitations: you should choose based on the daily flow of requests, the uniformity of inquiries, and the department’s work schedule.

The rules are not mutually exclusive, and in practice they are combined: basic distribution plus overriding by source, a request queue for those who did not fall into any group, and an on-duty person for non-working hours.

The limitation becomes not the mode itself but the absence of a response timer and handover rules — a lead without an owner is lost most quietly.

Implementation Stages: From Pipeline Audit to Handover

Setting up leads begins not with toggles in the interface but with analyzing how a request lives now: where it comes from, who sees it first, at which step it stalls or duplicates.

Most often the bottleneck is not in the tool but in a misaligned process: some inquiries go to messengers bypassing the system, some are recorded twice, and no one can say how many requests were left unanswered.

1. Pipeline audit. We map the actual path of an inquiry by sources and entry points and compare it with the policy. The output is a map with numbers: share of requests without a first touch, time to response, losses at each step.
2. Stage scheme. We design a set of stages for the real deal cycle, not for a template. Each has one clear transition criterion, so the manager does not drag cards manually or choose a stage at random.
3. Fields and distribution. Required card fields, rules for assigning a responsible person, a shared queue, and automatic task creation.
4. Robot setup. We tie automatic actions to events: a reminder during idle time, an email to the client after a stage change, reassignment when there is no responsible person, and a notification to the supervisor about a prolonged stage.
5. Scenario testing. We run each route with a test request, including non-standard ones: repeat inquiry, rejection, return from archive, amount change.
6. Handover and launch. We provide the stage scheme, list of robots, and a short policy for the department. For the first weeks, we monitor the pipeline on live data and adjust rules if a scenario behaves differently than with a test request.

Process Diagrams, Access Rights, and Work Policies

Lead setup is considered complete not when the scenario has worked on a test request, but when the sales department has a set of documents according to which a new manager can start work without calling the implementer.

We take artifacts from the actual configuration, not from the intent: each rule in the policy corresponds to the real behavior of the system.

• Deal process diagram — stages, transition conditions between them, and automatic actions at each: what the system does itself and where a manager’s decision is required.
• Field map — purpose of each field, whether it is required, the source of completion, and the validation rule: you can see where the value comes from and why the field cannot be deleted.
• Manager access rights — a “role × section × action” matrix: who sees other people’s deals, who changes stages, who exports the database, who edits reference lists.
• Request processing policy — response deadlines for each source, distribution order, escalation for overdue items, and rules for closing a deal without a client response.
• Instructions for the sales department — one or two pages in the manager’s language: how to maintain the card, what to fill in manually, and what actions to avoid.
• Rules for duplicates and rejections — how repeat inquiries are merged, what to specify in the rejection reason, and when the lead returns to work.

The set remains with the customer as a living document: it is updated together with the pipeline, so when tasks are handed over to their administrator or another contractor, the logic does not have to be reconstructed after the fact.

Case Study: Request Response Time Decreased Threefold

The sales department kept requests in Bitrix24 as in a general list: inquiries from the website form, emails, and calls fell into one pipeline, and a senior manager distributed them manually in the mornings.

Night and weekend inquiries waited until the next working day, repeated form submissions created duplicate deals, and some emails settled in personal mailboxes.

The share of requests without a response within 24 hours stayed around 18% — and even that was an approximate estimate: records were kept in a spreadsheet.

Where Inquiries Were Lost

The first gap was intake: the form sent an email rather than creating a deal, so the inquiry depended on whether a specific person would open it. The second was distribution: without shift rules, a request could hang on a manager on vacation.

The third was control: the first response deadline was not recorded anywhere, and reminders for a follow-up touch were set manually.

What We Changed

We collected intake from all channels into one pipeline with deduplication by phone and email.

Robots at stages distribute deals according to shift and workload rules, create an automatic task for the first touch with a control deadline, and escalate to the supervisor when overdue. Telephony integration records calls in the card, and inventory accounting pulls in order history.

After two months, the average first response time decreased from several hours to 12-15 minutes, the share of lost requests — from 18% to 2-3%, and missed calls automatically become tasks.

Stage reports replaced the manual spreadsheet: pipeline bottlenecks can be seen in real time rather than at the end of the month.

What to Do If Some Stages Are Already Set Up Manually

Most often the portal is not empty: someone set up stages for a previous department, some robots are already enabled, and some fields remain from previous tasks.

Starting over means stopping sales and losing history, so first we map it: which stages are actually used, where deals stall, and which robots duplicate the manager’s work.

There are few intermediate states, and each has its own procedure.

Next is the transition to automation without stopping the department: we do not delete stages but rename them and close them with permissions, so deal history and reports remain intact.

We transfer deals from retiring stages in bulk, enable robots one stage at a time, and check the result with managers while settings are made on a copy of the portal. We transfer to the production environment only what matched the department’s real work.

If there are several pipelines, we first align the stage logic between them — otherwise robots and reports will count the same movement twice.

Technical Doubts and Frequent Questions About Implementation

Doubts usually surface not during setup but before handover to work: what will happen with repeat requests, who will see extra data, and how to make sure robots trigger. Below are answers to what is most often checked before delivery.

How to limit access rights so a manager does not see someone else’s pipeline?

Rights are assigned by roles and binding to a department: a manager works with their own deals, a department head with consolidated ones, an administrator with all. Operations that break statistics are closed separately: manual stage change, deal deletion, database export.

How to verify that robots actually trigger?

Verification is done on test deals: we run the scenario through the stages and compare the robot log with the change history — whether the rule triggered, whether the notification was sent, whether the task was created.

We look separately at conflicts: two robots at the same stage can overlap, and one may silently fail to execute.

Will deal history be preserved when the pipeline changes?

Yes, if old stages are moved to the archive rather than deleted. Converting a lead into a deal does not erase completed stages, and the change log stores who edited fields and statuses and when — this allows a disputed deal to be reviewed.

Let's Discuss the Task and Come Back with an Estimate and Plan

To come back with a work scheme and a clear estimate, there is no need to prepare a technical specification — just describe how sales are organized now.

The more specific the initial data on the process, the fewer assumptions in the implementation plan and the more realistic the timelines.

• Intake channels: website, email, messengers, telephony, manual entry — which sources are live and which duplicate each other.
• Current pipeline: stage names, what happens at each, where deals get stuck, and at which step the lead actually stops moving.
• Distribution of responsible people: by what criterion a lead goes to a manager and what to do if they did not respond in time.
• Robots and reminders: which emails and tasks are already configured, what triggers at the wrong time or interferes with managers.
• Required fields: what is recorded during qualification so that reporting and stage conversion are calculated correctly.
• Roles and accesses: who changes stages, who needs consolidated analytics, who sees only their own deals.
• Related systems: 1C, telephony, website — where the inquiry history is stored and what should be synchronized.

Based on this data, we will put together a work scheme: a list of stages, a robot map, the composition of fields, and exchange points with external systems.

We will break implementation into stages with testing on one department, so process adjustments are made before the setup goes to all pipelines. Describe the task in free form — we will come back with a work estimate and plan.