Connecting a SIP Trunk to Bitrix24: Guide and Configuration

SIP trunk Bitrix24: why calls get lost in the sales department

A typical breakdown looks like this: the Bitrix24 SIP trunk is connected, calls go through, but they are absent from customer records.

The manager takes the call on a personal phone, missed calls are not assigned to anyone as responsible, and the pipeline is filled only with what the sales rep entered manually after the conversation.

The reason is almost always that Bitrix24 telephony setup is half done. Incoming routing works, but number-to-contact matching is not configured — and telephony is not linked to records: the system sees the call but does not know which client to attribute it to.

The line is assigned to one employee instead of a queue, and there is no forwarding rule for no answer, so the call goes into the void.

Duplicates are the second symptom. If the trunk is created twice or an extension overlaps with an internal number, one conversation creates two records: the call report shows more than there were, and the client's history is spread across two records.

Call recordings are lost in the process, and it is no longer possible to assess the department's performance from them.

The cost of such a configuration is lost calls to the sales department that the manager does not see. The report shows the call flow, but not missed calls: what went past the line is simply not recorded in it.

We explain how this is closed — from trunk registration to linking records and monitoring missed calls.

What connecting telephony to customer records provides

The classic "call to a personal mobile" scheme relies on the manager's memory: the incoming call is recorded only in the phone log, the conversation history is in their head, and there is no way to check whether the client was answered.

Requests that came after working hours or while the line was busy simply disappear from view. Let's look at how this is closed when calls go through a SIP trunk inside the CRM.

An incoming call arrives at the SIP trunk, and the Bitrix24 switch matches the caller's number against the contact database and opens the required record itself — a lead, contact, or deal.

Automatic call linking also works in reverse: dialing from a record creates a call activity with duration, responsible person, and result. The manager does not need to create anything manually — technically, there is nowhere for a call to "go nowhere."

Call recordings are stored alongside the same activity rather than in an archive on a shared drive, so call quality control becomes a filtered selection: deals without a next step, conversations where the client stated a condition that did not make it into the comment, objections at a specific stage.

The manager listens to the call directly from the record, without exporting and matching recordings with the CRM.

Next, a unified request pipeline works: incoming, outgoing, and missed calls go into one system, so end-to-end request analytics is calculated by the same rules, rather than from exports from the operator's portal.

It is visible how many requests reached a deal, at which stage they drop off, and which source brings clients who actually pick up the phone.

The measurable effect is in three things. The share of requests that previously settled in personal phones stops being lost: every missed call remains a task in the CRM. The manager frees up hours for summaries — reports are built from call activities, not from a manual log.

And a whole class of objections — "no one called us back" — goes away, because the fact and reason for a failed call are recorded automatically.

Options for connecting a SIP trunk to Bitrix24 and their limitations

Bitrix24 works with any SIP provider, but not every scheme provides the same set of capabilities: in some cases call recordings are lost, in others — routing by department.

The choice between cloud telephony, your own PBX, a virtual station, and simple number forwarding determines what you can do with a call after it arrives.

What to check before connecting

In practice, it is often not telephony itself that gets in the way, but a lack of synchronization: forwarding sends calls to mobiles, and the lead record retains neither a recording nor duration.

Before setup, we check the limit of simultaneous channels, codec negotiation, port availability, and whose side fault tolerance is on — this determines whether telephony will survive the failure of a single node.

Stages of telephony implementation: from audit to handover

Telephony implementation in Bitrix24 is a sequence of work where each step relies on the result of the previous one. If you skip the number inventory audit, the routing scheme will be assembled "as it happens" and will have to be redone after the first calls. The order in which we run the project:

1. Number inventory audit. Inventory: how many numbers, which directions, who owns them with the operator, how calls currently flow — through the office PBX, a softphone, or forwarding from a mobile.

2. Routing scheme. Where the incoming call goes — to a group, an employee, or an IVR; working and non-working hours, behavior when all lines are busy, separate branches for existing clients and new requests.

3. Call distribution rules. Queues and priorities, the logic "whoever is free gets the call," waiting time limit, transfer to the manager on a missed call. Call recording and its retention period are also configured here.

4. Trunk connection and CRM integration. We register the operator's data, assign numbers to employees, enable the customer record on an incoming call, and create a request for a missed call.

5. Test scenarios. Incoming during working hours, a night call, a busy line, a connection drop, transfer between departments, an outbound call with number substitution — we verify each against the recording and reports.

6. Handover to operation. We provide the route scheme, call handling regulations, and access, show employees how to work with the record and history; after that — support.

Routing schemes, access policies, and working documentation

After the SIP trunk launch, the customer should retain not only a working number but also a set of artifacts by which the system can be handed over to another administrator, expanded without rebuilding from scratch, or have a change rolled back. Below is exactly what is included in the deliverables based on the results of the work.

