Configuring Request Routing in Bitrix24 Open Lines
When all incoming messages land in one queue assigned to a random operator, a client who already works with a specific manager has to explain their situation from scratch every time. This is not a scaling problem — it is a routing configuration problem.
Distribution Algorithms
In the open line settings → "Queue" section → select an algorithm:
Round robin (queue). First request → first operator, second → second, and so on in rotation. A simple option for uniform load.
Simultaneously to all. A notification goes to every operator in the line. Whoever responds first handles the chat. Fast pickup with a small number of operators.
Responsible from CRM. If the client already exists in the database and is linked to a responsible manager, the chat is directed to that manager. If the manager is unavailable, escalation to the next in queue happens after N seconds.
The third option is the most valuable for sales and client retention. It requires correct client identification by phone number or another unique field.
Routing by Request Topic
To separate streams (sales / support / complaints), multiple open lines are used — one per request type. The client selects a topic via:
-
Bot scenario in the welcome message — buttons "Want to buy", "Problem with order", "Other" → each button transfers to a different line via
imopenlines.session.transfer. -
Different channels — different phone numbers, chat links, or buttons on the website lead to different open lines from the start.
-
Time-based routing — during working hours → one line (live operators), outside working hours → another (auto-replies only + callback form).
Escalation and Reassignment
What happens if an operator does not respond:
- After N seconds the chat passes to the next operator in the queue (configured in "Response wait time").
- If nobody responded — the chat stays in queue or is assigned to a "fallback" operator.
- When the maximum wait time is exceeded — an auto-reply to the client: "Leave your contacts, we will call back".
Manual reassignment: an operator can transfer a chat to a colleague directly from the interface. On transfer, the new operator sees the full conversation history.
Routing by Skills and Groups
If operators are divided into groups (e.g., by service language, by region, by product) — multiple open lines are created with different operator compositions.
Dynamic routing by client attributes — for example, VIP clients go to a dedicated queue — is not natively supported. It is implemented via:
- A bot determines the client type (query to CRM by phone number).
- Based on the type, transfers to the appropriate line via
imopenlines.session.transfer.
This requires an external bot server, not a built-in scenario.
Configuring Operator Work Schedules
The operator status ("online" / "break" / "offline") affects routing: a busy or absent operator is skipped in the queue.
Automatic status management: in the "Time tracking" module (Timeman) — at the start of the workday the operator automatically switches to "online", at the end — to "offline". This eliminates the situation where an operator went home but their status remained "online".
Configuration: CRM → Contact Center → [line] → Operators → enable "Use operator working hours".
Queue Monitoring
A supervisor sees the current queue state in real time: how many chats are waiting, which operators are busy, how many minutes each client has been waiting.
Available in: CRM → Contact Center → Monitoring. Here you can also take a chat from an operator or reassign it manually.
| Routing type | When to use |
|---|---|
| Round robin | Uniform load, interchangeable operators |
| Simultaneously to all | Small team (2–4 operators), speed is critical |
| Responsible from CRM | Returning clients, personalisation |
| By topic-selection buttons | Different request types, different specialisations |
| By groups / skills | Large team, clear specialisation |







