Bitrix24 Chatbot Development: Scenarios, CRM, Integration

Imagine your sales department drowning in repetitive inquiries, managers spending 2/3 of their time on routine tasks, and leads leaving due to slow responses. A chatbot for Bitrix24 solves this problem. We specialize in Bitrix24 chatbot development, including Open Lines chatbot and CRM integration, delivering turnkey solutions. Unlike standard auto-replies in Open Lines, which only cover one scenario—"you wrote outside business hours, please wait"—our bot handles up to 80% of incoming requests without operator involvement: it qualifies the lead, answers typical questions, creates deals in CRM, and transfers only those clients it couldn't process. Contact us to discuss scenarios for your business.

Architecture of a Chatbot in Bitrix24

Bitrix24 provides two mechanisms for chatbots:

Built-in Bot Framework — register a bot via REST API method imbot.register. The bot operates inside Bitrix24: replies in chats, Open Lines, internal conversations. Events are sent to your server's webhook URL.

Open Lines + external handler — all messages from connected channels (Telegram, WhatsApp, website) pass through an Open Line. The external service subscribes to events via imopenlines.bot.session.message and replies via imbot.message.add.

For most tasks, our Bitrix24 chatbot development uses a combination: external service (Python/Node.js) + Bitrix24 Bot Framework + CRM integration via REST. According to the official Bitrix24 REST API documentation, the imbot.register method is used to register a bot.

Registration and Bot Lifecycle

POST /rest/imbot.register
{
  "CODE": "support_bot",
  "EVENT_HANDLER": "https://your-server.com/bot/handler",
  "EVENT_MESSAGE_ADD": "https://your-server.com/bot/message",
  "OPENLINE": "Y",
  "PROPERTIES": {"NAME": "Support", "COLOR": "AZURE"}
}

After registration, Bitrix24 assigns a BOT_ID. All incoming client messages in Open Lines connected to this bot are sent to EVENT_MESSAGE_ADD as a POST request with fields: BOT_ID, DIALOG_ID, MESSAGE, USER_ID.

The bot replies via:

POST /rest/imbot.message.add
{
  "BOT_ID": 123,
  "DIALOG_ID": "chat456",
  "MESSAGE": "Hello! How can I help you?"
}

To transfer a chat to an operator — imopenlines.session.transfer with the operator's USER_ID or queue ID.

Dialog Logic: FSM vs. NLP

A script-based bot (FSM — finite state machine) is the most predictable option. Each dialog is a state tree. The user selects from buttons, the bot moves to the next state.

Buttons in Bitrix24 are implemented via KEYBOARD in imbot.message.add:

"KEYBOARD": {
  "BUTTONS": [
    [{"TEXT": "Order status", "COMMAND": "order_status"}],
    [{"TEXT": "Return item", "COMMAND": "return"}],
    [{"TEXT": "Talk to operator", "COMMAND": "transfer"}]
  ]
}

An NLP bot understands free text. It requires connecting a language model (Dialogflow, Rasa, OpenAI API). Process: message → NLP service → intent → intent handler → response. Accuracy for Russian in Rasa heavily depends on training data quality. OpenAI GPT-4 works without training but costs more at high loads.

In practice, we use a hybrid: structured buttons + NLP for free input with a fallback to operator when confidence is low (below 0.7). Hybrid bot is 1.5 times better than pure FSM, handling 95% of requests versus 60%.

Chatbot Integration with CRM

The key point is that everything the bot learns about the client must go into CRM. A typical scenario:

1. Client writes → bot creates a lead: crm.lead.add with source SOURCE_ID = 'CHAT'.
2. Bot asks qualifying questions: name, phone, issue summary.
3. Answers are written to lead fields: crm.lead.update with filled NAME, PHONE, COMMENTS.
4. If the client enters a phone — bot searches for it in CRM: crm.contact.list with filter by PHONE. Found — updates, not found — creates.
5. When transferring to operator — the lead is already filled, operator sees chat history in the card.

Creating/updating a CRM entity automatically appears in the timeline — standard behavior of the crm module.

Real Case from Our Practice: Chatbot for an Online Store

Our case — development and deployment of a chatbot for a large home appliance e‑commerce store handling ~500 inquiries per day via Telegram. 70% of incoming questions fell into three typical scenarios: "Where is my order?", "Can I return an item?", "Is a specific model in stock?". This is an ideal situation for automation.

Solution architecture: Node.js server on a dedicated VPS + Bitrix24 Bot Framework + REST integration with 1C for syncing orders and stock levels. The bot works in the Telegram Open Line and syncs all actions with CRM.

Implemented scenarios:

