Why Viber messages get lost in Bitrix24
A client writes in Viber — the message goes to the company's number, and that is exactly the moment when the chain most often breaks.
If the channel is not linked to the portal's Open Channel, the request remains in the app on the employee's phone: neither a dialog, nor a client card, nor the conversation history appears in Bitrix24.
From the business's perspective, it looks like "the client is silent," although in reality no one saw their missed messages.
The second break is already inside the portal. The messenger is connected in the portal, the dialog has been created, but the line does not know whom to assign it to: there is no distribution rule, no binding to a department, and employees are not on shift.
This is how unassigned dialogs appear — they hang in the Open Channels queue until the client goes to another provider. A separate category is requests outside working hours: without an auto-reply and queue placement, they do not get into any report.
The cost of such breaks is not just one lost message.
Lost requests do not settle in client cards, so there are no statistics or follow-up touches for them, and a client who has not received an answer writes to another channel or another employee — and you get a duplicate with new context. The load on support grows, and the share of requests answered within the first minutes falls.
Below we break down how this is closed: binding the channel to an Open Channel, distribution rules and queue, off-shift auto-replies, and missed message control.
What connecting a messenger to Open Channels gives
The messenger connects to Open Channels as another channel — on par with website chat, email, and social networks. Dialogs from Viber go into the same list as other requests, so the operator works in one window and does not switch between apps and tabs.
A client's message turns into a request with an assigned responsible person, not a notification that is easy to miss.
Then distribution rules come into play: the request goes to a specific queue by number, operator group, or responsible manager, and when everyone is busy — to the general queue with subsequent transfer.
If the client is already in the database, the system pulls up their card by phone number and links the conversation to the contact and deal. Double work disappears: there is no need to manually create a lead and transfer the dialog text from the phone into the CRM.
First response time stops being a verbal agreement — it is calculated automatically for each dialog and for the entire line. You can see how many requests came in during working hours, where the queue accumulates, and at what stage the operator is slowing down.
Quick templates for frequent questions close typical requests in one reply, and an off-schedule auto-reply removes the wait until morning.
The conversation history remains in the card in full.
The client returned a month later or the dialog was transferred to another operator — the context of previous agreements is available without asking "what did you want?" Attachments, links to invoices, and payment details are also preserved.
The effect is measurable: messenger requests are visible in the common funnel, distribution follows rules rather than reaction speed, and the first response fits within the specified standard.
If you need such a channel — describe the task, and we will return with an estimate and connection plan.
Options for connecting Viber to Bitrix24: comparison
Connecting Viber to Bitrix24 is done in three ways, and they differ not in interface design, but in where the conversation history settles and who is responsible for message delivery.
The native channel lives inside Open Channels: the request joins the general queue on par with chats and email, the operator replies from the card, and history remains in the portal.
An intermediary service builds its own platform on top of the channel, while a custom gateway requires a public address and ongoing maintenance.
The launch timeline of the channel is almost always determined not by code, but by approvals: binding the number to the Viber partner operator account, rules for template messages outside the response window, and portal availability from outside. Below are real alternatives with their applicability boundaries.
| Option | When it fits | Limitations and launch timelines |
|---|---|---|
| Native channel in Open Channels | One number, typical dialogs, history needed inside the portal | Depends on the Viber partner operator account and on template rules outside the response window; launch — from one day |
| Intermediary service | Multiple channels in one window, mailings, bot scenarios | Conversation goes through a third-party platform with its limits and delays; launch — several days |
| Custom gateway on the customer's side | On-premise portal, own storage and logging rules | Requires a public address with a valid certificate and gateway support; launch — weeks |
The choice usually comes down to one thing: are you ready to give the conversation to an external service for the sake of launch speed, or do you keep it in-house and pay for that with implementation time and the need to maintain a gateway.
How implementation proceeds: stages of engineering work
The order of work does not depend on whether we are connecting the channel from scratch or adding Viber to already working lines and telephony.
First we record the current state, then assemble routing, and only after that bring the channel into production — this way no dialog is lost at the moment of switching.
- Channel survey. We look at request volume, sources and peak load hours, operator response time, and points where requests are lost. The output is a map of current lines and a list of bottlenecks.
- Account preparation. We bind the number to the official account, set the sender name, welcome and absence messages, and administrator rights. We check that the account allows service notifications and is not restricted for mailing.
- Routing scheme. We determine the composition of lines and distribution rules: by load, operator competence, and request topic. We separately specify working hours, queue overflow, and behavior when all employees are unavailable.
- Connection with Bitrix24 Open Channels. We register the channel in the portal, configure receiving and sending, linking the dialog to the client card, and notifications for responsible persons. We grant access by the minimum required roles.
- Test scenarios. We run the first request, reply, attachments, transfer between operators, client return to the same dialog, channel unavailability, and redelivery after a connection break. We record response time and how the conversation looks on the client side.
- Handover to operation. We provide the routing regulation, instructions for operators and administrators, and access to logs. We agree on metrics that show the channel is working.
What we hand over after completion: settings and documentation
After completion, access to the channel should not depend on the person who configured it.
Therefore, along with the working line, we hand over a set of documents by which a new administrator can repeat the setup, and an operator on the first shift will understand how to conduct a dialog.
- Line scheme. Which Open Channels are created, which Viber channel is linked to which, how queues are arranged, and what happens to a request if all operators are busy or offline.
- Distribution rules. The order of assigning dialogs, the limit of simultaneous requests per operator, waiting time before escalation, and conditions for transferring a client to another line or department.
- Operator regulation. Accepting a dialog, welcome and clarifying question templates, actions on connection loss, the moment of closing a request, and recording the outcome in the client card.
- Administrator instruction. Connecting and replacing a number, editing the welcome message and working hours, adding and disabling an operator, and the procedure for changing the line scheme.
- Access rules. Roles in Bitrix24, who has the right to change channel settings, who sees the conversation, and where the action log is stored.
- Acceptance and diagnostics. A set of checks before launch — test message delivery, distribution, behavior during unavailability, dialog history — and a map of typical failures indicating what to check and whom to notify.
Such a set reduces the onboarding of a new operator to one shift and removes support's dependence on a specific engineer: changes are made according to a document, not from memory.
Case study: messenger requests in one operator window
A service company with a fleet of maintained equipment accepted requests in Viber to one corporate number.
The conversation was handled by a duty manager from a personal phone: requests did not get into the CRM, after an employee left the history went away with the device, and outside working hours the client did not even receive confirmation that the request had been accepted.
The channel was connected to Open Channels: queue, distribution rules by load and operator qualification, quick reply templates, automatic off-schedule reply with contact collection.
Each message turns into a request card with conversation history, attached photos, and a link to the service object — the operator sees what the client wrote earlier and does not ask questions again.
What changed after launch
The share of missed requests fell from one third to 4%: some are handled by the auto-reply with request registration, and some are picked up in time by the duty operator.
First response time dropped from several hours to minutes — the message no longer waits for the manager to become free, but immediately goes into the queue to an available one.
The load on operators was redistributed: one employee handles up to eight parallel dialogs thanks to templates and a single window, rather than switching between phone and accounting system.
The second channel — telephony and email — was connected to the same line using this scheme, without expanding the support staff.
What to do if the channel is already connected but messages do not arrive
The channel rarely drops completely: the portal works, operators see old dialogs, but new requests do not reach the Open Channel.
There are usually three reasons — the connection token has expired, the connector binding to the line has dropped, or event subscription has stopped being processed. Before rebuilding the portal, we localize the point of loss.
| Symptom | Where the request is lost | What we fix |
|---|---|---|
| Message delivered in Viber but not in the line | binding to the Open Channel | binding, operator access |
| New dialogs are not created, old ones still work | event subscription | handler address, server response |
| It worked and stopped after a few weeks | token lifetime | reissue and auto-renewal |
| Only part of messages arrives | queue and routing | rules, operator limits |
Channel checking starts with a test message from Viber and a parallel look at the request history: if the dialog is created in the contact card but did not get into the line, the issue is in routing, not in the channel itself.
An empty event log with live messages almost always means that the handler is unavailable or responding with an error.
Reconfiguration is cheaper than rebuilding: we rebind the connector to the Open Channel, reissue the token, subscribe to events again, and replay the accumulated queue so that requests do not get stuck in the buffer.
We finish with a control run along each route and observation for the first days — this shows that delivery is stable, not just that one test message went through.
Frequent technical questions about connecting the channel
Typical doubts when connecting almost always concern one thing: not "will Viber work," but how the new channel will coexist with what is already configured in Bitrix24 — lines, rights, request history. Below are short answers to what is most often asked before work starts.
Can Viber be added to an already working Open Channel?
Yes. The channel connects to an existing line as another source of requests, not instead of it. Distribution rules, auto-replies, and other channels continue to work as before — there is no need to stop receiving requests during setup.
Will the line withstand the increased flow of requests?
Throughput depends not on the channel, but on the number of operators and queue settings.
If there are more dialogs than the line can handle, we limit the number of simultaneous requests per operator, set priorities and group distribution — the client does not remain waiting in silence.
How to differentiate access between operators?
Roles are configured at the line level: who sees requests, who can reply, who changes channel settings. Conversation history and attachments remain inside the system, and we grant export access selectively — to individual employees, not the entire shift.
What will happen to the current conversation and settings?
The existing history is not affected: new conversations are stored alongside, on their own channel, with separate labeling in the client card.
Rollback is also provided — the channel can be disabled without losing already processed dialogs, if there is a need to return to the previous scheme.
Let's discuss the task: connecting a messenger to your lines
To discuss the task specifically and give an accurate estimate of the work, a technical description from the customer is enough — a ready-made specification is not required.
Gather what is already working: current lines, request processing regulations, and the composition of operators. Based on this data, we calculate the scope of setup in Bitrix24 and return with timelines and a scheme.
- List of Open Channels: which channels are already connected — email, web chat, messengers, social networks — and which of them need to be handled in Viber.
- Processing scenarios: distribution by departments (sales, support, service), queue rules, and dialog transfer between operators.
- Composition of operator groups: who is responsible, hourly schedule, who substitutes outside working hours and on weekends.
- First response rules: welcome message, menu with options, off-schedule auto-reply, templates for typical wording.
- Channel data: sender account, verification status, access to settings — the business profile and rights are arranged on the customer's side.
- Current request accounting: CRM, tasks, load reports — what needs to be preserved and what the conversation history should be linked to.
Then we assemble the routing scheme, connect the channel, run test dialogs on real scenarios, and hand over short instructions to operators. We agree on the implementation plan in stages so that launch does not block the current operation of the line.
We take on channel support: we monitor message delivery, update templates, menus, and access rights when the composition of groups changes.