Смарт-процессы в Битрикс24: как выбрать структуру и подготовить автоматизацию

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

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

Возможности сверены с официальной справкой Битрикс24 2 октября 2026 года. Доступность смарт-процессов, универсальных списков, роботов, бизнес-процессов и отдельных настроек зависит от тарифа и версии продукта. Перед реализацией проверьте их на своём портале и на странице тарифов Битрикс24.

Сделка, список или смарт-процесс: выбираем единицу учёта

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

Смарт-процесс позволяет создать собственный тип элемента с полями, стадиями, связями и правами. Он полезен, когда у объекта есть самостоятельная жизнь, которая не укладывается в воронку продаж. Возможности создания и настройки описаны в официальном обзоре смарт-процессов.

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

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

Та же логика работает в других отделах. Заявка на закупку с бюджетом, согласованием и поставкой — самостоятельный процесс; справочник поставщиков — реестр. Платное сервисное обслуживание продаётся через сделку, а обращения в рамках этого обслуживания удобно учитывать отдельно. Иначе десять заявок клиента легко превратятся в десять фиктивных продаж.

Договор как отдельный объект: что и с чем связываем

В учебном примере создаём модель «Согласование договоров». Одна карточка хранит один договор; новая редакция файла остаётся в той же карточке с новым номером версии. Дополнительное соглашение учитываем отдельной карточкой, связанной с основным договором. Это выбранное правило учёта: его нужно согласовать до переноса данных.

• Компания и контакт — контрагент и человек для связи. Не копируем их телефон и название в произвольные текстовые поля без необходимости.
• Сделка — продажа, ради которой готовится договор. В нашем примере у одного договора одна основная сделка, у сделки может быть несколько договоров.
• Задача или задание согласования — конкретная проверка определённой версии. Это поручение внутри процесса, а не второй договор.
• Исходный идентификатор — ключ документа из внешней системы, если карточки поступают через интеграцию. Название договора не годится для поиска дублей.

В настройках смарт-процесса Битрикс24 есть связи с элементами CRM и привязки к другим инструментам. Направление связи определяет, где сотрудник увидит связанную карточку; настройте и проверьте переход в обе стороны. Не считайте, что само наличие связи переносит сумму, ответственного или результат согласования. Справка по созданию смарт-процесса.

Если один рамочный договор обслуживает много сделок, заранее измените модель связей и правила отчёта. Копировать договор для каждой сделки только ради удобства фильтрации — значит размножить версии и потерять единую историю. А если исходный реестр находится в Excel, сначала определите ключ обновления и очистите дубли: этому посвящена инструкция по импорту в Битрикс24.

Стадии описывают состояние работы, а не перечень действий робота

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

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

Учебный маршрут: подготовка → согласование → готов к подписанию → подписан.
При замечаниях: согласование → доработка → согласование новой версии.
При отказе: переход в «Отменён» с причиной и прекращением лишних напоминаний.

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

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

Поля и обязательные данные: что нужно именно на этом шаге

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

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

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

Битрикс24 позволяет делать поля обязательными для определённых стадий, в том числе в смарт-процессах. Возможность зависит от тарифа; обязательность для сделок и смарт-процессов настраивается отдельно по воронкам. Проверяйте её там, где реально работает команда. Как настроить обязательные поля.

Заполненное поле ещё не означает корректные данные. Файл может оказаться старым, согласующий — не тем сотрудником, а срок — уже прошедшим. Кроме того, проверка заполнения в карточке и условие запуска робота решают разные задачи. Для ручного переноса, импорта, интеграции и автоматического изменения отдельно определите, где проверяются данные. Условие «не запускать робота» само по себе не доказывает, что неверный переход запрещён.

Ответственные и доступ: кто ведёт карточку, кто принимает решение

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

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

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

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

Только теперь проектируем роботов

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

Пример для стадии «На согласовании»:

1. Событие: договор направлен на согласование версии 3.
2. Условия: есть актуальный файл, согласующий и срок; версия 3 ещё не согласована; для неё нет действующего поручения.
3. Действие: создать одно поручение проверить версию 3 и передать ссылку на нужный документ.
4. Подтверждение: сохранить идентификатор созданного поручения и номер версии. Ошибку создания не выдавать за успешную отправку.
5. Исключение: если данных или доступа не хватает, сообщить владельцу процесса, что именно нужно исправить. Не отправлять документ произвольному запасному сотруднику.

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

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

Битрикс24 позволяет задавать очередь, время и условия робота. Если действие зависит от результата предыдущего шага, нельзя рассчитывать на визуальный порядок блоков при независимом запуске. При этом завершение робота, который создал задачу, не равно завершению самой задачи. Для ожидания решения нужен подходящий механизм. Условия и очередность роботов.

Возвраты, повторные запуски и защита от зацикливания

Рассмотрим два возврата. В первом сотрудник случайно переместил версию 3 назад и снова вперёд: новую задачу создавать не нужно. Во втором юрист запросил изменения, инициатор подготовил версию 4 и осознанно отправил её на проверку: новое поручение требуется. Простой флажок «задача создана» не различает эти ситуации.

Нужен ключ действия, например «тип процесса + ID договора + версия + шаг согласования». Перед повтором проверяют не только отметку в карточке, но и фактический результат: существует ли нужное поручение, к какой версии оно относится, закрыто ли оно. После сбоя сначала сверяют состояние, затем повторяют только отсутствующее действие.

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