• "Where is my order" → bot requests order number → queries 1C (via 1C REST service) → returns actual status. No operator involvement.
• "Product availability" → search Bitrix catalog (iblock.element.list + stock filter) → output current real-time stock.
• "Product return" → FSM scenario: purchase date → return reason → product photo (upload via disk.folder.uploadfile) → auto‑create a task for manager with attachment.
• Non‑standard inquiries → automatic transfer to operator with category note for fast processing.

Results after one month: operators handle only 35% of initial inquiry volume. The remaining 65% is successfully closed by the bot without human involvement. Average response time for typical questions dropped from 8 minutes to 15 seconds (32 times faster). This allowed the client to reduce support operational costs by 40%, saving approximately $5,000 per month, while improving NPS. Our development cost for a basic bot is $2,500, and complex projects cost $8,000.

Technical details during development: the main bottleneck was file handling (product/package photos). Bitrix24 sends uploaded files via temporary links with TTL of 30-60 seconds. We had to implement asynchronous download with retry logic and caching in S3 to avoid data loss during network failures.

Testing and QA of Chatbots

Before going live, all scenarios and edge cases must be tested:

• Functional testing — every FSM path run manually. Correctness of replies, user input handling, CRM data transfer are checked.
• Integration testing — interaction with Bitrix24 API, 1C, payment systems. Special attention to network errors and timeouts with slow internet.
• Load testing — simulate peak loads (if expecting 500+ messages per hour). Check how the bot server handles the request queue, no messages lost.
• Real channel testing — pilot with a limited group (e.g., 10% of incoming traffic) before full launch. Catches issues invisible on staging.

A typical chatbot regression test includes 15-20 scenarios and takes 2-3 hours of manual testing. We recommend re‑testing with every dialog logic update.

Deployment and Monitoring

Deployment is usually on a dedicated VPS or container (Docker + PM2). Critical requirements:

• SSL certificate for webhook URL (Bitrix24 requires HTTPS).
• Fixed IP or DNS with long TTL (changing IP causes message loss).
• Persistent connection to a message queue (Redis/RabbitMQ for async processing under high load).
• Logging all requests and errors — without it, diagnosing problems is impossible.

Monitoring after launch:

• Processing metrics: messages per hour, success rate, transfer rate to operator.
• Response time: average and max time from incoming message to bot reply.
• Errors: number of API errors, timeouts, failed external integrations.
• Availability: live webhook endpoint check every 5 minutes, auto‑alert on failure.

We recommend connecting Sentry or a similar service for real‑time exception tracking. Quick reaction is crucial — even 1 hour of downtime means losing 20+ client inquiries.

Hybrid Architecture Is More Effective

Comparison of bot types helps choose the optimal option:

Hybrid architecture (FSM + NLP) handles 95% of requests vs 60% for pure FSM — 1.5x more efficient.

What's Included in Chatbot Development

• Business requirements analysis and scenario description
• Dialog logic development (FSM/NLP)
• Bot registration and setup in Bitrix24
• CRM integration (leads, contacts, deals)
• Third‑party integrations (1C, ERP, telephony)
• Deployment on client's server
• Scenario documentation and deployment guide
• 30‑day warranty support

Effort Estimation Factors

A minimal working bot with 3-4 scenarios and CRM integration — from 40 hours (typical cost $2,500). A complex multi‑scenario bot with NLP and external integrations — 80-120 hours (typical cost $8,000). Contact us for a project estimate — we'll calculate timelines and cost individually. Get a consultation right now.

Open Lines: Where It All Begins and Breaks

The Open Lines module (imopenlines) is the standard Bitrix24 mechanism for omnichannel communications. It connects an external channel to an internal chat via the Im\Model\ChatTable entity. The problem is that out-of-the-box routing settings are primitive: "in turn" or "all at once." For a real sales department with 15+ managers, VIP clients, and SLA response times, this is not enough. We enhance routing via event handlers OnImOpenLinesChatStart and the REST API.

A manager switching between five windows loses messages, forgets to reply—the client leaves for a competitor who responded in 30 seconds. Bitrix24 messenger configuration gathers all channels into one interface, and CRM records every touch. Experience shows that after setup, average first response time drops by 40% within the first week.

How we implement messenger integration

We connect Telegram, WhatsApp, Viber, VK, online chat, email, and other channels via standard connectors or REST API. Each channel requires its own configuration, but the result is unified—all messages end up in open lines, and from there into the client card. We guarantee no message gets lost: we use tagged caching and agents to check queues.

How to connect WhatsApp to Bitrix24?

