Как настроить автоматический переход основной сделки по стадиям дочерних: робот для Битрикс24

Ручной контроль дочерних сделок: где воронка зависает

На одном из внедрений у производителя кухонь увидели типовую картину. Клиент оформляет заказ — в CRM появляется основная сделка, а от неё три дочерние: доставка, монтаж мебели, монтаж столешницы. Каждую ведёт свой исполнитель, в своём темпе. Основная сделка при этом висит на стадии «Монтаж» и ждёт, пока менеджер вручную проверит: все три дочерние закрыты? Тогда можно двигать дальше и подписывать акт приёмки.

Проверяют по-разному. Кто-то открывает основную сделку и проходится по связанным, кто-то держит список в голове. Пока сделок пять — работает. Когда их пятьдесят, основные сделки начинают зависать: дочерние давно завершены, а акт клиенту никто не выставил, потому что «ещё вчера вроде монтаж шёл».

Задача решается роботом: он сам следит за дочерними сделками и двигает основную, когда все они прошли нужную стадию. Разберём, как это устроено и как настроить.

Почему штатные роботы Битрикс24 не управляют связанными сделками

Стандартный робот в Битрикс24 живёт внутри одной сделки. Он умеет изменить её поля, поставить задачу, отправить письмо, передвинуть саму сделку по стадии. Но заглянуть в другую сделку и посчитать, сколько связанных сделок уже закрыто, он не может — в условиях робота просто нет такой логики.

Обычно на этом месте начинаются обходные пути: регламент «менеджер проверяет каждое утро», отчёт в BI, бизнес-процесс от разработчика. Первое ломается о человеческий фактор, второе только показывает проблему, но не решает её, третье стоит денег и времени на каждую новую воронку.

Как работает робот перехода основной сделки по стадиям дочерних

Робот «Переход основной сделки по стадиям дочерних» из приложения CRM Роботы + AI 2.0 закрывает именно этот сценарий. Он ставится на стадию дочерней воронки и при срабатывании поднимается до основной сделки, проверяет все дочерние и, если условие выполнено, двигает основную.

Логика проверки дочерних сделок по шагам

1. Дочерняя сделка попадает на контрольную стадию — например, «Архив распределенных сделок».
2. Робот находит по полю связи основную сделку этой дочерней.
3. Из основной сделки забирает список всех дочерних из множественного поля.
4. Проверяет каждую: прошла ли она контрольную стадию.
5. Если прошли все — переводит основную сделку на целевую стадию, например «Подписать Акт Приемки». Если хотя бы одна ещё в работе — не делает ничего и ждёт следующего срабатывания.

Важно: робот запускается на каждой дочерней сделке отдельно. Последняя закрытая дочерняя и станет той самой, после которой основная сдвинется.

Пять настроек робота

В диалоге настроек всего пять параметров:

• поле с основной сделкой — указывается в дочерней сделке;
• множественное поле с дочерними сделками — в основной;
• контрольная стадия дочерних сделок;
• целевая стадия основной сделки;
• считать ли проигранные дочерние сделки прошедшими этап.

Опция учёта проигранных дочерних сделок

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

Включать опцию стоит почти всегда. Выключать — только если проигрыш дочерней сделки действительно должен останавливать весь заказ, и об этом кто-то должен узнать вручную.

Настройка робота смены стадии основной сделки по шагам

Вся настройка занимает около пятнадцати минут, программист не нужен:

1. Создайте в дочерней воронке поле «Основная сделка» с типом «Привязка к элементам CRM» (сделка). В нашем примере это поле UF_CRM_1784805944.
2. Создайте в основной воронке множественное поле «Дочерние сделки» с той же привязкой — у нас UF_CRM_1784805969.
3. Заполните поля у существующих сделок: в каждой дочерней укажите основную, в основной соберите список дочерних.
4. Откройте роботов в дочерней воронке и поставьте робота «Переход основной сделки по стадиям дочерних» на контрольную стадию.
5. Заполните пять параметров: оба поля, контрольную стадию, целевую стадию и опцию про проигранные.
6. Сохраните и проверьте на одной тестовой связке сделок: переведите дочерние на контрольную стадию и убедитесь, что основная ушла на целевую.

