Setting Up Multichannel Service in Bitrix24

Multichannel service in Bitrix24: where requests get lost

Requests come to messengers, email, website forms, social networks, and by phone. As long as each channel has its own inbox and its own person on duty, support sees not a stream of requests but several disconnected feeds.

A client who wrote in chat, duplicated it by email, and called exists for support in three different personas — and is not recognized in any of them.

Disconnected request channels break in predictable ways. A chat request left in the evening sits unanswered until morning because no one tagged it or passed it into work.

An operator answers the same question twice, and the conversation history is lost when the client changes channel: you have to ask again for what they already told you.

Lost requests are almost invisible in this setup — each channel has its own count, and no one collects the overall picture.

The biggest loss comes from first response time. It stops being a manageable value: in some places it is calculated automatically, in others it relies on the operator's memory. The client judges not the depth of work on the issue but the silence in the first minutes.

Multichannel service in Bitrix24 brings channels into a single operator window. Open Channels receive messages, queue them, and distribute them by rules among available employees.

The request is linked to the client card together with orders from 1C and past dialogs — you can reply while seeing the context instead of starting from scratch.

Next, we break down exactly where requests get lost and what needs to be configured so the flow from all channels goes into one window with a transparent response time.

What multichannel service provides: effect and metrics

Multichannel service starts with a single operator window: emails, messenger messages, website chat, and calls enter one request stream with a shared customer history.

The operator does not switch between tabs or transfer data manually — routing in Bitrix24 is configured by rules based on channel, topic, and current employee workload.

The first measurable effect is response speed: first response time decreases, and the share of requests left unanswered during working hours falls.

The second effect is operator workload relief. Typical questions are closed by a scenario with ready-made answers, and only what requires a decision is escalated to an employee — with conversation history and data from the accounting system in the card. A team of the same size processes more requests per shift, and time per dialog decreases.

Response quality control rests on saved dialogs and unified templates: the manager sees first response time, closing speed, and customer rating for each employee, not based on general impressions. The policy defines what counts as a deadline violation and how a disputed dialog is reviewed.

Channel reporting shows where the main flow comes from, where requests get lost, and which topics generate repeat requests. Based on this data, routing rules, shift schedules, and auto-reply texts are adjusted — decisions are made by numbers, not by feel.

Comparison of ways to connect channels into a single window

Channels are connected into a single window in two fundamentally different ways: as a platform open line or as a separate integration with its own routing.

An open line provides a shared queue, rule-based distribution, and conversation history in the client card, but inherits limitations: the reply goes out only from the operator interface, and under overload the dialog hangs without escalation.

A separate integration is more flexible — it can support a non-standard channel, custom priority logic, and an external accounting system — but it must be maintained: updating access keys, handling external service unavailability, and re-authorization.

What to consider when choosing

In practice, the scheme is assembled as a hybrid: open channels hold the flow, callback and chat close the first contact, email and closed lines provide a personal response.

Before connecting, we check access rights: an employee leaving should not take the conversation history with them, and channel limitations should not become invisible to the manager.

Implementation stages: from flow audit to handover to support

Multichannel service breaks not on the number of channels but on routing: as long as an email, a messenger message, and a form request fall into different queues, the client writes to two places, duplicates remain unanswered, and conversation history is not collected into one card. That is why work proceeds sequentially, and each stage relies on the numbers from the previous one.

1. Request flow audit. We export history across all channels for a comparable period: channel shares, peak hours, share of repeat and abandoned dialogs, first response time, and the points where a request is lost. The output is a flow map with bottlenecks.
2. Routing scheme. We define distribution rules: owner by question type, waiting queue, escalation by silence timer, and off-schedule work. We agree on the scheme before configuration — edits on paper are cheaper than edits in production.
3. Channel setup. We bring channels into a single window, configure merging of one client's requests by phone and email address, response templates, auto-rules, and transfer of the request to the owner. We separately check role-based rights and the action log.
4. Test run. We run scenarios on a limited circle: a typical question, a repeat request, channel failure, escalation, and an after-hours response. We look at what happens to a request during a failure — it should enter the queue, not disappear.
5. Policies and training. Instructions for operators, an escalation map, and the procedure for changing routing rules.
6. Handover to support. We hand over the scheme, settings, dashboard, and edit policy, and enable queue monitoring and failure notifications so deviations are visible before customer complaints.

Configuration, schemes, and policies after project handover

After project handover, the client should be left not with a set of screenshots of "how it was configured" but with a working environment: documents by which a new operator comes online and the manager understands where each request goes. Below is the set of artifacts we hand over along with access to the system.

