Короткий ответ
Главное правило одной строкой:
Полей должно быть столько, чтобы их было достаточно для текущего этапа.
Не «на все случаи жизни» и не «пусть будет, вдруг пригодится». Достаточно для этапа, на котором сделка находится сейчас.
Остальное — инструменты, которые позволяют это правило соблюдать: обязательность по стадиям, ограничение видимости и расчёт через автоматизацию.
Штатные и пользовательские
Штатные поля система создаёт сама: сумма, ответственный, стадия, источник, контакт, компания. Удалить их нельзя, но можно скрыть из карточки, если они не нужны.
Пользовательские вы создаёте под свои задачи.
Правило, которое экономит потом много времени: сначала проверьте, нет ли подходящего штатного поля. Дублирующее пользовательское — частая причина, по которой потом не сходятся отчёты: часть сделок заполнена в штатное поле, часть в самодельное, а сводка собирается по одному из них.
Какие бывают типы
Их семнадцать, и выбор типа важнее, чем кажется: от него зависит, можно ли будет по этому полю фильтровать, считать и строить отчёты.
| Тип | Когда брать |
|---|---|
| Строка | свободный текст: комментарий, номер, примечание |
| Целое число, Число | количество, вес, метраж — то, что суммируется |
| Деньги | суммы; отличается от числа тем, что несёт валюту |
| Дата, Дата и время | сроки, плановые даты, дата монтажа |
| Да/Нет | признак: нужен ли выезд, есть ли доверенность |
| Список | выбор из фиксированного набора |
| Адрес | адрес с разбором на составляющие |
| Ссылка | ссылка на внешний ресурс |
| Файл | вложения: схемы, замеры, фото объекта |
| Привязка к пользователю | второй ответственный, инженер, кто согласовал |
| Привязка к элементам CRM | связанная сделка, счёт, предложение |
| Привязка к справочникам CRM | значения из своего справочника |
| Привязка к инфоблокам | элементы и разделы каталога |
| Бронирование ресурсов | переговорная, техника, слот |
Любое поле дополнительно делается множественным — тогда в него попадает несколько значений сразу. Это удобно для списков вроде «какие услуги интересуют», но осторожно: множественные поля хуже ложатся в отчёты.
Главная ошибка выбора типа — брать строку там, где нужен список. В строке каждый менеджер напишет по-своему: «Москва», «москва», «МСК». Ни отфильтровать, ни посчитать. Список лишает свободы и этим спасает данные.
Правило достаточности и как оно работает на практике
Двадцать полей в карточке появляются не сразу. Каждое заводили под конкретный запрос: тут нужно фиксировать источник рекомендации, там — номер доверенности, здесь — предпочтительное время звонка.
Через год менеджер открывает карточку и видит простыню, в которой заполнено четыре поля из двадцати. Остальные пустые — и уже никто не помнит, кто и зачем их просил.
Признаки, что полей перебор:
- Менеджеры заполняют не все. Это не про дисциплину — они интуитивно отсекают лишнее. Перегруженная карточка — первая из причин, почему менеджеры не работают в CRM.
- Руководитель не может назвать назначение каждого поля.
- Есть поля, которые заполняются один раз в квартал.
- Карточка не помещается на экран без прокрутки.
Лечится не удалением всего подряд, а привязкой полей к этапу.
Поля, привязанные к стадии
Ключевая мысль, из которой следует всё остальное: разные этапы требуют разных данных.
На первом контакте достаточно понять, кто это и что ему нужно. Поля про реквизиты, адрес доставки и условия договора на этом этапе только мешают — они пустые и создают ощущение, что карточка не заполнена.
На стадии договора наоборот: реквизиты обязательны, а поле «источник обращения» уже неважно, оно заполнено давно.
Настраивается это обязательностью на конкретных стадиях, а не на всех. Сделка не двинется дальше, пока нужное для этого этапа поле не заполнено.
Мы называем это защитой от ошибки. Работает она так:
- нельзя закрыть сделку в успех без суммы;
- нельзя отправить в производство без адреса и контактного лица;
- нельзя перевести на договор без реквизитов;
- нельзя закрыть в провал без указания причины.
Последний пункт особенно важен: без причины отказа проигранные сделки превращаются в кучу, с которой ничего нельзя сделать.
Важное ограничение: обязательных полей должно быть мало. Если на каждой стадии по пять обязательных, менеджеры начнут заполнять их формально — «ааа», «нет», «123». Данные станут хуже, чем были без обязательности.
Видимость: я вижу, ты не видишь
Отдельная настройка, про которую часто не знают: у поля можно ограничить видимость — выбрать сотрудников, которые увидят его содержимое.
Типовые случаи:
- Закупочная цена и маржа — видит руководитель, не видит менеджер.
- Условия договора и скидки — видит РОП и юрист.
- Внутренние пометки по клиенту — видит только тот, кто ведёт.
- Данные, которые нельзя показывать подрядчикам, работающим в том же портале.
Это настройка на уровне поля, отдельная от прав доступа к самой сделке. То есть человек видит сделку целиком, но конкретное поле для него скрыто.
Полезно помнить, что это удобство, а не защита от утечки: ограничение видимости решает вопрос «кому что показывать в интерфейсе», а не вопрос безопасности данных.
Расчётные поля: три сценария и экономика
Частый запрос: сделать поле, которое считается само. Маржа из суммы и себестоимости, срок из даты плюс количество дней, итог из количества и цены.
В разных системах это решается по-разному, и это стоит понимать до того, как выбрали систему:
Есть готовое поле-калькулятор. Настраиваете формулу в интерфейсе, поле считает само. Быстро и дёшево в поддержке.
Нет вообще. Считать придётся вне системы, а результат заносить руками — со всеми вытекающими.
Делается автоматизацией. Так устроен Битрикс24: отдельного типа «вычисляемое поле» здесь нет, но робот или бизнес-процесс при переходе на стадию берёт значения других полей и записывает результат в нужное.
Третий вариант работает, но у него есть цена, и вот здесь начинается разговор об экономике.
Во-первых, тариф. Простой расчёт делается роботом, а сложная логика с ветвлениями — бизнес-процессом, а он доступен не ниже Профессионального.
Во-вторых, настройка. Это работа: описать логику, собрать, проверить на краевых случаях, поддерживать при изменениях. Разовое поле-калькулятор стоит дешевле, чем кажется; десяток расчётных полей с зависимостями друг от друга — уже проект.
В-третьих, поддержка. Изменилась формула расчёта маржи — нужно править автоматизацию, а не поле. Тот, кто это делал, должен быть доступен.
Поэтому решение принимается не «хотим или нет», а сопоставлением: сколько стоит настройка и более высокий тариф против того, сколько времени сейчас тратится на ручной расчёт и сколько стоят ошибки в нём. Иногда честный ответ — считать в таблице, и это нормально.
Что проверить в своей карточке
- Пройдите по всем полям и по каждому ответьте: кто заполняет, на каком этапе, кто этим пользуется. Поля без ответа на третий вопрос — кандидаты на удаление.
- Найдите дубли штатных полей — самодельные «Телефон», «Сумма», «Ответственный».
- Проверьте типы: нет ли строки там, где должен быть список.
- Привяжите обязательность к стадиям, а не делайте поля обязательными везде.
- Посчитайте обязательные поля на каждой стадии: больше двух-трёх — риск формального заполнения.
- Проверьте видимость чувствительных полей: маржа, закупка, условия.
- Расчётные поля — оцените экономику до того, как заказывать настройку.
Если карточка разрослась и непонятно, что можно убрать, — посмотрим, какие поля реально заполняются, а какие пустуют. Обычно выясняется, что половина не используется, а из оставшихся треть дублирует штатные.
Если нужна помощь с настройкой портала — смотрите внедрение и настройка Битрикс24.