The CEO asks in plain words — the CRM answers in numbers

Context

A manufacturing and retail company — made-to-order kitchens and cabinet furniture, two showrooms, a city of over a million people. 50 employees in the CRM, ~10 selling reps. The client and primary user is the CEO. This is the third system built for this client.

Management saw the business only in averages: the CRM held 2,470 leads and 1,815 deals, but any management question — which rep is dragging their feet, which channel brings in the money, what is stuck — required a manual export and a hand-built report. Some cuts weren’t produced at all: the breakdown of “which rep got leads from which source” existed only as two separate views.

The second layer of losses was response speed. In made-to-order furniture a customer sends an inquiry to several companies at once, and the deal goes to whoever answers first. Nobody tracked in real time that a new lead had been sitting unanswered for an hour or half a day — such leads quietly leaked away.

Constraints

• Bitrix24 custom-field labels aren’t exposed via REST. The portal is heavily customized — 30+ pipelines and smart processes, hundreds of service fields, and the API returns codes instead of names. Key fields had to be identified from the data: export the values and check them against the client’s report — the designer field was confirmed by amounts matching to the ruble
• Permissions were granted in stages. The initial access covered only the CRM — employee names and task creation were unavailable. The system had to degrade honestly rather than crash
• Zero external dependencies. An operations requirement: no pip install, standard library only. The XLSX generator was written by hand on top of zipfile and XML
• Excel locales. The first CSV export “fell apart” on the client’s machine — the delimiter and decimal comma depend on the locale. Rewritten to produce real XLSX
• The client’s data quality as a product constraint. “Expected close date” is filled in for 2% of leads; the “Measurement done” stage is marked on roughly 15% of deals. The system had to be designed to show the gaps honestly rather than produce pretty but false numbers

Audit findings

This is the state of the client’s data before implementation — what the system uncovered, not the result of its work.

• 119 deals stuck at sales stages were sitting open at launch — one rep alone had 27 deals worth 13 million ₽. Nobody was flagging them systematically
• 93% of the key partner channel’s revenue was unattributed. Partner designers bring in large orders, but the deals in that channel had no specific designer on the record (9.5 of 10.2 million ₽ for one rep). The question of whom to pay commission and whom to work more closely with was being answered blind
• The method for measuring the deal cycle understated it by a month. The first version of the calculation showed a median “contract → won” of 86 days; after the method was fixed — 116. Customers would have been promised lead times a month shorter than reality

Solution

What it delivers

The CEO talks to the sales department through Telegram in ordinary language: “what’s on fire?”, “how many will we close this month?”, “which designers brought this rep’s deals?”, “set a task to call back on this deal”. The system understands the question, runs the numbers from the CRM and replies with a finished report plus a short “what to do first” takeaway. No exports, no pivot tables.

Unprompted, the system watches the flow around the clock: a new lead without a first response for longer than the standard gets a ping with the rep’s name, the source and the waiting time; a second time — escalation. Every morning at 10:00 a digest arrives: yesterday’s new leads by source and by rep, which leads are still unaccepted, stalled deals, revenue and payments, and a “what’s on fire first” line.

Analytics: pipeline and stage-by-stage conversion, revenue by source, rep KPIs, a ranking of partner designers, database reactivation, closing forecast, stage durations with medians and Excel export, and a single-file dashboard with charts. In total — 8 tools, 13 reports, 15 menu commands.

How it works

The same two-layer design as in all my systems: code does the math, the LLM understands the question. All arithmetic is deterministic Python over Bitrix24 REST: sums, conversions and medians are computed by code, not by the language model. The model parses a free-form phrase (“over 3 weeks”, “for June”, “from 1 to 15 July”), works out the dates itself and calls the right tool via function calling. The finished report is sent to the user straight from code, bypassing any retelling by the model — otherwise details got lost, a bug caught in live use.

Nothing is written to the CRM without an explicit “yes” from a human. The system shows a task card and waits for confirmation. For that, two modes are kept separate — viewing, and a proposal that pins down exactly what is being confirmed: mixing the two was a real vulnerability found in review. The client tunes the behavior straight from the chat — response standard, digest time, “stalled” thresholds — with no developer involved and no restart.

The heavy calculation — parsing stage history — takes ~38 seconds, so the CRM snapshot is cached for 5 minutes and heavy calculations for 30: without that, the chat would have “frozen”.

Outcome

The system is in production and used by the CEO daily. Development from first commit to handover: 2–3 days, 4,606 lines in 18 modules.

What I’d do differently

• Measurement method first, code second. The first version of the stage-duration calculation understated the cycle: it counted only deals whose start and end both fell within the sample window and ignored unfinished ones. “Contract → won” showed 86 days instead of 116. For duration metrics, build in sample truncation and censoring from the start
• Tools for the LLM are read-only by default. A free-form phrase like “what tasks should I set?” overwrote the list that the user’s “yes” referred to — in the worst case the wrong tasks would have gone into the CRM, to the wrong people. Writes go by a separate path, with a record of exactly what is being confirmed
• Test both paths, not one. The report worked correctly via a command, but when asked in words the model retold the data and lost the breakdown. Only the command path had been tested. If a function has two entry points, test both
• Don’t mistake “no data” for “impossible”. The bot refused the “rep × source” cut, blaming an integration limitation. In fact both fields came in the same export — 15 lines of code were missing. Distinguish “the data physically isn’t there” from “the cut hasn’t been written”

Stack

What it means in money

At launch, 119 deals were sitting in the CRM stuck at sales stages — one rep alone had 27 deals worth 13 million ₽. That is money that was already in your pipeline; there was simply nobody to watch it systematically. If daily monitoring brings even a couple of such deals a month back into play at your average order value — do the math on how many months it takes the implementation to pay for itself. After that, all you pay is the monthly fee — less than a manager picking through deals by hand.

Where next

People also look at

Does your CRM only answer with exports, too?