Отдельное внимание — пункту 3. Робот не ищет дочерние сделки сам, он читает готовые связи из полей. Если связи не проставлены, проверять будет нечего.

Пример из практики: дочерние сделки на производстве кухонь

Так эта схема работает у производителя кухонь из начала статьи. Основная сделка — заказ на кухню. От неё созданы три дочерние: доставка, монтаж мебели, монтаж столешницы. У каждой свой исполнитель и свой срок.

Робот стоит на стадии «Архив распределенных сделок» дочерней воронки. Водитель закрыл доставку — робот проснулся, проверил: монтаж ещё в работе, основную не трогаем. Сборщики закончили мебель — снова проверка, столешница ещё не смонтирована, ждём. Закрылась последняя дочерняя — все три прошли контрольную стадию, и основная сделка сама переехала на «Подписать Акт Приемки». Менеджер увидел её там утром и выставил акт в тот же день, а не через неделю, когда случайно вспомнил про заказ.

Где ещё применять робот контроля дочерних сделок

Схема «основная сделка плюс дочерние» встречается чаще, чем кажется:

• Строительство и ремонт: основной контракт, а дочерние — проектирование, поставка материалов, отдельные этапы работ. Объект сдан, когда закрыты все этапы.
• Установка оборудования: дочерние сделки на монтаж, пусконаладку и обучение персонала. Основная переходит к акту, когда всё три завершены.
• IT-проекты: разработка, тестирование и внедрение как отдельные сделки под одним проектом.
• Дизайн-проекты: концепция, чертежи, авторский надзор — заказ считается готовым после последнего этапа.

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

Типичные ошибки при настройке связанных сделок в Битрикс24

Поля связи не созданы или не заполнены. Робот настроен, стадии выбраны, а ничего не происходит — потому что у сделок пустые поля связи. Проверяйте сначала данные, потом робота.

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

Забыли опцию про проигранные сделки. Одна отменённая дочерняя блокирует основную навсегда, и это выглядит как «робот сломался». На самом деле он честно ждёт, пока все дочерние пройдут стадию.

Дочерние сделки ведут в другой воронке, а поля завели только в одной. Связи и робот должны жить там, где реально двигаются дочерние сделки. Если дочерние в отдельной воронке — поле «Основная сделка» и робот настраиваются именно в ней.

FAQ: вопросы о роботе перехода основной сделки

Сколько дочерних сделок поддерживает робот?

Жёсткого ограничения по количеству нет — робот читает всё, что лежит в множественном поле. Проверяли на связках с десятком дочерних, работает стабильно.

А если нужны разные целевые стадии для разных типов заказов?

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

Что будет, если одна дочерняя сделка проиграна?

Смотря как настроена опция учёта проигранных. Включена — проигранная считается прошедшей этап, основная двигается дальше. Выключена — основная останется на месте.

Робот работает только со сделками или со смарт-процессами тоже?

Сценарий описан для связки «сделка — сделки». Для смарт-процессов логику можно собрать через других роботов приложения, но это отдельная настройка.

Сколько времени занимает настройка робота?

Минут пятнадцать: два поля связи, один робот на контрольной стадии, пять параметров. Плюс тестовый прогон на одной связке сделок.

Нужен ли разработчик для настройки?

Нет. Два поля, один робот, пять параметров — это работа администратора портала, а не программиста.

Заключение: кому нужен робот синхронизации стадий сделок

Робот пригодится всем, у кого заказ распадается на несколько параллельных работ: производство на заказ, строительство, установка оборудования, проектные услуги. Если менеджер сегодня вручную открывает основную сделку и проверяет «ну что там дочерние» — эту проверку уже можно отдать роботу.

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

Робот входит в приложение CRM Роботы + AI 2.0 — там же больше пятидесяти роботов для типовых задач CRM, которые штатная автоматизация Битрикс24 не закрывает.