Setting up call recording in Bitrix24: cloud PBX and SIP trunk

Conversations with clients get lost: agreements have nothing to confirm them, disputed situations have nothing to review. We set up call recording in Bitrix24 turnkey — from telephony audit to access rights and review procedures. The share of conversations left without recording drops to zero.

Our competencies:

Frequently Asked Questions

Call recording in Bitrix24: where conversations get lost

Most often, conversations disappear not at the moment of the call but earlier — along the routing path. A call passes through an external line, the operator's SIP trunk, a distribution rule, and only then reaches the CRM card.

If recording is disabled on at least one of these nodes, or a rule routes the call around the scenario, no file will appear — while the call itself will remain in reports.

The second source of losses is the storage side. A cloud PBX keeps audio on its side and hands it to telephony in the CRM only when synchronization is enabled.

Disable the export or change the operator's terms — and the deal will retain a call entry without a recording, even though the conversation happened.

A separate case is transferring a call to an extension: recording starts on the first line and stops as soon as the conversation goes to another branch.

The cost of such gaps is higher than it seems. Call quality control turns into listening to what survived, a disputed situation with a client cannot be confirmed, and a new manager has nothing to train on — the archive ends up with random conversations instead of a system.

That is why call recording in Bitrix24 is set up at the scheme level: it is enabled on the line, routing rules, transfers, and queues are checked, and storage is moved to the card, where audio is linked to the deal and the responsible person.

Next, we break down how this works step by step: where exactly recording is enabled, how it reaches the CRM, and what to do if conversation recordings disappear after setup.

What changes after setup: control and review of inquiries

A call archive instead of folders with files

Every conversation from the cloud PBX is automatically linked to the client card in Bitrix24 and stored for a specified period — from several months to several years, according to the adopted retention policy.

Search is by number, responsible person, date, or deal stage: the query "find the conversation where delivery timelines were discussed" works in seconds instead of half an hour of going through files on a disk. Recordings are not lost when an employee leaves or the work number changes.

Evaluating managers by calls on real data

A manager listens not to selective "showcase" conversations but to a sample by criteria: interruptions, long pauses, conversations shorter than a minute, absence of a question about the client's task.

Such a sample shows exactly which step the dialogue breaks at, not just the funnel result. Reviewing three to five calls per employee per week removes the dispute "the client didn't want to" — there is a recording, there is an answer.

Reviewing inquiries and sales department control

Linking the recording to the deal stage shows where inquiries are lost: how many calls remained without a substantive answer, how many ended without an agreement on the next step.

The share of reviewed inquiries stops being an "eyeball" estimate — it is calculated from the log. And a whole class of disputes with a client goes away: a quote from the conversation closes the issue in a minute.

Connection options: provider PBX and your own trunk

A conversation can be recorded at three points: at the telecom operator, on your own station in your perimeter, or inside Bitrix24, if the stream goes through the standard connector.

The recording point determines where the file physically lands, what format you get, and what happens to the recording if the connection to the cloud drops.

Where the file physically lands

Option Where the conversation is recorded When it fits Limitations
Cloud PBX, provider connection On the operator's side; the file arrives in the card ready-made No own station, need fast launch, one contract for communications Retention period and format are set by the provider; some routing settings are unavailable
Your own SIP trunk to the provider, recording on your station On your server; a link to the file goes into the card Requirement to keep conversations within your perimeter, non-standard call flow A channel, server, and its maintenance are needed; the link to the card is configured separately
Mixed scheme External lines — at the operator, internal — locally Call center with a large volume of internal calls Two storage points; a single output to the employee interface is needed

What to consider when choosing

External telephony via a provider relieves you of station operation but ties you to its policy: stream compression, channel splitting, file lifetime.

Your own trunk gives control over routing and storage but requires a backup channel — if the trunk goes down, recording of external calls is simply not created.

In practice, the mixed option is more often chosen, and then both points are brought into one feed in the deal card so that the manager does not search for the recording in two places.

Work sequence: from telephony audit to access handover

We structure the work so that the existing telephony does not go down for a single working day: we set up new lines in parallel, switch over during quiet hours, and run all call scenarios before the switch. Below is the sequence by which call recording implementation proceeds.

  1. Survey of the current scheme. We collect the composition of numbers, providers, queues, and groups; we look at where conversations are already recorded, where they are partially recorded, and where they are lost during transfers between employees.
  2. Routing scheme design. We fix which lines and directions go to recording, in what form the archive is stored, and how rights are divided: who hears the recording, who sees only the fact of the call.
  3. Telephony and recording setup. We connect the cloud PBX or SIP trunk, enable automatic recording, link it to deal and contact cards so that the file appears in the CRM immediately after the call ends.
  4. Test verification. We make a control call for each scenario — inbound, outbound, transfer, hold, missed — and compare the duration and quality of the file with the actual conversation.
  5. Switch to new lines. We switch numbers in stages and keep the old ones in reserve until it is confirmed that all traffic goes through the new scheme without losses.
  6. Employee training. We show how to find a recording from the card, how to export it for review, and what to do in a disputed situation with a client.
  7. Handover to operation. We hand over access to the owner, the routing scheme, the retention regulation, and the change procedure — so that edits do not break recording.

Documentation, schemes, and regulations for working with telephony

Telephony assembled "from memory" survives until the first personnel change: the administrator leaves — and no one knows why part of the lines are not recorded.