• Connection diagram — the call path from the operator to the queue and extension, with marked failure points: where the call is lost when the trunk is unavailable and which route picks it up as a backup.
• Access policies — which directions are allowed and prohibited, time and duration restrictions, rules for external and long-distance calls, so that the trunk does not turn into an open channel.
• Employee role permissions — a matrix for the roles of operator, department manager, and administrator: who can access call recordings, statistics, route changes, and history export.
• Call handling regulations — what to do with a failed call, a missed call, a stuck call, how transfer between departments works, and at what point recording starts.
• Administrator guide — how to add a number, change a route, check trunk status after a failure, and avoid losing current settings during edits.
• Telephony configurations — export of settings so that the scheme can be restored on another portal or after a failure without manually repeating all parameters.
• Operator cheat sheets — short scenarios for frequent actions: transfer, hold, conference, callback, behavior when the connection is lost.
• Change log — what changed the route and when, who made the edit, and how to return to the previous version if the new scheme failed.

Such a set removes dependence on a specific contractor: the system can be developed with your own resources or handed over to a new administrator without restoring the logic from memory.

Case study: how the sales department stopped losing incoming calls

A sales department of 14 people received calls on two landline numbers and the manager's mobile.

Calls were distributed blindly: while one manager was on a call, the client listened to ringing and called a competitor back, and requests from messengers piled up in one employee's personal window.

Record-keeping was done partly in a notebook, partly in a spreadsheet, so linking a conversation to a deal after the fact was rarely possible.

What was changed

Connecting telephony to Bitrix24 was reduced to three steps: the SIP trunk was registered on the portal, numbers were separated by department and working hours, and call distribution was built on a queue with the rule "first available, priority to the manager who already handled this client." Every incoming call opens the request record or the found deal, the conversation recording is attached automatically, and a failed call returns to the queue with a callback task.

Metrics before and after

• share of missed calls: 31% → 4%;
• response time to a messenger request: 2-3 hours → 10-12 minutes;
• share of calls with recording and link to a deal: about 20% → 96%;
• operator workload leveled out: the spread between managers was cut in half, some calls went to the queue and automatic responsible person selection.

Three months after launch, the manager saw the pipeline in full: how many requests came in, how many were closed, where money is lost. The department stopped arguing about who picked up the phone — they argue about who handled the conversation better.

How does cloud telephony differ from your own PBX?

The difference is in one thing: where the connection logic resides and who is responsible for failure. In a cloud PBX, line registration lives with the operator — you maintain the channel and routing, and the call goes into Bitrix24 and the customer record.

Your own PBX does not depend on someone else's infrastructure, but every failure — power, media, update — is yours.

The cloud is vulnerable in one place — the internet channel: a single provider turns its outage into the loss of all communications. This is addressed by a backup channel and automatic route switching.

Your own PBX is vulnerable more broadly, so communication redundancy here is a combination of a backup channel, forwarding to mobiles, and a recovery procedure.

Total cost of ownership is structured differently: in the cloud, expenses are tied to the number of lines and workstations, but there is no server room or administration; with your own PBX, the investment is fixed, but licenses, media, and engineer hours are added. Scaling in the cloud is a one-day task; with your own PBX it runs into licenses and ports.

In practice, the hybrid more often wins: external lines with the operator, scenarios and recordings in-house.

Technical concerns before connecting telephony

Before connecting telephony to Bitrix24, customers ask the same questions — and that is normal: telephony affects real customers, not a test bench.

Below are answers to the engineering objections that most often slow down launch: changing operators, channel disruption, communication quality, and responsibility for the result.

What happens if the primary communication channel goes down?

We set up a backup communication channel — a second operator or a separate physical input. Routing rules in Bitrix24 do not change: when there is a disruption, calls automatically go through the backup, and the customer record and conversation recording remain in place. We verify the scenario's operability by simulating a disruption, not by promises.

What if complaints about communication quality arise?

Quality is determined by the channel, codec, and network load. During setup, we collect statistics on loss and delay, put voice in a separate queue and set priority, and select a codec for the actual bandwidth.

If complaints arise later, we analyze the logs: it is visible at which segment packets are lost and what to change — the channel, a setting, or the scenario.

Who is responsible for communication after launch?

We are responsible for telephony setup, routing, scenarios, and CRM integration; the operator is responsible for channel quality up to the connection point.

We record the division of responsibilities in the scheme and incident response regulations, so that during a failure we do not look for someone to blame but immediately eliminate the cause.

Let's discuss your call scheme and come back with an estimate

To make the calculation based on your scheme rather than an "industry average," we need source data: load, call distribution logic, and the parameters of the current telecom operator.

Below is what removes uncertainty before the start and allows you to build in load headroom in Bitrix24 right away, rather than redoing routing after launch.

• Number of lines and simultaneous conversations at peak — how many calls should pass without queuing during the busiest hour.
• Number of operators and groups: who receives calls, who transfers, whether separate queues by department and region are needed.
• Current telecom operator: which numbers are in use, how they are connected, whether they can be migrated or a new SIP trunk can be raised in parallel.
• Call handling scenario: IVR, working hours, forwarding to mobiles, call recording, and retention period.
• Channels in one window: calls only, or also email, messengers, and website requests.
• Data for reporting: which fields and events should go into the deal record, which analytical slices the manager needs.
• Constraints: access requirements, recording storage, redundancy scheme for channel failure.

Describe your telephony task — an engineer will analyze the scheme, clarify disputed points, and we will come back with an estimate and a staged work plan. If some data is missing, that does not block the start: we will advise how to obtain it from the current PBX and operator.