Вернуться к статьям Когда основная сделка ждёт завершения дочерних
Один заказ нередко распадается на несколько параллельных работ. В CRM появляется основная сделка, а рядом с ней — дочерние: доставка, монтаж, согласование документов или отдельные этапы проекта.
Проблема возникает в конце. Дочерние сделки уже завершены, но основная остаётся на прежней стадии, пока менеджер не проверит каждую карточку. При большом потоке проверку легко пропустить.
Робот «Переход основной сделки по стадиям дочерних» из приложения CRM Роботы + AI 2.0 проверяет общий результат дочерних сделок. Когда все они прошли заданную стадию, робот переводит основную сделку дальше.
Штатные роботы Битрикс24 и агрегация дочерних сделок
В Битрикс24 робот выполняет действие, когда элемент CRM попадает на определённую стадию, а триггер следит за событием и может сменить стадию. Этот принцип и расположение автоматизации по воронкам описаны в официальной справке об автоматизации продаж.
Штатных инструментов достаточно для прямых сценариев: изменить текущую сделку, создать связанный элемент смарт-процесса, заполнить выбранные поля или сменить стадию. Но условие «перевести основную сделку, только когда все связанные дочерние прошли контрольный этап» требует проверить состояние нескольких карточек. В описываемой схеме эту агрегацию выполняет робот приложения.
Отчёт или список покажут незавершённые работы, но сделку не передвинут. Бизнес-процесс придётся проектировать и поддерживать. Готовый робот рассчитан на одно правило: дождаться всех дочерних и продолжить основную.
Как робот переводит основную сделку по стадиям дочерних
Робот размещают на контрольной стадии дочерней воронки. Он срабатывает в дочерней сделке, находит основную по полю связи, читает сохранённый в ней список дочерних и сравнивает их стадии с заданным условием.
Когда достаточно связи один-к-одному
Если у сделки есть один связанный элемент, агрегировать список не нужно. Например, одна заявка на выезд в смарт-процессе связана с одной сделкой: при провальной стадии заявки сделка переходит в «Выезд отменён».
Битрикс24 умеет создавать элемент смарт-процесса, связывать его с CRM-карточкой и изменять связанный элемент. Эти возможности перечислены в инструкции по роботам смарт-процессов. Штатный робот или триггер подходит, если он умеет адресовать нужный тип связанного элемента. Иначе потребуется бизнес-процесс или приложение. Связь должна указывать на единственную карточку, лучше всего по ID.
Когда нужна агрегация дочерних сделок
Если у основной сделки несколько дочерних, срабатывание одной из них ещё не говорит о готовности заказа. Роботу нужно получить весь список и проверить каждый элемент.
У заказа четыре дочерние сделки: три дошли до контрольной стадии, одна остаётся в работе. Основная не двигается. После завершения последней дочерней робот повторит проверку. Для такой связи один-ко-многим и предназначен робот.
Логика проверки дочерних сделок
- Дочерняя сделка попадает на контрольную стадию.
- Робот читает поле «Основная сделка» и находит нужную карточку.
- В основной сделке он получает значения множественного поля «Дочерние сделки».
- Каждая карточка проверяется по контрольной стадии и правилу учёта проигранных сделок.
- Если условие выполнено для всего списка, основная сделка переходит на целевую стадию. Иначе она остаётся на месте до следующего срабатывания.
Робот запускается отдельно на каждой дочерней сделке. Обычно переход основной вызывает та дочерняя, после которой общий результат впервые стал достаточным.
Параметры робота перехода основной сделки
В настройках указывают:
- поле с основной сделкой в дочерней карточке;
- множественное поле с дочерними сделками в основной карточке;
- контрольную стадию дочерних сделок;
- целевую стадию основной сделки;
- правило учёта проигранных дочерних сделок.
Как учитывать проигранные дочерние сделки
Предположим, по заказу созданы три дочерние сделки. Две завершены успешно, а третья закрыта как проигранная, потому что часть работ отменили. Если проигрыш не считается прохождением этапа, основная сделка останется на месте. Если считается, закрытая дочерняя перестанет блокировать общий переход.
При частичной отмене услуги проигранную сделку обычно можно считать завершённой веткой. Если её проигрыш означает срыв всего заказа, основную лучше не переводить автоматически. Оставьте её на контрольной стадии и при необходимости настройте уведомление ответственному.
Связи, поля и защита перехода основной сделки
Почему для перехода основной сделки нужен уникальный ID
Связь должна точно отвечать на вопрос, какую карточку менять. Название сделки может повторяться, изменяться вручную или формироваться по одному шаблону, поэтому оно не подходит как идентификатор.
Для прямой связи со смарт-процессом официальный helpdesk рекомендует фильтр по ID: если фильтр находит несколько элементов с одинаковым значением, робот изменит первый найденный. После создания связанного элемента сохраните его ID в пользовательское поле исходной карточки и используйте это поле в следующих роботах.
В схеме «основная сделка — дочерние сделки» идентификаторами служат поля привязки к элементам CRM. В дочерней хранится ссылка на одну основную, в основной — полный список дочерних. Робот приложения читает обе стороны связи.
Ограничьте ручное изменение служебного поля доступными правами, настройкой формы или проверкой в автоматизации. Обычным сотрудникам не следует менять его вручную.
Какие поля перенести, чтобы связь сделок не потерялась
Связанные карточки остаются разными сущностями. Ссылка между лидом, сделкой и элементом смарт-процесса не копирует пользовательские поля автоматически. Лид здесь нужен только как пример карты данных, а не как отдельный маршрут робота.
| Данные | Откуда | Куда | Проверка |
|---|---|---|---|
| Тип работ | Поле лида или сделки | Поле сделки или смарт-процесса | Совпадают варианты списка |
| Адрес и дата | Исходная карточка | Связанный элемент | Совпадают типы полей и формат даты |
| ID связи | Созданный элемент | Служебное поле исходной карточки | Записан уникальный идентификатор |
При создании смарт-процесса штатный робот переносит только значения, указанные в настройках. Пользовательские поля нужно сопоставить явно. Если сначала требуется привести в порядок состав, названия и видимость полей, используйте инструкцию по настройке карточек лидов и сделок в Битрикс24.
Как защитить основную сделку от обратного перехода
Перед настройкой зафиксируйте событие, ID связи, условие и разрешённое направление перехода. В рабочей таблице достаточно двух сценариев:
| Связка | Событие и ID связи | Условие | Защита |
|---|---|---|---|
| Основная сделка ↔ дочерние сделки | Дочерняя вошла в контрольную стадию; поля «Основная сделка» и «Дочерние сделки» | Все дочерние прошли контроль или закрыты по разрешённому правилу | Основная ещё не дальше целевой стадии; обратный переход запрещён |
| Сделка ↔ один смарт-процесс | Связанный элемент закрыт; его уникальный ID сохранён в сделке | Стадия и причина закрытия требуют перехода | Фильтр по ID и проверка текущей стадии сделки |
Опция обратного перехода в штатных триггерах включается явно; это указано в справке о триггерах управления элементом. Если процесс должен двигаться только вперёд, не разрешайте возврат «на всякий случай». Перед сменой стадии проверяйте текущее положение основной сделки, чтобы позднее событие не откатило завершённую карточку.
Настройка робота перехода основной сделки по шагам
1. Опишите связи и стадии
Запишите названия основной и дочерней воронок, контрольную стадию дочерних и целевую стадию основной. Решите, что делать с проигранной дочерней сделкой.
2. Создайте поля связи
В дочерней воронке создайте поле «Основная сделка» типа «Привязка к элементам CRM». В основной воронке создайте множественное поле «Дочерние сделки» того же типа. Если поля уже есть, проверьте их тип и фактическое заполнение.
3. Заполните обе стороны связи
В каждой дочерней сделке укажите основную, а в основной соберите полный список дочерних. Новый робот не восстановит исторические связи по названиям, поэтому старые карточки при необходимости заполняют отдельно.
4. Разместите робота в дочерней воронке
Откройте автоматизацию воронки, где движутся дочерние сделки. Поставьте робота на контрольную стадию и заполните пять параметров. Настройки привязаны к сущности, воронке и стадии; тот же принцип показан в инструкции по роботам управления элементом.
5. Проверьте права и обязательные поля
Пользователь, от имени которого выполняется автоматизация, должен видеть обе воронки и иметь право менять нужные поля и стадии. Если целевая стадия требует обязательное поле, заполните его до перехода или добавьте проверку.
6. Запустите тестовую связку
Создайте одну основную и несколько дочерних сделок с тестовыми данными. Проводите их через сценарий по очереди. Проверьте успешное завершение, проигрыш, пустую связь и повторное срабатывание.
Тестовая матрица перехода основной сделки
| Тест | Исходные данные и действие | Ожидаемый результат |
|---|---|---|
| Не все дочерние готовы | Из трёх готова одна; перевести её на контрольную стадию | Основная остаётся на месте |
| Последняя дочерняя готова | Две уже прошли контроль; перевести третью | Основная переходит на целевую стадию |
| Проигрыш учитывается | Одна успешная, одна проигранная; опция включена | Основная переходит дальше |
| Проигрыш блокирует | Опция выключена; закрыть дочернюю как проигранную | Основная не меняется; если настроено уведомление, ответственный получает сигнал |
| Пустая связь | В дочерней нет основной; выполнить переход | Чужие сделки не меняются, ошибка видна в журнале |
| Неполный список | В основной указаны две дочерние из трёх; закрыть две | Тест выявляет ошибку данных, список исправляют |
| Повторное срабатывание | Основная уже на целевой стадии; повторить событие | Основная не откатывается и не меняется повторно |
| Обязательное поле пусто | Целевая стадия требует значение; завершить последнюю дочернюю | Переход блокируется, причина видна в журнале |
Исторические связи и несколько направлений перехода лучше сначала спроектировать с интегратором.
Диагностика ошибок перехода основной сделки
Неверный ID связанного элемента
Робот не находит карточку или меняет не ту. Сравните значение служебного поля с ID связанного элемента и проверьте, не остался ли там идентификатор старой карточки.
Неуникальный фильтр
При одинаковых названиях меняется первый найденный элемент. Замените фильтр по названию, адресу или клиенту на фильтр по ID.
Робот запущен не в той воронке
Дочерняя сделка дошла до нужной по смыслу стадии, но журнал пуст. Проверьте сущность и воронку над колонкой роботов: одинаковые названия стадий в разных воронках не делают их одной стадией.
Разрешён обратный переход
После позднего события основная возвращается назад. Отключите переход на предыдущий статус и добавьте условие по текущей стадии.
Пустое обязательное поле
Связь найдена и условие выполнено, но переход не завершается. Проверьте требования целевой стадии и журнал робота. Поле нужно заполнить заранее либо при пустом значении остановить переход и уведомить ответственного.
Для проверки последовательности действий используйте отладчик роботов. Битрикс24 сохраняет сессии и результаты отладки; ссылка на инструмент есть в официальной статье об автоматизации продаж.
Где применять контроль стадий дочерних сделок
Подход подходит процессам, где один коммерческий результат зависит от нескольких самостоятельных работ:
- поставка, монтаж и ввод оборудования в эксплуатацию;
- проектирование и отдельные этапы работ;
- разработка, проверка и запуск результата;
- согласование договора несколькими подразделениями;
- комплексный заказ с разными ответственными.
В типовом проекте основная сделка обозначала заказ, а дочерние — отдельные работы. Пока одна работа оставалась открытой, основная не менялась. После завершения последней дочерней робот перевёл её на стадию подготовки итоговых документов.
Если у основной сделки всегда одна дочерняя, агрегирующий робот избыточен. Используйте прямую связь один-к-одному с уникальным ID и отдельным условием перехода.
FAQ о переходе основной сделки по стадиям дочерних
- Где должен стоять робот: в основной или дочерней воронке?
В дочерней, на стадии, достижение которой запускает общую проверку. Основную робот находит через поле связи.
- Достаточно ли заполнить связь только в дочерней сделке?
Нет. В дочерней хранится ссылка на основную, а в основной — множественный список дочерних. Оба поля должны содержать актуальные значения.
- Можно ли искать связанную карточку по названию?
Фильтр по названию может сработать, пока названия не повторяются. Для рабочего процесса используйте уникальный ID или поле привязки.
- Что произойдёт с проигранной дочерней сделкой?
Результат зависит от параметра робота. Её можно считать завершённой веткой либо оставить блокирующей. Выбор должен соответствовать регламенту процесса.
- Переносятся ли пользовательские поля при создании связанной сущности?
Только значения, для которых настроено сопоставление или заполнение. Сама связь карточек не копирует адрес, дату, тип работ и другие поля.
- Может ли основная сделка вернуться на предыдущую стадию?
Переход назад разрешайте только для отдельного сценария. Проверяйте опцию триггера и текущую стадию, чтобы позднее событие не откатило завершённую сделку.
- Нужен ли разработчик для настройки?
Базовую связку может настроить администратор, знакомый с воронками и правами CRM. Интегратор нужен при переносе старых данных, сложной маршрутизации или двусторонних переходах.
Вывод: когда нужен робот перехода основной сделки
Робот из приложения CRM Роботы + AI 2.0 нужен в схеме один-ко-многим, где стадия основной сделки зависит от общего состояния дочерних. Он не исправляет пустые связи и поля: сначала приведите в порядок данные, затем настройте переход.
Начните с одной пары воронок. Зафиксируйте правила, создайте двустороннюю связь, решите судьбу проигранных сделок и прогоните тестовую матрицу. Для связи один-к-одному используйте более простую схему с уникальным ID.
Робот «Переход основной сделки по стадиям дочерних» входит в приложение CRM Роботы + AI 2.0. Перед установкой проверьте, что в основной и дочерних воронках уже созданы и заполнены поля связи.