Therefore, along with recording setup, we hand over a set of artifacts by which the configuration can be restored, expanded, or transferred to another contractor without us.

  • Connection scheme — cloud PBX, SIP trunk, extensions, inbound line routing, and the points where call recording is enabled.
  • Recording settings map — which lines are recorded, automatically or by button, where files are stored, and how they are linked to the client and deal card.
  • Access rights matrix — which employees hear all recordings, who only their own, who can export the file, and who is denied listening.
  • Retention regulation — recording lifetime by call type, the moment of automatic deletion, and the procedure for export for a client request or internal investigation.
  • Employee instructions — how to enable recording in the call card, find the needed conversation, and share a link within the system.
  • Administrator instructions — where to create a new employee, how to reassign an extension, and what to do if recording stops appearing.
  • Change log — what edits were made to telephony, by whom, and on what basis.

Such a set is updated with every change to the scheme or regulation. As a result, the solution remains manageable: staff expansion, a change of responsible person, or migration to another PBX does not turn into a project to restore call history.

Project breakdown: metrics before and after setup

Before: where conversations were lost

Project: sales department telephony — a cloud PBX is connected to Bitrix24, but recording was uneven. Some lines went through a SIP trunk without auto-start recording, and conversations received on a mobile and transferred to an extension did not get into the archive.

The export recorded about two-thirds of conversations; the rest were reconstructed from the call log — on average 15–20 minutes per incident.

What was changed and what was achieved

We brought the lines into one scheme: recording starts on the cloud PBX side, not in the employee's application, so it does not depend on the answering device.

We added auto-start on transfer to an extension and on an inbound call to a group, configured recording storage and access separation — the recording is seen by the manager and the owner of the deal card, not the whole company.

The share of recorded conversations reached 100% for inbound, outbound, and transfers. Recording search is done from the deal card and takes seconds instead of a quarter of an hour: the file is linked to the lead and deal, rather than searched by call time and number.

The speed of resolving disputed situations changed the most.

Previously, a client complaint turned into correspondence with a search for traces of the conversation; now the review is one run-through of the recording, and call losses are visible in the report: how many calls were not answered and at which stage.

How the cloud PBX in Bitrix24 differs from a SIP trunk

A cloud PBX records the conversation on its side: the audio file arrives in the call card ready-made; no separate server or disk space is needed.

The price for convenience is dependence on the plan: retention period and access to download and export are set by the provider, not by you. For a small department, this is enough — enable it in the settings, and it works.

Your own SIP trunk flips the scheme: your PBX or gateway does the recording, and a link to the file goes to Bitrix24 along with the conversation card.

Storage, encryption, and recording lifetime remain under your control — this is critical when conversations cannot leave the perimeter or the retention period is set by regulation.

The cost is configuring the link: matching extensions, the file name format, and delivering the recording over a secure channel.

A hybrid scheme is more common than it seems: headquarters on a cloud PBX, remote locations and the call center on their own trunk. Then routing decides where a specific call is recorded, and the call card must open the same way in both cases.

Here it is important to agree on a single format in advance — otherwise some recordings will not link to the deal.

The choice of option comes down to three questions. Where the materials physically reside and who is responsible for their safekeeping. How many conversations per month and how long to keep them. Whether there are requirements to keep recording within your own perimeter.

The cloud wins in launch speed, your own trunk in control, and the hybrid covers a distributed structure.

The answer determines not only the recording point but also fault tolerance: what happens to the file if the conversation is cut off in the middle, and how to retrieve the recording from the archive months later. This is what determines which scheme will form the basis of the setup.

Technical concerns: storage, access, and stability

Concerns about call recording are almost always resolved by settings, not by code modification.

Below are answers to what most often comes up at the acceptance stage: how long a recording lives, who sees it, why some calls ended up without a file, and how this works for employees outside the office.

How long are recordings stored, and what happens when space runs out?

The retention period is set by policy: recordings can be kept for six months, a year, or longer. Rotation deletes the oldest on a schedule, so storage volume grows predictably, not avalanche-like.

If an archive beyond this period is needed, we configure automatic export to your storage, where the deletion rules are already yours.

Which employees can see and download a recording?

We assign access by roles: a manager hears only their own conversations, a department head — their group, management — all lines. Listening and downloading are logged, so it is always visible who opened the file and when. We separately block external export so that the recording cannot be taken out with one click.

Why are some calls not recorded?

Usually recording is enabled on some lines and remains disabled on others — hence the gaps. A missed call does not create a file; only a mark about it remains in the card.

At acceptance, we go through each number separately: inbound, outbound, internal, and transfers between employees — and enable recording where it is actually needed.

How are calls from the mobile app recorded?

The conversation is recorded on the telephony system side, not on the phone itself, so the file arrives in the client card the same way as when calling from the office.

With poor connectivity, the recording is saved until the moment of the drop; the missing fragment cannot be restored — this is visible by the duration. The employee only needs the work application and network access.

Let's discuss the task and come back with an estimate and plan

For the estimate to be substantive rather than approximate, a little input is needed: what telephony is currently in use — a cloud PBX or your own SIP trunk, how many lines and employees, where recordings should be stored, and under what regulation access to them is granted.

If telephony is already connected, access to the settings and a description of the current routing are enough — we will capture the rest ourselves.

In response, we send:

  • an estimate of work by stages: recording connection, access rights, verification on real calls;
  • an implementation plan with the order of steps and the points where your acceptance is needed;
  • the scope of work — what we cover, what remains on the side of the telecom operator or portal administrator;
  • the call routing and recording storage scheme: where the file appears, how long it lives, what happens when a line is disconnected;
  • the list of roles and accesses that need to be granted before the start, with the boundaries of recording visibility by department;
  • the telephony support regulation: what is included in maintenance, how we respond to a recording break, and how settings change when employees rotate.

Describe the task in two or three paragraphs — about the current telephony, the number of lines, and access requirements.

Let's discuss the task in detail: we will come back with an estimate and implementation plan, and we will work through the disputed points before the start of work so that the setup does not surface as a bottleneck already in production.