Бизнес-процессы Битрикс24 для обработки заказов

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

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

Зачем автоматизировать обработку заказов процессами

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

Первая — потеря шагов. Человек забывает согласовать скидку, не ставит резерв, пропускает уведомление клиенту. Каждый пропуск — это либо недовольный покупатель, либо финансовый риск. Вторая — непрозрачность. Руководитель не видит, на каком этапе застрял заказ и кто виноват в задержке. Третья — зависимость от людей. Ушёл ключевой менеджер в отпуск — и его заказы «повисли», потому что регламент жил только у него в памяти.

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

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

Что такое бизнес-процесс в Битрикс24

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

Процессы в Битрикс24 бывают двух видов, и их важно не путать:

• Процессы в списках (универсальные). Классический механизм, унаследованный от платформы 1С-Битрикс: процесс привязан к элементу универсального списка или инфоблока. Подходит для документооборота — заявки, служебные записки, согласования договоров.
• Процессы в CRM. Привязаны к CRM-сущностям: лидам, сделкам, контактам, компаниям и смарт-процессам. Именно они нужны для обработки заказов, потому что заказ в CRM — это сделка или элемент смарт-процесса.

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

Дизайнер процессов доступен на старших тарифах облачного Битрикс24 и в коробочной версии. В коробке возможностей больше: свои действия на PHP, глубокая интеграция с 1С-Битрикс, размещение на собственных серверах. Но базовый набор действий, которого хватает для большинства сценариев обработки заказов, одинаков в обеих версиях.

Бизнес-процессы против роботов и триггеров

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

Триггер ловит внешнее событие (пришло письмо, оплатили счёт, заполнили форму) и переводит сделку на нужную стадию. Робот привязан к стадии воронки и выполняет одно действие, когда сделка на этой стадии оказывается: отправить письмо, поставить задачу, изменить поле. Бизнес-процесс — это полноценный алгоритм с памятью состояния, который живёт поверх сделки и может содержать десятки шагов, условий и ожиданий.

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

Анатомия процесса обработки заказа

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

1. Старт и первичная проверка. Процесс запускается по новому заказу, читает его поля: сумму, тип оплаты, клиента, состав. На этом шаге отсекаются заведомо некорректные заказы (пустой состав, отсутствует контакт) и выставляются служебные метки.
2. Ветка условий. Ключевое решение: нужно ли согласование. Обычно условие по сумме заказа или по типу клиента (новый / оптовый / с просрочкой по дебиторке).
3. Согласование. Если условие сработало, процесс ставит задачу-утверждение руководителю и ждёт «Согласовано» или «Отклонено». По результату идёт дальше или возвращает заказ на доработку.
4. Постановка задач. После согласования процесс раздаёт задачи отделам: складу — резерв и сборка, бухгалтерии — счёт и контроль оплаты, логистике — доставка. Часто параллельно.
5. Уведомления. На важных переходах процесс шлёт оповещения: клиенту — что заказ принят и когда ждать, менеджеру — что согласование получено, руководителю — что заказ завис.
6. Завершение. Когда все задачи закрыты и заказ доставлен, процесс переводит сделку в финальную стадию, фиксирует итог и при необходимости запускает пост-продажные шаги (запрос отзыва, повторная продажа).

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

Ключевые действия дизайнера процессов

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

Отдельно стоит выделить действия работы с переменными и вычислениями. Процесс умеет хранить свои переменные (например, «требуется ли согласование», «число попыток дозвона»), считать выражения и подставлять значения полей заказа в тексты писем и задач. Именно вычисляемые условия делают процесс гибким: одна и та же схема по-разному ведёт заказ на 5 000 и на 500 000 рублей.

Согласования: как встроить утверждение заказа

Согласование — сердце процессов обработки заказов в среднем и B2B-сегменте. Скидка сверх лимита, отгрузка в долг, нестандартные условия, крупная сумма — всё это должен подтвердить человек с полномочиями. Задача процесса — сделать так, чтобы согласование было быстрым, зафиксированным и не тормозило мелкие заказы.

Механика простая. Перед блоком согласования ставится условие: например, «сумма заказа больше 100 000 рублей» или «запрошенная скидка больше 10 %». Если условие ложно — процесс пропускает согласование и идёт дальше автоматически. Если истинно — включается действие «Утверждение»: согласующему приходит задача с деталями заказа и двумя кнопками. Процесс замирает и ждёт решения.

Дальше возможны три исхода, и каждый стоит предусмотреть:

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

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

Задачи ответственным и распределение работы

