Ответственный — центральное поле любой сущности Битрикс24: по нему считаются отчёты и KPI, на него завязаны права «свои/чужие», ему приходят уведомления и задачи. Поэтому вопрос «как поменять ответственного» возникает каждый день: новый лид нужно отдать свободному менеджеру, сделки уволившегося — передать преемнику, зависшее согласование — поднять руководителю. Разберём все уровни: ручная смена, массовая, автоматическая — и три робота, которые закрывают сценарии, недоступные штатным средствам. А в конце — обратный вопрос: как запретить менять ответственного, если отдельного права на это в Битрикс24 нет.
Ответственный или исполнитель: кто есть кто
В CRM у лида, сделки, контакта и компании ответственный один — это поле «Ответственный» в карточке. В задачах ролей больше: постановщик, исполнитель, соисполнители и наблюдатели. «Ответственным» в задачах называется именно исполнитель — тот, кто делает работу и по кому горят счётчики; постановщик лишь принимает результат. Если процесс должен «сменить ответственного за задачу», значит меняется исполнитель. Подробнее о ролях и полях задач — в статье о роботах в задачах.
Как поменять ответственного вручную
В карточке: поле «Ответственный» → выбрать сотрудника. В списке: отметить галочками нужные записи → групповое действие «Изменить ответственного» — так передаются десятки записей за раз; фильтр «Ответственный = Иванов» плюс «выбрать все» покрывает и сотни. Два подводных камня. Первый — права: ответственного меняет любой, у кого в роли CRM есть право «Изменение» на эту запись; отдельного права на смену ответственного нет — как всё-таки запретить, разобрано ниже. Второй — при передаче записи прежний владелец может потерять её из виду: права «читать только свои» отрежут доступ в момент смены, поэтому передачу клиентской базы планируют вместе с настройкой ролей.
Автоматическая смена: штатный робот и условия
В дизайнере роботов есть штатное действие «Изменить ответственного» — оно ставит конкретного сотрудника или значение из поля. В связке с условиями «если — то» получается маршрутизация: сумма сделки выше порога — ответственным становится старший менеджер; источник «партнёрка» — записи уходят менеджеру по партнёрам. Слабое место штатного действия — оно знает только то, что жёстко указано в настройке: конкретного человека или поле. Кто «свободный», кто «из нужного отдела», кто «руководитель текущего ответственного» — этого дизайнер сам не умеет, и здесь начинаются роботы Роботеки.
Распределение лидов и сделок по менеджерам
Классика: входящие лиды должны распределяться по отделу продаж равномерно, а не падать на одного дежурного. Робот «Случайный сотрудник из списка/отдела» выбирает случайного активного сотрудника указанного отдела — или из явного списка ID — и умеет исключать одного человека, например текущего ответственного. Возвращает ID, имя, email и признак «найден» (Y/N); следующим шагом штатное действие записывает ID в поле «Ответственный». Случайный выбор на дистанции даёт равномерную загрузку без таблиц учёта очереди. Если распределение должно зависеть от подразделения автора или территории — сначала робот «Получить отдел сотрудника» определяет отдел, затем условие ветвит маршрут. Полный конвейер обработки входящих — в статье о лидах.
Увольнение менеджера: передать всё связанное
Самый болезненный сценарий. Групповое действие в списке передаст сделки — но не тронет связанные записи: у компании останутся контакты со старым ответственным, у контактов — их сделки. Робот «Сменить ответственного у связанных» решает именно это: запущенный на компании, он переназначает все её сделки или все контакты; на контакте — его сделки или компании; на сделке — её контакты или компанию. За один запуск обрабатывается до 500 связанных записей, робот возвращает количество обновлённых и признак успеха. Процесс передачи базы собирается в пару шагов: сменить ответственного у компании штатным действием → роботом протянуть нового ответственного на все сделки и контакты этой компании. Тот же приём работает при передаче ключевого клиента новому аккаунт-менеджеру — без увольнений.
Эскалация: не менять, а подключить руководителя
Иногда смена ответственного — ошибка: за просроченную задачу должен отвечать тот же менеджер, но узнать о просрочке обязан его руководитель. Робот «Получить руководителя сотрудника» возвращает прямого руководителя по структуре отделов — процессу остаётся поставить ему задачу или отправить уведомление. Ответственный не меняется, но появляется контроль. Чтобы эскалация работала, структура компании должна быть заполнена честно — как её настроить, разобрано в статье о структуре компании.
Можно ли запретить менять ответственного?
Штатно — только вместе со всем остальным. В ролях CRM нет отдельного права «смена ответственного»: поле «Ответственный» правит каждый, у кого есть право «Изменение» на запись. Отнять его — значит запретить менеджеру редактировать карточку целиком: телефон, сумму, комментарии. Что на самом деле даёт ролевая модель:
- Права на стадии. Для лидов, сделок и смарт-процессов права настраиваются отдельно для каждой стадии: на финальных стадиях и на «Согласовании» правку можно закрыть. Вместе с ответственным закроются и остальные поля — обычно на этих стадиях это и нужно.
- Уровень «Свои». Это не запрет, а тормоз: отдав сделку коллеге, менеджер тут же теряет к ней доступ, а забрать себе чужую не может — он её просто не видит. Подробнее о том, как уровни доступа зависят от ответственного, — в статье о правах доступа и роботах.
- Задачи. Здесь нужное право есть: в ролях задач отдельно включаются «Смена исполнителя» и «Делегирование задачи». Но роли в задачах настраиваются только на тарифах «Профессиональный» и «Энтерпрайз», а руководитель делегирует задачи подчинённым всегда, независимо от настроек.
Ролевая модель CRM тоже есть не на всех тарифах. Если право «Изменение» отнимать нельзя, а контроль нужен, запрет собирают процессом: смену не блокируют, а откатывают.
Как автоматически вернуть прежнего ответственного?
Понадобится пользовательское поле-эталон — например, «Закреплённый ответственный» с типом «Привязка к сотруднику» — и бизнес-процесс с автозапуском «при изменении». Схема такая:
- При создании сделки процесс записывает текущего ответственного в поле-эталон.
- При каждом изменении сделки запускается проверка. Робот «Получить руководителя сотрудника» по ID из эталона находит руководителя прежнего ответственного.
- «Сложное условие» одним шагом проверяет три вещи: ответственный не равен эталону, «Кто изменил» не равен этому руководителю и не равен администратору CRM. Логика AND, на выходе Y или N.
- Y — смена без разрешения: штатное действие «Изменить ответственного» ставит значение из эталона, а руководитель получает уведомление, кто пытался передать сделку.
- Ответственный отличается от эталона, но условие вернуло N — сделку передал руководитель или администратор. Процесс записывает нового ответственного в эталон, и с этого момента закреплён уже он.
Откат сам снова запускает процесс «при изменении», но ответственный к этому моменту совпадает с эталоном, и проверка завершается без действий — зацикливания нет. Одно правило: процессы, которые назначают ответственного законно, — распределение лидов, передача базы при увольнении — должны записывать нового ответственного и в эталон, иначе проверка откатит и их. Как запускать автоматизацию при правке поля, разобрано в статье об изменении поля, а что ещё переназначить при уходе сотрудника — в чек-листе увольнения.
Частые вопросы
Можно ли запретить менеджерам менять ответственного? Отдельного права в ролях CRM нет: либо закрыть право «Изменение» целиком или на отдельных стадиях, либо откатывать смену процессом, как описано выше. Меняется ли постановщик задачи? Штатно нет — пересоздайте задачу процессом или измените исполнителя. Уведомляется ли новый ответственный? Да, стандартным уведомлением; дополнительное с контекстом можно отправить из процесса — как настроить, в статье об уведомлениях из бизнес-процессов. Что будет с активными процессами при смене ответственного? Они продолжают идти; если маршрут зависит от ответственного, перечитайте поле в момент использования, а не в начале процесса.
Итог
Ручная смена закрывает единичные случаи, групповые действия — разовые передачи, роботы — поток: равномерное распределение новых обращений, передача связанной базы при увольнении, эскалация по структуре и откат смены, которую никто не разрешал. Роботы «Случайный сотрудник», «Сменить ответственного у связанных», «Получить руководителя», «Получить отдел сотрудника» и «Сложное условие» — в каталоге Роботеки, ставятся из Маркета бесплатно. Нет нужного сценария — опишите задачу, сделаем робота.