Типовая петля выглядит так: робот меняет поле → бизнес-процесс запускается на изменение → возвращает стадию → робот снова меняет поле. Уберите лишнюю точку запуска, проверяйте, действительно ли значение изменилось, и задайте ограничение повторов с передачей исключения человеку. Исправление ошибки не должно само без конца порождать ту же ошибку.

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

Уведомления и сроки: одно сообщение должно вести к одному действию

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

Инициатору нужен результат с замечаниями, юристу — поручение с версией и сроком, руководителю — исключение при просрочке. Всем троим не требуется сообщение о каждом изменённом поле. В уведомлении указывайте объект, требуемое действие, срок и ссылку; конфиденциальный текст договора не копируйте в общий чат.

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

Плановое время робота и фактическое время выполнения могут различаться. В справке Битрикс24 отмечены задержки при большом количестве запущенных роботов и бизнес-процессов. Поэтому не обещайте исполнение «ровно в секунду» и проверяйте работу с часовыми поясами и календарём. Настройка времени в роботах.

Будущую отчётность закладываем в структуру сейчас

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

• Остаток на согласовании — договоры, которые находятся на этой стадии в выбранный момент.
• Срок проверки версии — время от её отправки до решения; отдельно определите рабочее или календарное время.
• Доля возвратов — доля завершённых проверок версий с результатом «на доработку». Не смешивайте её с долей договоров, у которых был хотя бы один возврат.
• Полный срок договора — время от начала подготовки до выбранного финального события, с отменёнными договорами в отдельной группе.

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

В BI Конструкторе предусмотрены наборы данных по смарт-процессам, их истории стадий и связям. Перед проектированием отчёта проверьте фактические поля, доступность и глубину нужных данных: это не обещание, что любой коннектор автоматически выгрузит все события. Наборы данных смарт-процессов. Выбор способа получения данных разобран в статье о выгрузке из Битрикс24, а различие просрочек и выполненной работы — в материале о контроле задач и CRM.

Чек-лист готовности к автоматизации

До настройки роботов на каждый пункт должен существовать конкретный ответ или документированное правило.

• Определено, что означает одна карточка и почему выбран именно этот тип сущности.
• Проверена доступность нужных инструментов на тарифе и в версии портала.
• Описаны связи, источник каждого важного поля и ключ поиска дублей.
• У каждой стадии есть владелец, условия входа и выхода; согласование и финальный результат различаются.
• Обязательные данные и проверки заданы по этапам и каналам поступления карточек.
• Роли, заместители, доступ к связанным объектам и файлам проверены без прав администратора.
• Для каждого действия определены точка запуска, результат и обработка ошибки.
• Различаются случайный повтор, новая версия и намеренный повторный запуск.
• Описана защита от дублей и петель, включая одновременные запуски и частичный сбой.
• Согласованы календарь, получатели уведомлений и прекращение действий при отмене.
• Есть данные для будущих показателей и способ сверить их на нескольких карточках.
• Назначен владелец приёмки, записаны учебные сценарии и порядок остановки автоматизации.

Учебные сценарии: как принять результат настройки

Ниже — задания для отдельной тестовой среды или изолированного учебного процесса с согласованным доступом. Используйте вымышленные карточки и тестовых получателей; реальные письма, сообщения клиентам и интеграционные действия должны быть отключены или заменены. Название «ТЕСТ» само по себе не делает сценарий безопасным. В рамках этой статьи сценарии в живой CRM не запускались.

1. Полный маршрут. Учебный договор «Д-001», версия 1, заполненные данные. Ожидаем одно поручение, правильного согласующего и срок. После положительного решения — «Готов к подписанию», а не «Подписан».
2. Не хватает данных. Уберите файл или согласующего. Проверьте ручной переход и каждый предусмотренный автоматический канал. Ожидаем понятную причину остановки и отсутствие ошибочного поручения; сам факт молчания робота проверкой не считается.
3. Неверные полномочия. Инициатор пытается подтвердить согласование; посторонний сотрудник открывает карточку и файл. Ожидаем соблюдение утверждённых ограничений. Отдельно проверяем, что юрист действительно может прочитать документ.
4. Случайный повтор. Версию 1 повторно направляют на ту же стадию. Ожидаем одно действующее поручение и отсутствие повторного уведомления.
5. Возврат и новая версия. Юрист возвращает версию 1 с замечаниями; инициатор отправляет версию 2. Ожидаем новое поручение именно для версии 2. Поздний ответ по версии 1 не должен согласовать версию 2.
6. Частичный сбой и конкуренция. Смоделируйте создание поручения без записи результата, затем повтор; отдельно — два одновременных запуска. Ожидаем восстановление связи с существующим поручением либо управляемую остановку. Два поручения на один ключ — непройденная проверка.
7. Отмена и просрочка. Отмените учебный договор до времени напоминания. Ожидаем отсутствие лишнего сообщения. Для другого договора проверьте просрочку и одну эскалацию по принятому правилу, включая выходной день.
8. Замена исполнителя и отчёт. Передайте открытое поручение заместителю. Сверьте фактического исполнителя, адресата напоминания и показатели на наборе из подписанного, отменённого и возвращённого договоров.

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

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