Проектирование пользовательских полей CRM Битрикс24 под ключ

Проектирование пользовательских полей Битрикс24: где ломается учёт

Карточка сделки живёт дольше, чем регламент, по которому её заводили. Сначала появляется поле «Комментарий для склада», потом «Комментарий для склада (новое)», потом кто-то добавляет срок поставки строкой — и в одной сущности уже три поля про одно и то же. Дубли в карточках сделок — не ошибка менеджера, а следствие того, что поля добавляли под сиюминутную задачу, не проектируя структуру заранее.

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

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

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

Что даёт единая схема атрибутов в карточках сделок

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

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

Целостность данных в отчётах держится на том, что все карточки описываются одними и теми же атрибутами. Сходимость выборок по воронкам, ответственным и периодам перестаёт зависеть от того, кто и как заполнил поле, — аналитика строится на едином источнике, а не на ручной сверке выгрузок.

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

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

Варианты реализации справочников: сравнение подходов

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

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

Порядок работ: от разбора карточек до регламента

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

1. Аудит карточек. Выгружаем структуру лидов, сделок, контактов и смарт-процессов: список полей, типы, дубли, пустые и устаревшие. Отдельно проверяем, что поле используется в отчётах, роботах, шаблонах писем и правилах распределения — скрытые зависимости находятся на этом шаге, а не после переноса.

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

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

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

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

6. Регламент работы. Передаём документ: какие поля менять можно, какие требуют согласования, кто отвечает за справочники, как откатывать неудачное изменение. Регламент закрывает вопрос, из-за которого структура карточек обычно и расползается.

Что передаём на руки: конфигурации, схемы, инструкции

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

Что входит в комплект

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

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

Кейс: как убрали ручной ввод в карточках отдела продаж

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

Что изменили

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

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

Метрики до и после

• Полей в карточке: 34 → 12, время заполнения сократилось почти втрое.
• Время обработки заявки: с 11 минут до 4.
• Доля ручных операций: с 58% до 19%.
• Заявки, возвращённые на доработку: с 21% до 5%.

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

Что делать, если в Битрикс24 уже созданы свои атрибуты?

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

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

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

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

Сверка закрывает переход. Если расхождений нет, старые атрибуты остаются только для аудита; если есть — дорабатываем правило приоритета и повторяем перенос по спорным записям. Схема обновляется без потери данных и без остановки отдела.

Частые технические сомнения перед стартом работ

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

Каждое разбираем до начала проектирования: поля создаются вместе с матрицей доступов, схемой обмена и проверкой отчётов на копии Битрикс24, а не после запуска.

Не появятся ли два поля с одинаковым смыслом?

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

Уйдёт ли новое поле в 1С и вернётся обратно?

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

Сломает ли поле существующие отчёты и воронку?

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

Не вырастет ли нагрузка на отдел?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Что снять с вашей стороны заранее:

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

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