RYC Software
Get an estimate

What AI can already do in the Bitrix24 CRM

Call and chat summaries, deal scoring, draft replies and document parsing in the Bitrix24 CRM — and how to protect API keys and client data while doing it.

Companies using Bitrix24 keep asking the same question: “Can we add artificial intelligence to the CRM?” Behind it there is usually not a wish to chat with a bot but a very concrete pain: managers do not manage to fill in cards, the head of sales does not listen to calls, incoming documents are entered by hand. Let us go through which of these tasks language models solve today and how to embed them in Bitrix24 without putting data at risk.

Four scenarios that work

Call and conversation summaries. The call recording is transcribed, and the model writes a short summary into the deal timeline: what was agreed, which objections came up, what the next step is. The same goes for long chats and open channels. The head of sales reads a few lines instead of listening to the recording, and a new manager quickly gets into the context of someone else’s deal.

Deal scoring. The model assesses a deal from the conversation history and CRM data: how interested the client is, whether there are signs the deal has stalled, what is missing for the next step. The result is written to a card field, and you can build filters and reports on it.

Draft replies. In a chat or an email the manager gets a ready reply option that takes the client’s history into account. A person sends it — after checking and editing.

Data extraction from documents. From an invoice or contract that arrives, the model pulls out details, amounts, dates and line items and places them in CRM fields. The employee only has to check the result rather than type it in.

To these scenarios we add assistants in open channels, which answer routine questions and hand the dialog to a manager, and bots on the internal knowledge base for employees.

How this is embedded in Bitrix24

Technically, an AI feature is an ordinary Bitrix24 app with a server side. The app subscribes to portal events, for example a finished call or a new message, receives the data it needs through the REST API, sends it to the model and writes the result back: into the timeline, a card field or a chat. For the manager it looks like a new tab or block in a familiar card, not like a separate service.

Keys and data: three rules

The main question clients ask is security. We follow three rules.

  1. API keys stay on the server only. The model provider’s key never reaches the browser or the interface code. Anyone can read code that runs in the browser, so every call to the model goes through the server side.
  2. Only what is needed goes to the model. A call summary does not need company details, and parsing an invoice does not need the correspondence history. Wherever possible we strip extra fields and personal data before sending.
  3. The client chooses the provider. We do not tie a solution to one model. We pick the provider to fit the client’s requirements for data storage, quality and request volume, and it can be switched if needed.

Separately, about mistakes. A language model can be wrong, so we build scenarios in which the decision stays with a person: the manager sends the draft, and important fields extracted from documents can be confirmed manually.

Where to start

It is best to start with one scenario where the time saving is clear — most often call summaries or parsing of incoming documents. Such a scenario quickly shows the client the value and helps decide what to automate next.

If you are thinking about AI in your CRM, send us a description of the task. Within 1–2 business days we will suggest an approach and estimate the scope of work.

Tell us about the task

Send a description — we will return a timeline and scope estimate in 1–2 business days.

Get an estimate