Антон Дегтярёвкастомизация битрикс24: что можно без разработчика, а что — только с ним
На аудите регулярно слышу два противоположных запроса: «мы наняли программиста для того, что можно было настроить за час» и «полгода мучаемся руками с тем, что без разработчика в принципе не сделать». Оба стоят компании денег. Провожу границу — что реально закрывается конструктором Битрикс24, а где без строчки кода не обойтись.
почему слово «доработка» путает всех
Под «доработкой Битрикс24» клиенты понимают три разных по сложности вещи: настройку в интерфейсе (поля, автоматизация, шаблоны), написание формул и условий поверх стандартных инструментов (уже погранзона) и полноценную разработку — виджет, интеграцию, изменение кода. Смешение этих уровней — причина, почему в одном случае платят программисту за час работы мышкой, а в другом ждут от штатного менеджера то, что физически возможно только через API.
Ниже — граница по трём уровням, с примерами из реальных аудитов за последний год.
уровень 1 — делается в конструкторе без единой строчки кода
Пользовательские поля сделки, лида, контакта — текст, список, дата, привязка к сотруднику. Стадии воронки под свой процесс. Роботы на переходах между стадиями — назначить ответственного, отправить уведомление, поставить задачу, изменить поле по условию. CRM-формы для приёма заявок с сайта напрямую в нужную воронку. Шаблоны документов — договор, счёт, коммерческое предложение — с автоподстановкой полей из карточки сделки.
Про то, как это собирается в цепочки с ветвлениями и согласованиями, я подробно разбирал в статье про бизнес-процессы в Битрикс24, а если поток однотипных объектов не привязан к продаже — смотрите материал про смарт-процессы. Это весь уровень 1: закрывает 70–80% типичных запросов на аудите без единого разработчика.
уровень 2 — no-code, но требует аккуратной настройки
Вычисляемые поля с формулами (расчёт скидки по объёму заказа, автоматический расчёт срока по типу услуги) технически не код, но ошибка в формуле ломает логику на десятках сделок сразу — тестировать нужно на копии портала, а не на боевых данных. Условные роботы с ветвлением по нескольким полям одновременно — тоже граница: конструктор позволяет, но собрать 5–6 условий без путаницы получается не с первого раза.
Отдельно — Битрикс24 «Вайбкод», платформа для сборки приложений через постановку задачи нейросети без написания кода вручную. Я разбирал её отдельно — где вайбкодинг реально работает, а где ломается. Коротко: закрывает простые внутренние инструменты, но для интеграций с внешними системами и сложной валидации данных сгенерированный код всё равно нужно дособирать интегратору.
уровень 3 — здесь без разработчика не обойтись
Интеграция с внешней системой через REST API — 1С, сайт на нестандартной платформе, складская программа. Кастомный виджет в карточке CRM — например, калькулятор стоимости с логикой, которая не укладывается в формулу поля. Обработчики событий на входящий вебхук — когда нужно не просто уведомление, а автоматическое действие с расчётами во внешнем сервисе. Массовая миграция данных с нестандартной схемой полей из старой CRM.
Полный список возможностей REST API и что реально на нём строят — в отдельном разборе REST API Битрикс24: что можно сделать без коробки. Если задача требует пункт из этого уровня — экономия на разработчике почти всегда оборачивается кустарным решением, которое ломается при следующем обновлении портала.
коробка vs облако — по-разному сдвигает границу
В облачном Битрикс24 доступа к ядру нет в принципе — любая доработка идёт через официальный REST API и виджеты, прямое изменение кода системы невозможно физически, даже если нанять сильного разработчика. В Коробке доступ к исходному коду открыт, поэтому туда же можно добавить произвольную логику на уровне базы данных — но это одновременно риск: доработка ядра усложняет обновления, и через год-два версию системы приходится обновлять руками вместе с доработками.
Практический вывод: если планируете глубокую кастомизацию на годы вперёд — смотрите Коробку с самого начала. Если типовой бизнес с несколькими нестандартными процессами — почти всегда хватает облака с REST API интеграциями, без рисков доработки ядра.
как я оцениваю на аудите, нужен ли разработчик
Три вопроса, которые задаю в первую очередь. Первый — есть ли в задаче внешняя система, с которой нужен обмен данными в реальном времени? Если да — почти всегда нужен REST API и, значит, разработчик. Второй — нужен ли интерфейс, которого нет в стандартной CRM (отдельная страница, кастомный виджет, специфичная визуализация)? Если да — виджет, разработчик. Третий — задача решается через поле, робота или CRM-форму хоть с натяжкой? Если да — делаю сам или показываю, как настроить, без привлечения программиста.
Если у задачи «и то, и то» — например, нужен виджет с расчётом, который тянет данные из внешнего склада — считаю по частям: сама интеграция со складом это разработчик, а карточка с полями для отображения результата — уже уровень 1.
ошибка: наняли разработчика для того, что настраивается за час
Клиент из логистической компании потратил 40 000 рублей на фрилансера за «интеграцию с формой расчёта стоимости на сайте» — задача оказалась настройкой обычной CRM-формы с вычисляемым полем по тоннажу и километражу, без единой строчки кода. Проблема была не в сложности задачи, а в формулировке ТЗ: «нужна автоматизация» звучит как разработка, хотя по факту это конструктор.
Правило простое: прежде чем звать разработчика, проверяю задачу на уровень 1 из этой статьи — часто выясняется, что решение уже встроено в интерфейс, просто не на виду.
ошибка: экономят на разработчике там, где он точно нужен
Обратный случай — компания два месяца пыталась собрать интеграцию склада через связку из трёх коробочных виджетов и ручной синхронизации Excel-выгрузками, лишь бы не платить за разработку. В итоге данные расходились каждую неделю, менеджеры теряли доверие к CRM, а сотрудник, который вёл эту синхронизацию вручную, тратил на неё по 4–5 часов в неделю — за два месяца это дороже, чем разовая оплата интеграции через API.
Если задача попадает в уровень 3 — интеграция с внешней системой в реальном времени — экономия на разработчике почти всегда стоит дороже самой разработки, просто растянуто по времени и незаметно на фоне зарплаты штатного сотрудника. Разобраться, какой тип доработки нужен именно вам, проще на консультации по приложениям и интеграциям, чем методом проб на боевом портале.
как проверить готовое решение, прежде чем платить за него
Перед оплатой любой доработки — и настройки конструктором, и разработки — прошу показать её не в презентации, а на копии реальных данных: 10–15 карточек сделок или объектов, максимально близких к боевым. Формула, которая красиво считает на трёх тестовых примерах, часто ломается на нестандартном случае — например, скидка не учитывает отрицательное значение или деление на ноль при пустом поле количества.
Для интеграций уровня 3 отдельно смотрю, что происходит при сбое внешней системы: если склад временно недоступен, должна быть понятная ошибка и повтор попытки, а не тихая потеря данных без уведомления. Разработчик, который сразу показывает обработку такого сценария, а не только счастливый путь без сбоев, обычно понимает архитектуру интеграции глубже, чем тот, кто предъявляет только работающую демонстрацию.
Ещё один момент, который стоит проверить до оплаты, — что произойдёт с доработкой при обновлении Битрикс24. Для конструкторных решений (поля, роботы, формы) риск минимален, они часть официального интерфейса. Для кастомного виджета или интеграции через API стоит спросить у разработчика, на чём построено решение — если на официальных методах REST API, доработка переживёт обновления; если на недокументированных обходных путях, риск поломки при следующем релизе платформы становится реальным, и об этом лучше знать заранее, а не после сбоя.