После того как заказ прошёл проверку и согласование, начинается исполнение — и здесь процесс раздаёт задачи. Задача в Битрикс24 — это не просто напоминание, а полноценная единица работы со сроком, ответственным, чек-листом и связью с заказом. Процесс ставит их автоматически, подставляя данные заказа в название и описание.

Типовое распределение по отделам для интернет-магазина выглядит так:

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

Второй приём — умное назначение ответственного. Не жёстко «задача на Иванова», а «на ответственного за склад», «на руководителя отдела продаж автора сделки», «на дежурного оператора». Процесс умеет вычислять исполнителя по структуре компании и полям заказа. Тогда при кадровых изменениях не нужно переделывать схему — меняется только назначение роли в оргструктуре.

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

Уведомления: кого, когда и куда оповещать

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

Разделите адресатов и поводы:

• Клиенту — только ключевые вехи: заказ принят, согласован/подтверждён, передан в доставку, доставлен. Канал — e-mail и (при интеграции) SMS или мессенджер. Тон — человеческий, с номером заказа и ожидаемым сроком.
• Менеджеру заказа — события, требующие его реакции: согласование получено или отклонено, клиент не отвечает, оплата просрочена. Канал — уведомления внутри Битрикс24.
• Руководителю — исключения, а не рутина: заказ завис на согласовании дольше нормы, крупная сделка отменена, сорван SLA. Это сигналы, что нужно вмешаться.
• Отделу — постановка и просрочка задач по их зоне ответственности. Обычно достаточно штатных уведомлений о задачах, отдельные сообщения нужны для нестандартных ситуаций.

Технически уведомления шлются двумя действиями: «Уведомление» (сообщение в мессенджер и центр уведомлений Битрикс24 — для сотрудников) и «Отправка почтового сообщения» (e-mail по шаблону — чаще для клиента). В тексты подставляются поля заказа: номер, сумма, состав, ссылка на карточку. Хорошая практика — держать тексты писем клиенту в отдельных почтовых шаблонах, чтобы маркетолог мог править формулировки без правки самого процесса.

Отдельно про уведомления клиенту о смене статуса заказа. Если заказы приходят из интернет-магазина на 1С-Битрикс, статусы часто ведутся там, и логичнее выстраивать клиентские оповещения вокруг воронки выполнения заказа. Как связать статусы магазина с наглядной воронкой и уведомлениями, мы разбираем в материале про статусы заказа и воронку выполнения в Битрикс.

Реализация в Битрикс24: настройка пошагово

Перейдём от теории к настройке. Ниже — последовательность создания бизнес-процесса обработки заказа над сделкой CRM. Порядок и названия пунктов зависят от версии портала, но логика неизменна.

1. Подготовьте воронку и поля. Убедитесь, что в сделках заведены нужные поля: сумма, тип оплаты, категория клиента, а стадии воронки отражают реальные этапы заказа. Процесс будет опираться на эти данные.
2. Откройте роботы и бизнес-процессы. В настройках воронки CRM найдите раздел автоматизации. Для сложной логики выберите создание бизнес-процесса (дизайнер), а не робота.
3. Задайте параметры запуска. Укажите, когда процесс стартует: при добавлении сделки (новый заказ), при изменении, вручную. Для заказов обычно автозапуск по добавлению.
4. Соберите ветку проверки. Добавьте действие «Условие» и настройте проверку суммы или категории клиента, чтобы отделить заказы, требующие согласования.
5. Вставьте блок «Утверждение». В ветке «требуется согласование» добавьте действие утверждения, выберите согласующего (конкретного или по роли), задайте текст задачи и срок.
6. Разведите задачи по отделам. Действием «параллельное выполнение» запустите задачи складу, бухгалтерии, менеджеру. В каждой подставьте поля заказа в название и описание, назначьте ответственного по роли.
7. Настройте уведомления. Добавьте действия уведомления и отправки письма на ключевых переходах: заказ принят, согласован, передан в доставку.
8. Добавьте эскалации. Для блоков ожидания задайте таймеры: если нет ответа за N часов — напоминание или передача. Это защита от зависаний.
9. Финализируйте. В конце процесса действием «изменение документа» переведите сделку в финальную стадию и зафиксируйте итог.
10. Протестируйте на боевых сценариях. Прогоните тестовый заказ по каждой ветке: мелкий (без согласования), крупный (с согласованием), отклонённый, зависший. Проверьте журнал процесса.

Как это выглядит в дизайнере процессов

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

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

Связка с заказами 1С-Битрикс

Если заказы оформляются в интернет-магазине на платформе 1С-Битрикс, важно понимать, что магазин и Битрикс24 — разные продукты, и процесс работает уже над данными в CRM. Заказ должен сначала попасть в CRM в виде сделки, и только потом к нему применяется бизнес-процесс. Каналов передачи два.

