Зачем вообще нужны пользовательские поля
Стандартный набор полей в Битрикс24 покрывает универсальные сценарии: имя, телефон, email, сумма сделки, источник. Но как только бизнес становится чуть специфичнее — строительный подряд, ювелирная розница, аренда коммерческой недвижимости — стандарта уже не хватает.
Пользовательские поля решают конкретные задачи:
- Хранят отраслевые данные — тип материала, площадь объекта, предпочтительный канал связи, тип чека.
- Управляют автоматизацией — роботы и бизнес-процессы срабатывают по значениям полей.
- Обеспечивают сегментацию — фильтры и отчёты строятся на значениях, которые менеджер выбирает из списка.
- Контролируют полноту данных — обязательные поля не дают закрыть сделку без нужной информации.
По нашему опыту, в типовом проекте внедрения настраивается от 20 до 100+ полей суммарно по всем объектам CRM — в зависимости от сложности бизнес-процессов.
flowchart LR
LID[Карточка лида\nдо 20 полей] --> KONTAKT[Карточка контакта\nдо 30 полей]
LID --> KOMPANIYA[Карточка компании\nдо 50 полей]
LID --> SDELKA[Карточка сделки\nдо 100 полей суммарно]
SDELKA -->|автозаполнение| KOMPANIYA
SDELKA -->|автозаполнение| KONTAKT
Типы полей: что выбрать для каждой ситуации
Выбор типа поля определяет, как данные вводятся, хранятся и используются в автоматизации.
| Тип поля | Когда использовать | Пример |
|---|---|---|
| Строка | Произвольный текст, одна строка | Должность, номер договора |
| Строка (многострочная) | Комментарий, описание запроса | Детали запроса клиента (высота 5) |
| Список | Фиксированный набор значений, один выбор | Способ оплаты, тип компании |
| Список (множественный) | Несколько значений из набора | Сфера деятельности, группа продукции |
| Число | Суммы, количества, расчётные показатели | Получено средств, остаток к доплате |
| Дата | Фиксация событий и дедлайнов | Дата последней продажи, желаемая дата старта |
| Дата и время | События с точностью до минуты | Дата и время зум-встречи |
| Да/нет | Бинарный признак | Отсрочка платежа, вся сумма получена |
| Файл | Вложения к карточке | Акт, рабочая документация |
| Привязка к сотруднику | Ответственный, исполнитель | Ответственный менеджер |
| Привязка к элементу CRM | Связь между объектами | Сделка в смарт-процессе |
Практическое правило: список предпочтительнее строки везде, где данные потом нужны для фильтрации или автоматизации. Строка удобна только для уникального текста, который не повторяется.
Карточка контакта: что добавляют на практике
В типовом проекте карточка контакта содержит до 30 пользовательских полей. Стандартный набор (фамилия, имя, телефон, email, адрес) дополняется отраслевыми данными.
Универсальные дополнения: - Тип контакта (список: клиент, подрядчик, партнёр) - Тип клиента (список с сегментацией) - Источник — передаётся автоматически из карточки лида - Дата рождения — используется для автоматических напоминаний
Пример автоматизации по полю карточки контакта: если тип покупателя не «Конечный покупатель» и дата рождения не заполнена — система ставит менеджеру задачу на уточнение. После заполнения ежегодно за день до даты рождения автоматически создаётся задача с именем «Поздравить [Имя] [Фамилия] с днём рождения».
Поля для повторных продаж (ювелирная и сервисная розница): - Дата последнего ремонта - Дата последней скупки - Дата последнего обмена - Не получил одобрение от банка на рассрочку (да/нет) - Дата отказа банка по рассрочке - Сумма по отказанной рассрочке
Такие поля заполняются автоматически при завершении карточки сделки с соответствующим типом — менеджер не тратит время на ручной ввод.
Перед тем как формировать список полей, полезно проработать требования через опросный лист — это экономит время на переделки.
Карточка компании: поля для сегментации и аналитики
Карточка компании — центральный объект для накопления истории отношений с корпоративным клиентом. В сложных проектах она содержит до 50 полей.
Базовые классификационные поля:
| Поле | Тип | Пример значений |
|---|---|---|
| Организационно-правовая форма | Список | ИП, ООО, АО, ФГУП |
| Тип компании | Список | Производитель, дистрибьютор, партнёр, конкурент |
| Сфера деятельности | Список (множественный) | Медоборудование, IT, пищевая продукция… |
Аналитические поля — заполняются автоматически: - Финансовый результат за всё время работы — увеличивается на сумму каждой успешной сделки - Количество сделок — счётчик закрытых сделок - Дата последней продажи — фиксируется при завершении сделки как успешной - Категория клиента — автоматически формируется как комбинация финансового потенциала и прогноза частоты обращений (например: AQ1, BQ2)
Поле «Дата последней продажи» особенно ценно: на его основе создаются сохранённые фильтры для всей команды — чтобы легко находить компании, которые не покупали ничего за последние 3, 6 или 12 месяцев.
В логистике карточка компании дополнительно хранит дату последней активности по перевозкам — её вычисляет бизнес-процесс, который ежесуточно проверяет список последних перевозок и записывает дату самой свежей. Подробнее о таких интеграционных сценариях — в статье про Битрикс24 для логистики.
Карточка лида: минимум для квалификации
Карточка лида хранит информацию о контакте, компании и обращении до момента квалификации. Стандартный объём — до 20 полей. Данные поступают вручную или автоматически из каналов лидогенерации (формы на сайте, телефония, мессенджеры).
Типовой состав полей карточки лида:
- Источник (список)
- Причина обращения (строка)
- Дата следующей коммуникации
- Причина отложенного звонка (строка)
- Номер телефона, email, название компании
Важный момент: поле «Источник» в карточке лида должно автоматически передаваться в карточку контакта при конвертации — иначе аналитика по каналам привлечения в CRM разрывается.
После квалификации лида система создаёт связанные карточки контакта, компании и сделки с заполненными данными из лида — это ключевой результат правильно настроенной воронки лидов.
Карточка сделки: поля под процесс продажи
Карточка сделки — самая насыщенная по количеству полей. В проектах с несколькими воронками суммарно настраивается от 40 до 100 полей, при этом поля, общие для всех воронок, считаются один раз.
Пример универсальных полей для всех воронок (консалтинг, услуги):
| Поле | Тип | Примечание |
|---|---|---|
| Детали запроса клиента | Строка (5 строк) | Заполняется менеджером |
| Материалы от клиента | Файл (множественный) | ТЗ, брифы, документы |
| Дата и время зум-встречи | Дата и время | |
| Итоги первой зум-встречи | Строка (3 строки) | |
| Предпочитаемый канал связи | Список | Почта, WhatsApp, Telegram |
| Способ оплаты | Список | По счёту, наличными, картой, переводом |
| Момент оплаты | Список | Предоплата, постоплата, авансовая |
| Отсрочка платежа | Да/нет | |
| Крайняя дата оплаты по отсрочке | Дата | |
| Получено средств | Число | |
| Осталось к доплате | Число | |
| Вся сумма получена | Да/нет | Контроль при завершении сделки |
Пример для строительного подряда: - Желаемая дата старта работ - Желаемая дата финиша - Дата старта (фактическая, ставится прорабом) - Дата финиша (фактическая) - Акт передачи давальческого материала (файл, обязательный при определённом условии) - Рабочая документация (файл, множественный, появляется со стадии подписания договора)
Обратите внимание: поле «Рабочая документация» в этом примере отображается не с первой стадии, а только с момента подписания договора — это управление видимостью через настройку карточки.
Если ваши сделки предполагают длительное согласование, изучите также подход к воронке проектных продаж — там вопрос состава полей особенно важен.
Обязательность, видимость и порядок полей
Три параметра, которые определяют поведение поля в карточке:
Обязательность
Поле может быть обязательным при переходе на конкретную стадию. Это значит: пока поле не заполнено, сделка не перейдёт дальше по воронке. Используется для: - Контроля качества данных на ключевых переходах - Фиксации причины отказа на негативных стадиях - Подтверждения получения оплаты перед закрытием
Не злоупотребляйте обязательными полями — если их слишком много, менеджеры начинают заполнять «для галочки» некорректными данными.
Видимость
Поля можно настроить так, чтобы они: - Показывались всегда — ключевые данные, нужные на любой стадии - Скрывались — неактуальные для данной воронки поля убираются из вида, но данные сохраняются - Отображались в «моём виде» — каждый сотрудник может настроить личный вид карточки, не трогая общий
В проектах с несколькими воронками одно и то же поле может быть видимым в одной воронке и скрытым в другой — это позволяет не создавать дублирующих полей.
Порядок и группировка
Поля группируются в разделы (например, «Контроль оплат», «Реквизиты»). Порядок полей внутри раздела и порядок разделов настраивается через редактор карточки. Правило: сначала — поля, которые заполняются первыми в процессе работы.
Если после первичного запуска выяснится, что часть полей лишняя или не хватает новых — это нормальная ситуация, которая фиксируется в структуре ТЗ на доработку.
Автозаполнение и связи между карточками
Часть полей не требует ручного ввода — они заполняются автоматически через бизнес-процессы или роботов.
Типовые сценарии автозаполнения:
-
Из сделки в контакт. При успешном закрытии сделки с определённым типом (например, «ремонт») поле «Дата последнего ремонта» в карточке контакта автоматически фиксирует дату завершения.
-
Из сделки в компанию. Поля «Финансовый результат», «Количество сделок», «Дата последней продажи» обновляются при каждой успешной сделке — без участия менеджера.
-
Из лида в контакт/компанию. При конвертации лида поля источника, причины обращения и другие данные автоматически переносятся в связанные карточки.
-
Из смарт-процесса в компанию. В логистических проектах поле «Дата последней активности» в карточке компании обновляется ежесуточно на основе данных из смарт-процесса «История перевозок».
-
Название сделки по шаблону. Бизнес-процесс формирует название автоматически из комбинации полей: название объекта + город + бренд. Это упрощает навигацию в списке сделок.
Для сложных интеграционных полей (например, синхронизация с 1С) важно заранее определить направление передачи данных и обязательность заполнения — иначе синхронизация не сработает. Подробнее о таких сценариях читайте в статье про интеграцию Битрикс24 и 1С.
Если часть полей предполагает хранение нетипичных данных — например, пользовательских реквизитов в банковских реквизитах — стандартными средствами CRM это не реализуется и потребует доработки через REST API.