Call analytics in Bitrix24: AI scoring for 100% of sales conversations

TL;DR. The sales director had time to listen to 5-10% of calls; nobody reviewed the rest. The system scores 100% of them: transcription with speaker separation, a 0-10 score against the company's own rubric, and the result in the Bitrix24 deal card within minutes. Inference runs locally, so call recordings stay on the client's servers.

Situation: why call recordings do nothing on their own

Recordings had piled up in the CRM for years, and nobody listened to them systematically. The sales director could get through 5-10% of conversations — each one took 15-20 minutes to play back, match against the deal stage, and turn into feedback for the rep.

Quality control rested on spot checks and on remembering which reps usually do well. There was a separate constraint: recordings of client conversations count as sensitive data, so sending them to a cloud API was out.

Task

1. Score every sales call, not a sample.
2. Score against this specific team's methodology: different deal stages call for different behaviour from the rep.
3. Keep recordings and transcripts inside the client's perimeter, with no cloud APIs.
4. Deliver the result where the rep and the director already work — the Bitrix24 deal card.

What we built: the call scoring pipeline

Bitrix24 fires a webhook when a call appears on a deal. The API validates the request and hands the job to a background worker, which downloads the recording, transcribes it and separates the rep's speech from the client's.

The transcript, together with the deal context, goes to a local LLM for a 0-10 score against the sales team's own rubric. That rubric is split across 7 funnel stages, and the stage is taken from the deal's position in Bitrix24. Hard limiters run separately: if the rep failed to agree a next step or behaved unprofessionally, the score is forced down regardless of the rest of the conversation.

The score, a summary and the next step come back as a comment in the deal timeline, linked to a cumulative PDF report covering every call on that deal. Low scores notify the sales director; high ones are flagged as reference examples for training new reps.

Transcription and the LLM run on the client's GPU. Neither the recording nor the transcript reaches an external service.

Result

• 100% of calls get scored, against 5-10% under manual review.
• Reviewing one call went from 15-20 minutes of human work to roughly 40 seconds of machine time.
• Recordings and transcripts never reach an external API. There is no token bill at all: instead of a cloud API invoice, a fixed GPU cost.
• The director sees a score against the stage the deal is actually at in the CRM, not a general impression of the conversation.

Key technical decisions

1. The scoring methodology is editable YAML, not code. Stages, score ranges and limiters live in a structured file a non-programmer can read. Changing what counts as a good call means editing a file, not a deploy.
2. The stage comes from the CRM, the model doesn't guess it. Each Bitrix24 funnel stage maps to a scoring stage through config, so the model scores the conversation against the deal's actual stage. Stages that shouldn't be scored are excluded by a separate list.
3. Deterministic scoring with quote verification. The final score isn't taken from the model's own report: it is bound to the range the model named, then computed in code from limiters backed by quotes from the transcript. That removed the spread between runs on one unchanged call.
4. Voicemail and no-answers are filtered out before the LLM runs. A call with almost no client speech is skipped — no score, no notification to the director, no noise on the deal.
5. Calibration before production. One script runs a batch of calls and compares the model's scores against the sales director's scores on the same conversations. A second measures transcription accuracy against reference transcripts. Those are different sources of error and have to be isolated separately.
6. Two interchangeable backends for the local LLM. Switched by a single setting, because the hardware in development differs from production.

FAQ

Do call recordings go to OpenAI or another cloud service?

No. Transcription and the language model run on the client's server. The recording and the transcript never leave the company perimeter. A side effect is that there is no token bill: instead of a variable cloud API invoice, a fixed GPU cost.

Can the scoring criteria be changed without a developer?

Yes. The scoring methodology lives in a YAML file: funnel stages, score ranges, limiters. Editing the criteria needs no code change and no deploy.

What does the company need in place for this to work?

Bitrix24 with call recording and an outgoing webhook configured, a server with a GPU, and a written scoring methodology — the one the sales director already uses when reviewing calls by hand. If there isn't one, formalising it is part of the first stage.

How long does call analytics take to implement?

One process end to end into production takes 1-2 months. The exact timeline depends on whether the scoring methodology exists already and whether there are test recordings available for calibration.

What would come next

The natural continuation is aggregated analytics across the team: which objections repeat, which stage loses the most deals, how a given rep's score moves over time. After that, prompting the rep before the call rather than reviewing it afterwards.

If your calls are recorded but nobody listens to them, let's talk it through in 30 minutes.