• Штатная интеграция «Интернет-магазин + CRM». В коробочном 1С-Битрикс есть модуль, который зеркалит заказы магазина в CRM Битрикс24: новый заказ создаёт сделку с составом, суммой и клиентом. Обмен идёт по расписанию или по событию.
• Обмен по API. Когда нужна нестандартная логика (свои поля, фильтрация, обогащение данными), заказы передают через REST API Битрикс24: магазин по событию оформления заказа создаёт или обновляет сделку и подкладывает нужные поля.

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

Тему обмена и настройки интеграции Битрикс24 с сайтом мы подробно разбираем в отдельной статье про интеграцию с Битрикс24 — там про механику связки, поля и типичные проблемы обмена. За полноценным внедрением интеграции магазина и CRM обращайтесь к нашей услуге по интеграциям.

Таймеры, эскалации и SLA

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

Механик несколько, и они комбинируются:

• Ограничение времени на действие. У блоков утверждения и заданий задаётся срок. По его истечении процесс идёт по ветке «просрочено», а не висит.
• Напоминания по таймеру. Параллельная ветка с паузой шлёт напоминание, если основная задача не закрыта за N часов. Можно наращивать давление: сначала мягко исполнителю, потом его руководителю.
• Передача ответственного (эскалация). Если за срок ответа нет, процесс переназначает задачу заместителю или дежурному, чтобы заказ двигался дальше.
• Автоматическое решение по правилу. В некоторых сценариях допустимо правило «если руководитель не отклонил за 4 часа — считать согласованным». Применять осторожно и только там, где риск оправдан.

За этим стоит понятие SLA (Service Level Agreement — соглашение об уровне сервиса) — заданные нормативы времени на каждый этап. Формализуйте их: сколько допустимо на согласование, на сборку, на звонок клиенту. Процесс с эскалациями сам следит за соблюдением SLA и поднимает тревогу при нарушении. Это переводит контроль сроков из режима «руководитель вручную проверяет» в режим «система сама сигналит об отклонениях».

Метрики и контроль процесса

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

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

Не гонитесь за идеальным процессом с первого раза. Здоровая практика — запустить рабочую версию, месяц понаблюдать за метриками и журналами, найти узкие места (медленное согласование, лишние уведомления, зависания на конкретной ветке) и точечно доработать. Автоматизация обработки заказов — это итеративная настройка, а не разовый проект.

Частые ошибки при автоматизации

• Строят один гигантский процесс на весь регламент — его невозможно отлаживать и поддерживать. Разбивайте на несколько связанных.
• Забывают ветку «согласование не требуется» — и менеджеры ждут руководителя даже по мелким заказам, автоматизация тормозит работу вместо ускорения.
• Не ставят таймеры и эскалации — процесс зависает навсегда, если ответственный в отпуске или пропустил задачу.
• Заваливают сотрудников уведомлениями — важное тонет в шуме, оповещения перестают читать.
• Жёстко назначают конкретных людей вместо ролей — при кадровых изменениях приходится переделывать схему.
• Запускают процесс на каждое изменение сделки при активном обмене с магазином — процессы стартуют лавинообразно.
• Не согласуют статусы CRM и интернет-магазина — клиент видит в кабинете один статус, а внутри заказ на другом этапе.
• Внедряют автоматизацию без описанного регламента — переносят в схему хаос, и на выходе получают автоматизированный хаос.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность автоматизации перед запуском.

1. Регламент описан. На бумаге зафиксированы шаги, роли, условия согласований и сроки — до того, как открыт дизайнер.
2. Поля и воронка готовы. В сделках есть сумма, тип оплаты, категория клиента; стадии отражают реальные этапы заказа.
3. Процесс разбит на модули. Крупный сценарий разложен на управляемые процессы: согласование, исполнение, постпродажа.
4. Ветка без согласования есть. Мелкие заказы проходят автоматически, ручной шаг включается только по условию.
5. Ответственные назначены по ролям. Задачи идут на роли и позиции оргструктуры, а не на конкретных людей.
6. Таймеры и эскалации настроены. У всех шагов ожидания есть сроки, напоминания и передача при просрочке.
7. Уведомления откалиброваны. Клиенту — вехи, менеджеру — реакция, руководителю — исключения; без шума.
8. Связка с магазином согласована. Определён источник правды по статусам, обмен с 1С-Битрикс не порождает лавину запусков.
9. Протестированы все ветки. Прогнаны заказы: мелкий, крупный, отклонённый, зависший; журнал проверен.
10. Метрики на контроле. Настроен просмотр времени прохождения, согласований и просрочек для последующей доводки.

Вывод

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