Why the Bitrix24 sales generator does not bring in leads
Inquiries from the website form, email, messengers, and telephony arrive reliably, but they do not make it to the deal.
The Bitrix24 sales generator is not an "enable" button but a combination of distribution rules, robots at stages, and event triggers: a new lead, a missed call, a repeat inquiry.
When the combination is half-assembled, inquiries fall into a common list without an owner and cool down — they are lost in the funnel, although from the outside the flow looks functional.
The second typical cause is manual processing of leads and delayed first response. A manager sees the notification when they become free, sets a task without a deadline, and responds several hours later or the next day.
During this time, the client manages to write to three contractors, and the conversation starts from a catch-up position.
This is not treated with persuasion but with configuration: an auto-reply in the first minute, a task with a strict deadline, escalation to the manager when overdue, and automatic raising of the card to the top.
The third failure is quieter and therefore more expensive — a dormant customer base. Segments by last deal date, industry, or activity are not assembled, repeat touches are not launched, and contacts built up over years just sit there.
A segment of "have not purchased for more than six months" and a two- or three-step scenario are enough to return part of the revenue without new acquisition costs.
These are three different failures with different symptoms but a common outcome: part of the flow does not reach the deal. Below we break down how this is closed through configuration — from fields and stages to robots and reporting.
What a configured Bitrix24 delivers: measurable effects
In Bitrix24, customer segmentation turns a common funnel into a set of separate routes: new leads, repeat inquiries, and dormant deals follow different rules.
Robots in the funnel themselves assign an owner, set a deadline at the stage, and insert an email template — the deal stops depending on whether the manager remembers the next step.
First response speed is measured in minutes instead of hours. The inquiry immediately goes to the on-duty person, and if there is no reaction within the allotted time, the task goes up the chain.
The share of processed inquiries approaches 100%: the report shows every one, including those that previously settled in email and messengers.
Reactivation of the dormant base works on a schedule, not according to the manager's mood. A reminder goes to a customer who has not been in touch for a long time and is based on their past purchase history. Deal recovery becomes a constant flow rather than a one-time mailing to the entire list.
A separate effect is an eliminated class of losses: deals without a next step and inquiries without an owner. Rules close them before they get into the stage failure report.
Repeat sales grow on reminders about service expiration or consumables — the share of customers with a second order increases by one and a half to two times.
How segments and robots are built: comparison of approaches
A segment is not a contact list but a rule by which the list is rebuilt. Hence the difference in approaches: manual segments maintain precision, automated scenarios provide coverage, and hybrid mode removes the limitations of the first two.
| Approach | When it fits | Where it breaks |
|---|---|---|
| Manual segments | Small base, one-off campaigns, non-standard selections | Fields in cards change — the selection becomes outdated; support grows along with the base |
| Automated scenarios | Mass repeatable actions by trigger | Robot cascades, duplicates when re-entering a stage, no owner responsible for the result |
| Hybrid mode | Live base, different customer types | A regulation is needed: what the robot closes and what remains with the manager |
Robot launch conditions are set in three ways: changing the deal stage, changing a card field, or expiration of a period without activity. The main risk is a cascade: a robot changes the stage, this triggers the next robot, and the chain goes into a loop.
Therefore, the scenario explicitly specifies the entry point, the order of steps, and the stop condition, and repeat launch is blocked by a service flag on the record.
Hybrid mode relies on role separation: the robot is responsible for timeliness and coverage, the manager for decisions that cannot be formalized.
Segments are assembled automatically by fields, but the campaign is launched manually — this excludes mailings to an erroneous selection.
Configuration stages: from funnel audit to handover
Configuring the sales generator is not enabling a ready-made module but assembling rules for a specific funnel and the data already accumulated in it.
The order of stages is fixed: robots set up before the segment map begin to duplicate tasks and clutter the deal history, and this then has to be sorted out manually.
- Funnel audit. We analyze stages, sources, reasons for refusal, and points where deals hang longer than usual. The output is a list of bottlenecks with figures: share of abandoned leads, time to first response, conversion between stages.
- Segment map. We mark customers by source, stage, purchase history, and activity. Each segment has an explicit entry and exit condition; otherwise automation begins to treat new leads and old customers the same.
- Robot configuration. We attach rules and triggers to transitions between stages: auto-tasks, reminders, owner distribution, messages to the customer. We check that with a missed call or refusal, the lead does not remain without action.
- Test run. We run scenarios on a copy of the funnel: duplicates, repeat inquiries, refusals, long pauses. We look at the trigger log and correct conditions that generate extra notifications.
- Result measurement. We compare indicators before and after at the same stages: response time, share of deals returned to work, manager workload.
- Handover of settings. We provide the robot scheme, amendment regulations, access rights, and instructions for employees. We train the team and record which changes need to be coordinated so the logic does not diverge.
Documentation, access rights, and regulations at the output
After launching the sales generator, the client retains not only a working funnel but also a set of documents by which it can be maintained and developed without our team.
Each artifact captures a specific decision in the configuration — what exactly moves a deal to the next segment, who has the right to edit robots, and according to which scenario "cooled" customers are returned. Below is the list of what we hand over at the output.
- Funnel scheme — stages, order of transitions, composition of segments, and conditions for entering each of them, including exceptions (returns, duplicates, refused deals).
- Robot documentation — a table for each robot and trigger: trigger condition, action, message template, employee responsible for reacting to the result.
- Access policies — role matrix: who changes stages manually, who edits robots and segments, who sees customer base exports, and who has read-only access to their own deals.
- Reactivation regulation — by what criteria a deal is considered cooled, how often a touch is launched, how many attempts are made, and at which customer response the cycle stops.
- Sales department instruction — short scenarios for each segment type: how to take a lead, what to answer to an objection, where to record the reason for refusal so that it is taken into account in subsequent touches.
- Integration map — which systems the funnel exchanges data with (telephony, email, order accounting) and which fields are synchronized in both directions.
- Amendment regulation and change log — who approves a logic change, in what order it is rolled out, and how it is rolled back if the conversion indicator drops.
- List of acceptance checks — a set of test deals that are run after each edit of robots or segments.
We keep documents in your environment — a knowledge base or internal repository; access remains with you. During handover, we review the regulations with employees and show how to make a change without affecting neighboring scenarios.
Case study: reactivation returned leads from the dormant base
A retail chain with a base of about 40 thousand contacts: website leads fell into one funnel without sorting, managers reached about half, and customers who had purchased earlier did not receive repeat offers.
The analysis showed that the bottleneck was not the flow of inquiries but the absence of segments and rules for reacting to an event.
What the measurements showed
| Indicator | Before | After |
|---|---|---|
| Share of processed inquiries | 41% | 96% |
| First response time | 9 h | 18 min |
| Return from dormant base | 2% | 17% |
| Repeat sales | 11% | 28% |
| Conversion to payment | 6% | 11% |
| Deal cycle length | 34 days | 21 days |
What was changed
In Bitrix24, segments were marked by activity and source: fresh inquiries, cooled without response, previous buyers, refuseniks with a specified reason.
A dedicated robot was assigned to each segment — new leads receive an instant response, the dormant base receives a warming series with a step of several days, and refuseniks receive a message with new value instead of a repeat "we are calling about your inquiry."
The key turned out to be the escalation rule: if the first response is not sent within 15 minutes, the task is automatically raised to the manager.
The share of processed inquiries doubled, the base stopped being a warehouse of unprocessed leads, and returning customers provide about a third of repeat sales.
What to do if some robots are already configured?
A partially configured funnel is a working state, not an emergency: scenarios were set up for department tasks at different times, and some of them reference fields that have not been filled for a long time.
The first step is inventory: we export all robots by stages and look at where launch conditions overlap, where two automations write to the same field, and where a deal hangs without a task.
Next comes rebuilding the funnel on a copy. Existing scenarios are transferred as is, duplicates are collapsed, and the order of robots is arranged so that the task is set before the stage change, not after.
We do not touch the working funnel until the switch — sales continue according to the proven scheme.
Migration of settings proceeds in portions by stages, not as a single "switch everything": after each portion, we check the trigger log and the list of deals that passed the stage in a day.
If a robot did not trigger or triggered twice, the edit is rolled back in a targeted way, and the rest of the logic continues to work.
Inherited segments are a separate story. They often overlap with each other and are assembled by fields that have stopped being filled, so deals fall out of automation unnoticed.
We do not delete such segments but rebuild the conditions by fields that are actually filled and check coverage: how many deals actually fall into each segment.
Working without stopping sales relies on three things — edits on a copy, switching outside working hours, and control metrics before and after: first response time, share of deals with a task, conversion between stages. If the metrics did not drop during the control period, the scenario is accepted as the main one.
What is clarified before start: technical doubts
Before the start, we fix the scope of work: which accesses are needed, what we consider a finished result, how the system behaves after launch. Below are the questions most often asked and the places where risks usually hide.
How long does configuration take?
The basic outline — segments and robots for first response — is assembled in a few days. The full one, with base reactivation and exchange with external systems, takes from two weeks: the timeframe depends on the number of channels and data cleanliness.
What rights are needed for configuration?
We work under a separate account with rights only to CRM, robots, and business processes. After handover, we transfer access to your administrator and record in the scheme who can edit segments and logic.
How is consent to mailing taken into account?
We store the consent flag in a separate contact field along with the source and date. Without confirmation, the contact does not enter the mailing; unsubscription is processed automatically and blocks repeat sending.
How to exclude duplication of inquiries?
We merge contacts by normalized phone and email, search by messengers and website forms. Before creating a deal, the robot checks active ones — a repeat inquiry goes into an already existing card.
What is included in support after launch?
We monitor robot logs and the task queue to catch failures before the sales department does. After platform updates, we run scenarios on a test environment and adjust the logic for new conditions.
Let's discuss the task: what inputs are needed to start
Segments, robots, and reactivation scenarios cannot be assessed "by eye": the scope of work depends on the state of the funnel, reference data, and access rights.
To come back with a work plan and estimate, rather than a range "from and to," a short set of inputs is needed to start work.
- Funnel scheme: stages, owners, rules for deal transition between stages.
- Segments and card fields: by what criteria to divide the base — source, industry, deal age, amount, activity.
- Reactivation triggers: events by which the robot returns a customer to work.
- What is already configured: robots, business processes, email templates — so as not to duplicate logic.
- Accesses and roles: administrative access to the portal, rights to configure robots, list of employees affected by the scheme.
- Base volume and quality: how many deals and contacts, share of duplicates and empty fields — hence the number of segments and processing speed.
- Communication restrictions: mailing consents, time zones, prohibited hours.
- Success criterion: share of returned deals, robot trigger speed, number of touches before response.
With administrative access and these inputs, we go through the funnel, count the number of scenarios and robots, and note what will have to be cleaned up before configuration — that is how the scope estimate appears.
Describe the task and attach what you already have: we will return with an estimate and plan for your sales generator.