WhatsApp is the main business channel. Integration via WhatsApp Business API with a verified account. We configure sending and receiving messages from the Bitrix24 interface—they fall into an open line. We create HSM templates for initiating dialog (abandoned cart reminders, order status). Templates go through Meta moderation—allow 2-3 days. We ensure file, image, and document transfer. We link conversations to contacts and deals via CRM_ENTITY_TYPE and CRM_ENTITY_ID.

Telegram: Free Channel with High Reach

Telegram Bot API is free and well-documented—a pleasant rarity among messengers. Integration into Bitrix24 is done via the imopenlines connector. Setup: connect the bot to open lines, configure the connector to Telegram. Receiving messages, photos, videos, documents—all mapped to the Bitrix24 chat. Inline buttons and reply keyboards for navigation. Webhook on https://yourdomain/rest/imconnector.register—register the connector. CRM integration: incoming message creates a lead via crm.lead.add or an activity in the deal.

Telegram is indispensable for:

• Support via bot—standard questions resolved without an operator (up to 70% of inquiries).
• Notifications: orders, delivery, payment—via Telegram Bot API sendMessage.
• Lead collection: bot asks qualifying questions → creates a lead.

Viber and VK: Audience 35+ and Social Network

Viber maintains positions in regions. We connect a business account via the open lines connector. We use Viber Business Messages—bulk messaging with action buttons and rich content. Receiving and sending from CRM works immediately.

VK (Vkontakte) is the largest social network in Russia. Integration via the imopenlines community messages connector. Process messages and comments from a single interface. Auto-creation of a lead—handler OnImOpenLinesCrmCreate. Integration with VK Ads for tracking sources via UTM. Bot for auto-replies—VK Bot API + Callback API.

Why is proper routing of inquiries important?

Distribution of inquiries among operators is organized through queue mechanisms. By default: "who is free." In reality, more complexity is needed:

• Determining responsible person by number or email from CRM—im.chat.get + search via crm.contact.list.
• Distribution by departments based on keywords (NLP classifier or simple regex on first message).
• Priority queue for VIP—by segment in CRM.
• Escalation on 5-minute timeout—auto-switch to next.
• Transition to call directly from chat—telephony.externalcall.register.

We use custom event handlers OnImOpenLinesChatStart and REST API to implement such scenarios. Additionally, we connect Bizproc for complex approval chains and integration with HL blocks for storing custom queue parameters. Result: client does not wait, operator is not overloaded.

What is included in messenger integration work

Chatbots: Script-Based and with NLP

Types

Script-based (rule-based): button menu, decision tree. "How to pay" → "Where is my order" → "Business hours." Transfer to operator at intent == 'unknown' → transfer_to_queue. Reliable, predictable, covers 60-70% of typical inquiries.

With NLP: free text in Russian. Intent detection (buy, complain, inquire about delivery), entity extraction (name, date, order number). Contextual dialog—remembers what was discussed. Implemented on Rasa or Dialogflow, integrated with Bitrix24 via REST.

use Bitrix\Main\Loader;
use Bitrix\Imopenlines\Model\SessionTable;

Loader::includeModule('imopenlines');

$eventManager = \Bitrix\Main\EventManager::getInstance();
$eventManager->addEventHandler('imopenlines', 'OnImOpenLinesMessageReceive', function($event) {
    $message = $event->getParameter('message');
    $chatId = $event->getParameter('chatId');
    
    if (preg_match('/order status (\d+)/i', $message, $matches)) {
        $orderId = $matches[1];
        // Get order status via API
        $order = \Bitrix\Sale\Order::load($orderId);
        if ($order) {
            $status = $order->getField('STATUS_ID');
            \Bitrix\ImOpenLines\Chat::sendMessage($chatId, 'Your order #' . $orderId . ' status: ' . $status);
        }
    }
});

Scenarios and Real Impact

Comparison: a script-based bot processes requests 5 times faster than an operator, and an NLP bot reduces fallback rate to 15% after training on real dialogs. Average savings on operator salary when implementing a chatbot amount to substantial monthly savings.

How can chatbots transform your customer support?

Development Process

1. Inquiry analysis—export history from open lines, cluster by topic. Identify 80% of typical requests.
2. Dialog design—map on miro/figma. Each branch ends either with an answer or transfer to operator.
3. Development—logic, integration with CRM and external APIs. For script-based: finite state machine. For NLP: pipeline: tokenizer → featurizer → classifier → response selector.
4. NLP training—on real dialogs (at least 500 examples). Set confidence threshold.
5. Testing—run all branches, edge cases (empty message, sticker, voice).
6. Optimization—monitor fallback rate, retrain on new dialogs every 2 weeks.

Timeline

Result: all communications in one window, routine automated, no message lost. Managers sell, not search for the right chat. Evaluate which channels you need—contact us, we'll select for your niche. Get a personalized timeline and cost estimate for your project.