A customer sends a long email: some requirements are in the message, deadlines were discussed earlier, and the salesperson needs to understand quickly what has changed. If you simply switch on AI without agreeing on review rules, CRM may become another place where people have to correct someone else’s conclusions.
A better starting point is a small workflow: identify what information the employee needs, what they check themselves and what counts as an acceptable result. This is especially important for teams handling correspondence in several languages.
What has changed in Bitrix24
In its September 2026 updates overview, updated on 13 October, Bitrix24 announced email processing in BitrixGPT for CRM. This is a reason to test a new workflow on your own work, rather than change the entire process immediately.
A practical task might be: before drafting a reply, the salesperson needs a short list of the customer’s requirements. Test that task first. There is no need for a separate project to send replies automatically at this stage.
Suppose a company receives requests for equipment quotations. In a hypothetical email, a buyer changes the specification and asks for a revised proposal. A useful result helps the employee understand what changed and which questions remain open. This is a test scenario, not a promise that the tool will work without errors.
Check your portal’s conditions first
According to the official BitrixGPT settings guide, processing is available on commercial plans. Automatic processing is limited to the ru zone with a BitrixGPT + Marketplace subscription; manual processing is available in all domain zones and uses requests.
For a company in Kazakhstan or Kyrgyzstan, this is enough reason to avoid assumptions based on its country. Before estimating the work, check the actual domain zone, plan, subscription and remaining requests directly in the portal. The country where a team operates does not by itself establish that a particular mode is available.
Also clarify who will start processing, who will see the result and who is responsible for reviewing it. Feature availability and the team’s readiness to use it are separate prerequisites.
Choose one email category and build a test sample
Do not start with sales, complaints, accounting and supplier enquiries simultaneously. Choose one clear stream, such as quotation requests, and prepare a small sample approved for testing.
Useful examples include:
- a short email with a clear request;
- a long thread containing changing requirements;
- an email with no stated deadline;
- a message with ambiguous wording;
- correspondence in the languages your customers actually use.
Do not assume equal quality in Russian, Kazakh, Kyrgyz and English. Test each required language separately. Mixed-language speech, product names and internal abbreviations also deserve their own examples.
Before running the test, an employee should write down the expected result in their own words. Otherwise, assessment can quickly become “the text looks convincing.” A simple checklist is enough: what the customer requested, which facts are confirmed and what needs clarification.
Define what the salesperson must verify
Specify the categories to check: amounts, dates, quantities, specifications and commitments made by either party. If information is missing or contradictory, an acceptable result flags the uncertainty rather than filling the gap with a plausible assumption.
Agree how employees should record errors: the original passage, the incorrect conclusion and the correct interpretation. Without this, recurring problems are hard to distinguish from an isolated inconvenience.
Treat the email’s content, the employee’s decision and any external action as separate steps. Before sending a proposal or changing an agreement with a customer, the salesperson confirms the important facts. This is a proposed working rule, not a description of a built-in mandatory approval step.
Plan the correction process too: who will amend a record if an error is discovered later, and how will colleagues learn about the change? Implementation is complete only when exceptions have a clear handling procedure, rather than after the first successful example.
Assess the value and move into regular use
Compare work with and without AI using comparable emails. Count not only the time spent on the initial review but also checking and corrections. An attractive summary may fail to save the expected time if the salesperson still rereads the entire thread.
Define acceptance criteria in advance:
- which information must never be omitted;
- which errors require the workflow to be stopped;
- who resolves disputed results;
- what request usage is acceptable;
- when the team returns to manual review.
Choose numerical thresholds for your own task after initial testing. Do not apply savings promised in someone else’s example to your own correspondence.
First document the working procedure in a short guide, then expand the workflow. If correspondence should lead to a next action, our article on stalled deals in Bitrix24 will help.
To discuss implementation, prepare your email categories, required fields and examples of difficult situations. Contact QQDev through the Bitrix24 audit page. With this information, it is easier to determine whether configuration is sufficient or whether processes and integrations also need changes.