• Channel map — a list of connected entry points with an owner for each: email, website chat, messengers, telephony, social networks. We separately record after-hours behavior and the merging rule so one client does not start three parallel dialogs.
• Routing scheme — a matrix "request type → queue → operator group → response time" with escalation branches for overdue cases and redistribution rules under line overload.
• Request handling policy — stages from first contact to closure, required card fields, transfer procedure between lines, conditions for reopening, and review of disputed cases.
• Operator access rights — roles and visibility levels: who works only with their own dialogs, who sees the full customer history, who changes routes and templates. We grant access to reporting separately from the working environment.
• Operator instructions — one-to-two-page scenarios: how to answer a typical request, what to do in a conflict, and to whom and when to transfer the dialog.
• Change policy and versions — how new channels and routing edits are approved, where the settings history is stored, so that six months later it is clear why the rule looks the way it does.
• Channel failure action plan — whom to call, how to switch the flow to a backup line, and how to notify operators and clients.

We assemble each document together with the client's team and verify it at acceptance: the operator walks through a typical dialog using the instructions, and the manager builds a report on the request funnel. If at some step the scheme diverges from practice, we fix the settings, not the paper.

Case study: how we reduced first response time and lost requests

Baseline

Support ran through email and one website chat, while operators handled requests from messengers and social networks manually, transferring text into the shared system.

During peak hours, first response time reached 40 minutes, and the share of lost requests — those not answered the same day — stayed at 12%.

What we configured and what the result was

We built a single window on Bitrix24: connected Open Channels to website chat, messengers, email, and social networks, and set routing by topic and current operator workload.

Typical questions were closed with templates that insert data from the client card, and the history of past conversations was linked to the request — the operator sees the context and does not start the dialog from scratch.

Two months later, first response time during working hours dropped to 3–4 minutes, and the share of lost requests to 1.5%. Repeat requests fell by about a third: the issue was closed in the first dialog.

Operator workload became predictable — they handle up to four dialogs in parallel instead of being torn between tabs, and delays are visible by the queue timer while the client is still waiting for a response.

Support manager: "Before, every morning we reviewed what we had not managed to answer in the evening. Now the whole queue is visible in one window, escalation triggers automatically, and requests no longer have to be manually thrown between people."

What to do if some channels are already connected manually

Connecting a channel manually is not a problem: the difficulty is that conversation history, operator rights, and distribution rules remain in the old environment. With a rough switchover, the client loses the request context and the operator loses the queue.

That is why migration takes place as a period when both environments work simultaneously and channels move one by one.

Migrating conversation history runs into export limitations on the messenger side: some channels provide dialogs incompletely, and some only for a limited period.

First we determine what volume is actually needed for work, migrate requests, attachments, and owners, and put the rest into the client card as an archive. Phased migration removes residual risk: while one channel is in testing, the others are served as before.

Channel duplication is a common side effect: two handlers receive messages on one account, and the client gets two responses from different operators.

We eliminate this before switchover: remove the old handler, verify addresses and routing rules, and only then enable the channel in Bitrix24.

The order is always the same — test channel, then operator group, then the rest, with the ability to roll back to the old scheme within a shift.

Common technical concerns before starting the project

Before launch, technical teams check not a list of features but system behavior on a live flow: whether the infrastructure will handle peak load, whether conversation history will fall apart, and how requests will be distributed between lines and shifts. Below are the four most common concerns and how we address them before work begins.

Will conversation history be preserved when migrating from the current system?

We migrate requests, attachments, and client links into the card so the dialog context is not lost when the operator changes. Before the production migration, we run a test on a copy and compare the number of requests before and after. We review discrepancies before switchover.

How will requests be distributed between operators and shifts?

Rules are configured by channel, topic, group, shift schedule, and current workload — the request goes to the least busy operator. A waiting timer with escalation to the manager works. We monitor first response time and the share of requests closed without a second line.

Will the infrastructure handle peak load?

We capture the load profile from the current system and test on a copy with headroom: we move queues and search to separate services and enable caching. We look at response time, queue length, and the share of requests lost during peak. We add headroom before launch, not in the middle of the season.

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

To make the implementation plan based on facts rather than general considerations, we start with an analysis of current requests: where they come from, who answers, and at what step they get lost.

Based on the results, we record the scope of work, the order of channel connection, and the control points that show the result.

Below is a typical list, which we refine for your customer workflow.

• Order of channel connection — from simple to complex: website form and email, then messengers, then telephony and social networks. Each next one is connected on an already working scheme, without stopping service.
• Unified request feed: email, message, and call enter one client card with end-to-end conversation history.
• Routing: queues by topic, workload, and schedule; request escalation if no response is given within the specified time.
• Response templates and automated scenarios: greeting, clarifying questions, transfer to a specialized employee, closure with rating.
• Roles and access rights: the operator sees their dialogs; the manager sees channel workload, first response times, and the share of missed requests.
• Control points: after each channel, we verify that requests are not duplicated or lost during transfer between employees, and measure first response time before and after.
• Support policy: who makes edits to routes and templates after launch, and how quickly failures in integrations between systems are resolved.

Describe the task: how many channels there are, where requests are currently lost, and how many people work with clients. We will come back with an implementation plan, scope of work, and control points — with timelines and responsible persons.