Why call routing in Bitrix24 fails
Call routing in Bitrix24 breaks not at the setup stage, but at the junction of rules: the queue, work schedule, and forwarding conditions begin to conflict with each other.
A typical picture: a call goes to an employee who is already on vacation, and while the line is busy, the next client hears short beeps and dials a competitor.
The first point of telephony failure is priorities within the queue. If distribution is built only on the "free or busy" principle, at peak all calls fall on one manager, the rest are idle, and missed calls do not even turn into a request with a callback task.
The second is the absence of a call distribution scenario for non-working hours and breaks: a night call hangs unanswered or goes to a voice menu from which no one returns to the client.
The third is the loss of line state after a network failure: the call remains in the queue although it is actually completed, and it is no longer possible to sort out the history from the log.
The fourth is a desynchronized responsible person: a request is created but not linked to the number, and a repeat call from the client starts from scratch.
Each of these points costs a missed contact at the stage when the client is already ready to buy — next we analyze how this is closed.
What a well-thought-out call distribution scheme provides
Before routing setup, a call almost always follows the simplest rule — to a common number or to the first available person.
Externally it looks like work, but the time to first answer grows with every missed ring, and some requests settle in unanswered: the client does not wait and goes to whoever picked up earlier.
A distribution scheme built for real roles changes the picture at the entrance. The call goes to the right department according to the scenario — by time of day, direction, or client owner — and reaches the person who solves the issue rather than forwarding it further.
Then queues and groups work: while one is busy, the call moves to a free person instead of returning to the common flow.
The effect metrics are taken immediately, in Bitrix24 reports. Time to first answer becomes a manageable value, the share of lost calls becomes calculable rather than estimated: missed calls do not dissolve in general statistics but go into a separate list with the reason.
Service quality control stops relying on the manager's memory. Conversation recordings are linked to the request and deal, so resolving a disputed situation takes minutes, and new employees reach a normal level faster.
A separate class of failures — "could not get through, and no one noticed" — goes away. A request is created automatically even after a missed call, so no query remains without an owner and a next step.
Call distribution modes: comparison of options
The distribution mode is set at the queue level within a group or an individual number, and it determines who the call goes to and what the client hears in the first seconds.
Rules are combined into a chain: the voice menu separates general requests from targeted ones, the queue seeks an answer from a live employee, and forwarding picks up what was not closed during working hours.
The choice of mode is always a compromise between answer speed and hit accuracy. The stricter the filter by competencies, the longer the caller waits in the queue; the broader the rule, the more often the call goes to an employee who will not solve the issue on the first touch.
| Option | When it fits | Limitations |
|---|---|---|
| Call queue | Several employees with interchangeable skills; need to evenly unload the line | Does not account for specialization — the request may go to someone who does not own the topic |
| Competency group | Products or directions require different qualifications; important to solve on the first touch | Requires maintaining up-to-date employee attributes, otherwise the call hangs without an answer |
| Auto-attendant | Many typical call reasons and sorting is needed before picking up | A long menu is annoying; if there is an error in the scenario, the client leaves without waiting for an operator |
| Forwarding to mobile | On-duty outside the office, few responsible people, night requests | Depends on the employee's connection quality; the call may go to voicemail |
A mode change applies to new calls; active ones remain on the previous rule — switching takes place without line downtime.
Before putting a rule into operation, it is worth running it on a test group: check how a missed call, busy state, and going outside the work schedule are handled.
Stages of work in Bitrix24: audit, scheme, setup, handover
We carry out work in sequential stages, and each has a control point: without it, we do not move to the next step.
The call processing logic is agreed upon before setup, so there is no need to edit scenarios on live traffic — employees do not catch lost calls in the middle of the day.
- Telephony audit. We collect numbers, operators, queues and groups, compare the rules with how calls are actually distributed. Control point — a map of current flows and a list of places where the subscriber leaves without an answer.
- Routing scheme. We design the target flow: entry, greeting and menu, department selection, distribution among employees, transfer, rule for missed call. Control point — the scheme is confirmed by department heads before setup begins.
- Scenario setup. We transfer the scheme into the system: distribution rules, waiting time, queues, forwarding, work during non-working hours, conversation recording. Control point — each route passes a test call in both directions.
- Testing call scenarios. We run typical and edge situations: busy, no answer, refusal, transfer between departments, call at lunch and at night. Control point — a log of tests with the result for each route and corrections made as a result.
- Handover and regulations. We show the administrator where to change the queue and add an employee, and fix the rules on paper. Control point — the employee makes a typical change themselves, under our supervision.
- Support. We track the share of missed calls and time to first answer, and analyze deviations. Control point — a report on routing metrics in the agreed form and timeframe.
Set of documentation and settings after implementation
The setup of call routing in Bitrix24 ends not with turning on the queue, but with the handover of a working set. Without it, in a month no one remembers why on a failed call the call goes to the second line, and any edit begins with re-analyzing the logic from scratch. Below is what remains with your team after delivery.
- Call distribution scheme — all branches from the incoming number to the responsible employee: queues, groups, waiting time, transfer conditions.
- Escalation rules — by which event the call goes to the manager or to a backup group: failed call, exceeding waiting time, request during non-working hours.
- Operator instructions — what the employee sees on the screen and in what order they act: accept, hold, transfer, record the outcome of the conversation.
- Request processing regulations — deadlines for returning a missed call and responding to a ticket, who controls execution and where to report a failure.
- Access differentiation — who changes the scheme, who sees reports, who works with conversation recordings and request history.
- Procedure for checking changes and a way to return the previous configuration if the new logic did not take root in work.
- A set of control indicators — share of missed calls, time to first answer, share of requests brought to a result.
The set is assembled so that it can be read without us: schemes match actual settings, and instructions are written for employees, not for engineers.
Case: the sales department stopped losing incoming calls
The sales department worked on a common line: the call went to whoever picked up first.
At peak hours and at lunch, calls went nowhere — by morning, reports showed 30-40% missed, and there was no way to restore who did not call back and when: the call history was not linked to the client card. Some requests hung between managers — each believed a colleague was handling the client.
What was changed
We assembled a queue with distribution by groups and work schedule: the call first goes to the responsible manager, then to the on-duty person, then to the department head.
A missed call automatically creates a task with a conversation recording and a link to the client card, and anything not processed on time is raised a level higher.
Transfer of the request to a manager is recorded in the history: you can see who accepted the client and at which minute.
What became
The share of missed calls fell from 35% to 4%, and first contact with the client occurs on average in two minutes instead of several hours.
Call processing control is based on a report: the manager sees unclosed requests and workload for each employee in real time, and the argument "I did not see the ticket" no longer arises.
It was set up on Bitrix24 — telephony, deals, and tasks live in one scenario, so analyzing a call does not require exports to third-party tables, and the client owner is assigned automatically.
What to do if telephony is set up but calls are lost?
Telephony is connected, calls are in the log — but clients complain they could not get through.
Most often the reason is not in the PBX or the operator, but in distribution rules: the request goes to the wrong department, hangs in the queue longer than expected, or is cut off during forwarding.
Telephony diagnostics begins with comparing two sources — the operator's call detail records and the call log in the portal itself.
A discrepancy for a specific number immediately shows at which step the call was lost: it did not reach the line, did not fall under any rule, went to an unavailable employee, or was dropped by external forwarding.
Next we check typical bottlenecks: overlapping rules with the same priority, when a call goes to a random department; the line's work schedule diverging from the queue schedule; a voice menu with no exit to a live operator; employees unlinked from extensions or dropped from the queue after vacation. Each of these causes call loss, but is treated differently.
Almost all of this is closed by setup without replacing the PBX. It is enough to rebuild routing: set rule priorities, add a "no answer" branch with transfer to the on-duty person, align schedules, and duplicate a missed call with a task in an open deal.
After edits, the scheme is run with test calls for each scenario — from mobile, from abroad, during non-working hours — and only then are the rules changed to production. This way the funnel stops losing tickets, and investments in new equipment are not required.
Common technical questions before setting up telephony
Telephony integration is not connecting a number, but rules: queues, operator groups, schedule, behavior on no answer. Most failures come from the junction of schedules and time zones — night forwarding triggers in the middle of the working day.
Our PBX is not one of the "native" ones — is integration possible?
Yes. The telephony module in Bitrix24 accepts cloud and office PBXs via an open interface. Without a ready connection module, we raise an intermediate service that transmits call events to the portal.
How are time zones configured?
The schedule is set in the portal's time zone, not an individual operator's — otherwise the morning shift from another region falls into night forwarding. We separately check transitions through midnight and weekends.
Will conversation recordings overload the system?
Recording is enabled at the number level, the file is linked to the call card, and the retention period and access rights are set by policy: an operator sees only their own recordings. We upload a long archive to external storage.
What about the load on the line?
We calculate the peak number of simultaneous conversations and allow a margin for advertising spikes. If exceeded, the call goes to a queue with a voice greeting rather than being dropped — statistics show whether another line is needed.
Let's discuss your call processing scheme
To come back with an assessment of the routing scheme rather than general considerations, we need initial data on your telephony — in free form, we will assemble the rest ourselves.
If the scenarios are already working and need to be rebuilt, we start with an audit of the current scenarios: it shows which rules conflict with each other and at which step calls are lost.
It is enough to send:
- Department structure and roles: who calls, who answers incoming calls, where on-duty lines are needed.
- Current distribution rules: queues, groups, priorities, waiting time, and what happens on a failed call.
- Communication channels: landline and mobile numbers, messengers, extensions — with a note on which are already connected to Bitrix24.
- Work schedules and exceptions: breaks, weekends, holidays, forwarding to the on-duty person.
- Where conversation outcomes go: deal card, report, external system, requirements for the call log.
- Limitations: operator rights, access, integration with 1C or an accounting system, requirements for conversation recording.
On this basis, we prepare a work plan for telephony: the order of changes, what we fix immediately and what we check on a test environment, how we roll back if the scenario behaves differently. Describe the task — we will come back with an assessment and work plan.