Developing a chatbot for Bitrix24

Chatbot Development for Bitrix24

Standard auto-replies in open lines cover only one scenario — "you wrote outside business hours, please wait." A full-featured chatbot handles incoming requests: qualifies the lead, answers common questions, creates deals in CRM, and hands off to an operator only those clients it could not handle itself.

Chatbot Architecture in Bitrix24

Bitrix24 provides two mechanisms for chatbots:

1. Built-in Bot Framework — register a bot via the REST API method imbot.register. The bot works inside Bitrix24: it replies in chats, open lines, and internal conversations. Events are sent to the webhook URL of your server.

2. Open Lines + external handler — all messages from connected channels (Telegram, WhatsApp, website) pass through the open line. An external service subscribes to events via imopenlines.bot.session.message and responds via imbot.message.add.

For most tasks, a combination is used: an external service (Python/Node.js) + Bitrix24 Bot Framework + CRM integration via REST.

Bot Registration and 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 the bot a BOT_ID. All incoming client messages in open lines connected to this bot arrive at EVENT_MESSAGE_ADD as POST requests with the 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! What can I help you with?"
}

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

Dialog Logic: FSM vs. NLP

Scripted bot (FSM — finite state machine) — the most predictable option. Every dialog is a tree of states. 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": "Contact operator", "COMMAND": "transfer"}]
  ]
}

NLP bot — understands free-form text. Requires connecting a language model (Dialogflow, Rasa, OpenAI API). Processing: message → NLP service → intent → intent handler → response. Rasa's accuracy for non-English languages depends heavily on training data quality. OpenAI GPT-4 works without training but costs more at high volumes.

In practice, a hybrid is used: structured buttons + NLP for free-form input with fallback to an operator when confidence is low (confidence < 0.7).

CRM Integration

The key point — everything the bot learned about the client must end up in CRM. Typical scenario:

1. Client wrote → bot created a lead: crm.lead.add with SOURCE_ID = 'CHAT'.
2. Bot asked qualification questions: name, phone, nature of request.
3. Answers are written to lead fields: crm.lead.update with NAME, PHONE, COMMENTS filled.
4. If the client entered a phone number — the bot searches CRM: crm.contact.list filtered by PHONE. Found — updates; not found — creates.
5. When transferring to an operator — the lead is already filled; the operator sees the chat history in the card.

The creation/update of a CRM entity automatically appears in the timeline — this is standard behavior of the crm module.

Real Case: Bot for an Online Store

Task: online home appliance store, ~500 requests per day via Telegram. 70% of questions — "where is my order?", "can I return it?", "is model X in stock?".

Architecture: Node.js server on VPS + Bitrix24 Bot Framework + integration with 1C via REST.

Scenarios:

• "Where is my order" → bot requests order number → queries 1C (via 1C REST service) → returns status to client. No operator needed.
• "Item availability" → search the Bitrix catalog (iblock.element.list) → returns current stock level.
• "Return" → FSM: purchase date → reason → product photo (accepted via disk.folder.uploadfile) → creates a task for the manager.
• Everything else → transfer to operator with topic tag.

Result after one month: operators handle 35% of the original volume. The remaining 65% is handled by the bot. Average response time for a typical question dropped from 8 minutes to 15 seconds.

Bottleneck: processing photos from clients. Bitrix24 passes files via temporary links with a short TTL — the bot server must download them within 30–60 seconds, otherwise the link expires.

What Affects Effort

Minimum working bot with 3–4 scenarios and CRM integration — from 40 hours. Complex multi-scenario bot with NLP and external integrations — 80–120 hours.