Новые бизнес-процессы Битрикс24: как автоматизировать сделки без лишних дублей

В справке Битрикс24 от 17 сентября 2026 года подробно описаны действия группы «Продажи и CRM» в новом конструкторе бизнес-процессов. Они позволяют создавать и менять карточки, планировать дела и передавать данные между связанными элементами. Действие выполняется после запуска процесса триггером.

Для отдела продаж это возможность убрать ручное копирование. Но у автоматизации есть неприятная особенность: она повторяет не только полезные операции, но и ошибки в правилах. Если запуск настроен слишком широко, вместо одной задачи менеджер получает несколько, а клиент — повторные обращения.

Возьмём условный процесс согласования поставки. После подтверждения условий нужно назначить ответственного, подготовить следующее действие и сохранить значимые данные в карточке. Прежде чем собирать схему, стоит записать, что именно должно существовать в конце и что уже создано раньше.

Это позволяет отделить обновление от создания. Если компания уже есть в CRM, новой карточкой нельзя подменять изменение её данных. Если дело по согласованию открыто, повторное срабатывание не должно автоматически означать второе одинаковое поручение.

Нужно определить конкретное событие: нужный переход стадии, изменение выбранного поля или ручную команду сотрудника. Формулировка «когда со сделкой что-то произошло» слишком широкая. В рабочей CRM карточки меняют менеджеры, интеграции и другие процессы.

Отдельный вопрос — повторное прохождение стадии. Клиент может вернуться к согласованию после изменения цены. Здесь бизнес должен решить, создавать ли новый цикл работ, продолжать старый или требовать подтверждение менеджера. Конструктор не угадает эту логику за руководителя.

Для каждого действия укажите, откуда берутся ответственный, срок, сумма и реквизиты. Пустое обязательное поле должно приводить к понятной реакции: остановке с уведомлением или передаче человеку. Подставлять случайного сотрудника только ради завершения схемы опасно для учёта.

Я бы отдельно проверила сценарий смены ответственного. Если процесс запустился вчера, а сделку сегодня передали другому человеку, кто получает новое дело? Такая мелочь быстро превращает полезную автоматизацию в источник потерянных задач.

На тестовых карточках пройдите обычную сделку, повторный запуск, возврат стадии и отсутствие исходных данных. Затем проверьте работу с ограниченными правами: схема, доступная администратору, может вести себя иначе в повседневной роли менеджера.

Зафиксируйте, где видно выполнение процесса и кто разбирает ошибки. Если сотрудник замечает только отсутствие результата, ему приходится заново делать всё вручную, рискуя получить дубли после восстановления системы.

Обновление справки не означает одновременную доступность всех функций на каждом портале: Битрикс24 предупреждает о постепенном появлении обновлений. Начинать лучше с одного понятного сценария. Его ценность измеряется сокращением ручных действий и числа ошибок, а не количеством блоков в красивой схеме.

The Bitrix24 help center, updated on September 17, 2026, details the actions in the 'Sales and CRM' group within the new business process builder. These actions allow you to create and modify cards, schedule tasks, and transfer data between linked elements. The action executes after the process is triggered.

For sales teams, this offers a way to eliminate manual copying. However, automation has a downside: it repeats not only useful operations but also errors in the rules. If the trigger is set too broadly, a manager may receive multiple tasks instead of one, and a client may receive duplicate follow-ups.

Consider a hypothetical supply approval process. After confirming terms, you must assign a responsible person, prepare the next step, and save key data in the card. Before building the workflow diagram, write down exactly what should exist at the end and what has already been created.

This separates updates from creation. If a company already exists in the CRM, a new card cannot replace its data updates. If a task is already under approval, a re-trigger should not automatically create a duplicate assignment.

Define a specific event: a stage transition, a field change, or a manual command by an employee. The phrasing 'something happened with the deal' is too broad. In a live CRM, cards are modified by managers, integrations, and other processes.

A separate issue is re-entering a stage. A client may return to approval after a price change. The business must decide whether to start a new workflow cycle, continue the existing one, or require manager confirmation. The builder cannot guess this logic on behalf of leadership.

For each action, specify the source for the responsible person, deadline, amount, and billing details. An empty required field must trigger a clear response: stop with a notification or escalate to a human. Assigning a random employee just to complete the scheme is dangerous for accounting.

I would separately test the scenario of changing the responsible person. If the process started yesterday and the deal is transferred to another person today, who receives the new task? This small detail can quickly turn useful automation into a source of lost tasks.

On test cards, run a standard deal, a restart, a stage return, and a scenario with missing initial data. Then verify behavior with restricted permissions: a workflow visible to an administrator may behave differently when executed by a regular manager.

Identify where process execution is visible and who handles errors. If an employee sees only a lack of results, they must manually redo everything, risking duplicate records when the system recovers.

Documentation updates do not mean all features are immediately available on every portal; Bitrix24 warns that updates roll out gradually. Start with a single, clear scenario. Its value is measured by the reduction in manual actions and errors, not by the number of blocks in a visually appealing workflow.