Setting up automatic lead creation from Bitrix24 calls

Automatic lead creation from calls: where the process breaks

A call is answered, the manager speaks with the client, but there is no card in CRM. A day later it turns out they agreed on a meeting, but there is nowhere to record it — the request dissolves in the call log.

This is not an accident, but a typical result: telephony and lead creation rules are configured separately, and at the junction the most valuable thing is lost — the inquiry.

The first cause is on the telephony side. The integration is subscribed to the wrong event type and receives notification only about a missed call, not about a completed conversation.

If the channel to the PBX breaks for at least a few seconds, the event is lost without retries, and telephony does not appear in the card — neither recording, nor history, nor duration.

The second is in processing rules. A lead is not created if the number is already in the database: the event is attached to an existing contact or deal where no one expects it.

Extension numbers, internal lines, and calls from unfamiliar directions fail in the same way — the conditions are written for a single scenario.

The third is organizational. Error handling is not assigned to anyone: no one reads the exchange log, and a missed call is made up for by manually creating a lead in the evening, when the client has already chosen another. The loss of a request does not look like a loss — the numbers in reports add up.

We break down what reliable automatic lead creation consists of: from marking up telephony events to processing rules and error control.

What changes after implementation: response speed and lead loss

A lead card appears at the moment the subscriber hangs up: telephony is connected to Bitrix24, the completed call event itself raises the deal and pulls in the call recording, number, and history of previous inquiries.

The manager no longer needs to copy the contact from the log and search for the client in the database — time to first response is reduced from hours to minutes, and no blind spots remain on missed calls.

What becomes measurable after implementation:

• the share of processed calls approaches full, including missed and after-hours ones;
• time to first response is calculated for each deal, not based on the manager's impressions;
• manual operations — creating a card, copying a number, reminding about a callback — leave the department's workflow.

An entire class of failures goes away: a request lost when switching between systems, a client without a callback because the call remained only in the manager's memory, duplicate cards for the same person on a repeat inquiry.

Each such case used to be found already at the stage of 'the client went to another,' now it is visible at the moment it appears.

Call control stops being selective: the recording is linked to the deal, the responsible person, duration, and result of the conversation are specified, so any call can be reviewed, not just the one that happened to be monitored.

Inquiry processing speed and lead loss become metrics against which a target can be set and its fulfillment checked. Below is how this is configured for your request processing workflow.

Ways to connect telephony with the card: comparison of options

There are four options for connecting telephony with the card, and the choice is determined by how much your qualification logic differs from the standard one.

Standard processing rules cover most cases and start working immediately after the number is connected, but they reproduce only the conditions built into the settings: call direction, answered or missed, assignment to a responsible person.

As soon as a composite condition appears — for example, a repeat call with an identified number within 24 hours — a separate scenario is needed.

Below is what each option provides and where it hits limits; the table rows are not mutually exclusive.

The working scheme is usually built on standard rules, supplemented by a scenario for your logic, and necessarily includes a backup mode. Exchange with an external PBX is chosen when the station is already deployed and there are no plans to change it.

Work order: from analysis of current calls to handover to support

We start with a telephony audit: we look at call statistics by numbers and lines, find missed and short calls that currently do not turn into leads, and record who is responsible for processing inquiries. Without this, the routing scheme will produce duplicates and lost cards in Bitrix24.

1. Audit of calls and responsible persons. We export the call history, mark up typical scenarios — inbound, missed, returns — and agree on which employee or group takes each type of inquiry.
2. Routing scheme. We draw the call path: line and extension number, distribution rule, pipeline and stage into which the card goes, set of required fields.
3. Setting up lead creation rules. We link card creation to the call event, set the responsible person, source, inquiry subject, and links to the contact and company.
4. Duplicate protection. We set up matching by number: a repeat call is appended to the existing card or deal rather than creating a new record.
5. Testing on real calls. We run scenarios from different numbers, including missed calls and transfers between employees, and verify the result in the call log and cards.
6. Employee training. We show managers what processing now looks like and what to do with inquiries that the system did not recognize automatically.
7. Handover of documentation to support. We provide the routing scheme, list of rules, and change regulations; further edits to fields and logic go through support.

What remains with you: settings, schemes, and regulations

After handover, the customer's environment retains not only a working scenario but also a set of documents by which it can be maintained without us.

This is fundamental: rules that live only in the interface and in the contractor's memory break at the first change of responsible person or the first non-standard situation on the line.

Each artifact closes its own failure point — from a disputed call on the operator's side to editing a trigger condition. Below is what you receive as files and settings, not a verbal retelling.

• Scenario map: which Bitrix24 events create a lead, under what conditions an inquiry is assigned to the first responder, and what goes to rejection.
• Call flow diagram — from inbound to the line to recording in the card, with points where processing may break and a description of behavior on disconnection.
• Inquiry processing regulations: response times, escalation procedure for unsuccessful calls, rules for repeat calls and duplicates.
• Responsibility matrix and operator access rights: who sees and changes fields, who approves edits to rules, who has access to the log.
• Operator instructions: step-by-step analysis of a typical call and disputed cases — missed call, inquiry from an existing client, after-hours call.
• Change procedure: how an edit is tested in a test environment, who confirms it, and how to roll back to the previous version of the rules.
• Check log — test runs, control of duplicates and inquiries that did not reach the card.

