Заказчик - производственная компания: выпускает пигменты и лакокрасочные материалы (название по договорённости не публикуется). У компании два потока продаж и собственная лаборатория. Когда клиент заказывает новый продукт или типовой образец, заявка должна уходить в лабораторию, а после согласования с клиентом возвращаться в продажи.
До проекта всё это переносили руками: менеджер дублировал данные в лабораторию, лаборатория сообщала результат в чате, часть заявок терялась, сроки никто не контролировал.
Работа шла в два этапа на боевом портале. Первый этап: связать в CRM Битрикс24 две воронки продаж со смарт-процессом «Лаборатория», чтобы заявка шла по цепочке продажи => лаборатория => продажи автоматически, без ручного переноса и потерь.
Второй этап: у компании изменился сам процесс лаборатории. Появился типовой образец, который проходит лабораторию по короткому маршруту, без разработки рецептуры и расчёта себестоимости. Понадобились два маршрута в одной воронке, новый порядок этапов, формальная обратная связь от клиента с возвратом на доработку и историей кругов, запрет на чужие этапы и передача сделки дальше только после принятого результата.
Ограничения: сотрудники работают в портале днём, поэтому заметные им правки делались по вечерам и по согласованию. Тип продукта в сделках синхронизируется с 1С, коды его значений менять нельзя. Действующие автоматизации заказчика нужно было сохранить.
Работал на боевом портале (Битрикс24, коробочная версия), в два этапа.
Этап 1, связка воронок с лабораторией:
- Карточка в смарт-процессе «Лаборатория» создаётся сама, когда сделка переходит на стадию проработки. Типовые продукты идут мимо лаборатории.
- Клиента и поля заказа в карточку переносит PHP-блок в бизнес-процессе: штатная привязка элементов этого не делает.
- Защита от дублей: повторный заход сделки на стадию возвращает существующую карточку, а не создаёт вторую.
- Обратный перевод сделки из лаборатории в продажи. Смарт-процесс штатно не может двигать сделку, а исходящие вебхуки сервер портала не выпускал, поэтому сделку переводит PHP-блок.
- Блокировка сделки на время работы лаборатории правами роли, уведомления руководителям, обязательная «Сумма». Всё в двух воронках с разными кодами стадий.
Этап 2, два маршрута и обратная связь:
- Третий тип продукта «Типовой образец». Поле общее с 1С, поэтому значение заведено с кодом из 1С, а переименование сделано в классической форме поля: новая форма пересоздаёт коды, и обмен перестал бы узнавать тип.
- Два маршрута в одной воронке лаборатории. Новый продукт: сбор требований => разработка => расчёт себестоимости => тестирование => согласование с клиентом. Типовой образец: сбор требований => подготовка образца => тестирование => согласование.
- Карточка идёт сама: пять триггеров по завершению задачи и отметке экономиста. Триггер по статусу задачи штатно срабатывает на любую задачу карточки, даже прошлого круга, поэтому у триггеров условие на этап и тип, а старые задачи закрываются сами.
- Защита чужих этапов. Права ролей задаются на этап целиком, по типу карточки этап не закрыть. На этапах первым стоит PHP-блок: карточку чужого типа он тихо возвращает на прежний этап, без запуска роботов, и пишет тому, кто её перевёл.
- Окно результата: при переводе на согласование Битрикс требует результат тестирования и комментарий. Обязательность полей-списков выставлена скриптом, иначе окно настройки пересохраняет коды значений.
- Возврат на доработку: PHP-блок дописывает в «Историю обратной связи» дату, результат и комментарий, очищает поля и закрывает задачи прошлого круга.
- Сделка уходит на «Внутренний акцепт», только когда карточку завершают с принятым результатом. При переводе кодом роботы этапа не запускаются, поэтому запрос суммы руководителям отправляет сам блок.
- Задачу «Разработать рецептуру» нельзя завершить без файла рецептуры. Штатно Битрикс не запрещает завершение задачи по полю CRM: отказ даёт обработчик события задач. Новая карточка задач текст отказа не показывает, поэтому он дублируется уведомлением через фоновое задание: отправленное внутри отказа откатывалось вместе с запросом.
- Сделку нельзя увести с проработки дальше «Внутреннего акцепта»: второй обработчик, на изменение сделки. Работает на канбане, в карточке и через REST.
- Автоматизации заказчика, сломавшиеся после смены кодов в справочнике, общем с 1С, перепривязаны к новым кодам.
Проверка: 23 сквозных сценария на портале в обеих воронках на тестовых данных, код обработчиков сначала на макете Битрикса в Docker, 72 автоматические проверки. Для каждой доработки есть скрипт выключения.
Технологии: Битрикс24 коробочная версия, CRM, смарт-процессы, бизнес-процессы, роботы и триггеры, PHP в бизнес-процессах и обработчики событий, D7-фабрики CRM, REST API, права ролей, обмен с 1С, Docker.
Заявки на новые продукты и типовые образцы идут по цепочке продажи => лаборатория => продажи без ручного переноса. Лаборатория ведёт два маршрута в одной воронке, карточка сама идёт по своим этапам: задачи ставятся один раз, переходы срабатывают по завершению задачи и по отметке экономиста.
Обратная связь клиента записывается в карточке и сразу доходит до лаборанта, при доработке видна история всех кругов. Карточку нельзя увести на чужой этап, разработку нельзя закрыть без файла рецептуры, а сделку нельзя перевести дальше, пока лаборатория не закончила. Руководители получают запрос суммы по каждой сделке из лаборатории.
Объём второго этапа: 4 новых поля, 5 триггеров, 9 новых роботов и ещё 12 с переписанными условиями, 3 новых PHP-блока в бизнес-процессах, 2 обработчика событий, около 410 строк рабочего PHP, 23 служебных скрипта для диагностики, установки и отката. Срок второго этапа - около трёх недель, с 11 сентября по 2 октября 2026.
Заказчик получил инструкции по обоим этапам. По второму - PDF на 55 страниц: каждый шаг настройки и как его повторить или поправить, правила для менеджеров и лаборатории, 16 проверок, полный код блоков и обработчиков в приложениях.
Портал рабочий, закрытый, публичной ссылки нет: скриншоты сняты на боевой системе и обезличены.