Documents are updated together with settings: if a condition or responsible person changes, the regulations and instructions are edited in the same order.

Case study: how the call flow stopped getting lost at peak load

The client is a service company with a sales department of 14 people and two call intake lines. Inquiries were created manually: an operator listened to the recording, wrote down the number, and passed it to a manager.

Peak load occurred in the morning — more than a third of the daily flow came in within an hour, and the processing queue was not cleared until evening.

What the measurement showed

Over two weeks of observation, we calculated: about 17% of inbound calls never became leads — some were lost during handover between shifts, some remained in the log without an answer.

First contact with the client occurred on average after 40 minutes, and during peak hours — after several hours, when the person had already called another contractor.

What was changed

Telephony was connected to Bitrix24 and automatic lead creation was configured: the system creates a card based on a completed call, pulls in the call recording, number, responsible person according to the distribution rule, and inquiry source.

Missed and unrecognized calls go to a separate duty queue — the call does not remain without an owner.

Metrics before and after

The share of inquiries converted into leads grew from 83% to 99%, and time to first contact decreased from 40 minutes to 3–5 minutes.

Peak load stopped being a separate problem: calls are distributed according to rules, and the duty officer sees only what requires manual resolution. The sales department's workload became more even — manual log review took about two hours a day and left the process.

How does a standard rule differ from a separate processing scenario?

A standard rule in Bitrix24 is a ready-made handler for the completed call event: it creates a lead by number, substitutes the responsible person according to the distribution rule, and transfers fields from the contact card.

Trigger conditions are set by portal settings: call type, attachment to an existing contact or creation of a new entity, required fields.

A separate scenario is your own handler that receives the same payload but makes the decision itself.

It branches logic by source, campaign tag, conversation duration, history of previous deals, and extension number, and before creating a lead it checks duplicates across several fields at once, not only by phone number.

The boundary of choice runs along the homogeneity of the flow. If calls come from one direction and the card fields are sufficient, a standard rule is enough — less code and fewer failure points.

As soon as exceptions appear — forwarding, multiple lines, different pipelines for one number — without a scenario some inquiries remain without a lead.

We start with a standard rule and record which branches it lacks; we move to a separate scenario when the list of exceptions no longer fits into the settings.

Frequent technical questions about telephony and cards

We collected the questions that most often come up before enabling automatic lead creation: some about the logic of matching numbers, some about the platform's boundaries themselves.

Below are short answers on the mechanics, so it is clear what is configured for your process and what hits limitations.

Disputed points — a repeat call and the choice between a new deal and an already open one — are closed by routing rules, not by a 'default' setting. Therefore they should be discussed before launch, otherwise managers will get duplicates.

How is the call distributed between a deal and a new inquiry?

By stage and responsible person. An active deal at the negotiation stage takes the call for itself — this keeps the communication history and call recordings in one place.

If the deal is successfully closed or lost, the call goes as a new inquiry, otherwise the deal cycle metrics cease to be comparable.

What happens when changing the telephone provider?

The routing scheme, distribution rules, and cards remain; only the connection point and access keys change.

The procedure is as follows: configure the new operator, run test calls on a closed number, verify that the lead, recording, and responsible person are set correctly, and only then switch the main traffic.

Which platform limitations should be taken into account?

Three main ones. The platform limits the frequency of requests to its software interface — under peak load we set up a queue and retries with delay so the call is not lost. Call recordings are stored for a limited time depending on the plan, so we move copies to external storage.

And some operators do not transmit the caller's number — such calls come in as unknown and require manual review.

Let's discuss your scenarios and come back with a work plan

To come back with a timeline estimate rather than general words, we need a minimum of context. Describe which calls should become leads: inbound, missed, individual numbers, or entire lines.

And separately — by what criterion to consider a lead already created: not duplicating the inquiry here is more important than speeding up its appearance in the pipeline.

Then we proceed step by step:

• we analyze the current telephony scheme and how calls get into Bitrix24 today;
• we record the scenarios: which events create a lead, which fields are filled automatically, which remain for the operator;
• we agree on linking the call recording and responsible person to the card;
• we describe behavior during failures — unavailable line, repeat call, inquiry from an existing client;
• we prepare a work plan: stages, checkpoints, procedure for enabling in production;
• we assemble the set of materials to be handed over — routing scheme, set of rules, operator instructions, rollback procedure;
• we conduct acceptance testing on real calls and close discrepancies.

From you we need access to the admin area, a test line, and a person who confirms the distribution rules: without them, approval will drag on for weeks.

Describe the scenarios as a list or a recording of the analysis — we will come back with a work plan, timeline estimate, and list of materials.